Taras

In theory, we can avoid "overfetching": First download `BUCK` file of dependency and then execute it until some point (for example, we will force to check features before adding any...

I think it's better to leave only `BUCK` and download the whole package in any case (at least, it can be changed in future). Also, since we have `buckaroo_macros`, we...

But also, that type system is not always convenient for configuration in the example: ```toml api = { gl = "3.2", gles = "" }, ``` Maybe we should allow...

Due to TOML restrictions, the config will look like: ```toml [[dependency]] package = "github.com/Tarik02/glfw" version = "branch=fix-windows" [[dependency.feature]] name = "profile" value = "core" [[dependency.feature]] name = "api" value =...

Yes, you can see more info about array of tables in table [here](https://github.com/toml-lang/toml/blob/master/README.md#array-of-tables).

Yes, I thought about it. I think it is good place for the features. Also, it's needed to modify buckaroo_macros.bzl to add functions to access features list. Features should be...

Also, I have a question: is there a way to get know what package are we building from function in `.buckconfig.d/.buckconfig.buckaroo`?

> I think we should explore using just read_config before extending the macros. Once we add a macro, it is very difficult to change them without breaking packages. @njlr, if...

> Well we are committed to maintain macros once they are offered. If they are provided and people use them, then changing them will break packages. I would call this...

> Step 3: Implement virtiofs support in QEMU for Darwin Do you think this is possible? It requires to be able to share mmap'ped memory pages between host and guest....