zjturner

I was under the impression that hash_all_commands basically enabled the action cache and that it would have benefits even in local build scenarios. Did I misunderstand?

Just curious, what does DICE stand for? I keep seeing it and wondering. In any case, I know buck1 had a dir cache, and the topic of dir cache has...

Why not a priority queue by number of nodes waiting (directly or indirectly) on the node?

Isn’t http_archive using a projected artifact as an output? https://github.com/facebook/buck2/blob/39d275483a79df668ca6eb73b534ea83c27e856f/prelude/http_archive/http_archive.bzl#L215

I looked into this some and I can reproduce this. Here's a minimal reproducer: ``` # root//bucklink:BUCK load(":rule.bzl", "link_dir") link_dir( name = "makelink", link_name = "hello", link_target = "D:\\src\\buck2", script...

> In the meantime, you can do a "local remote" build, where you run the "remote" build locally. I do plan to try this, I just haven't taken the time...

buck2 is already symlinking individual headers into the `buck2-private-headers` folder and then adding the include paths for the `buck-private-headers` folder to each target. But it's *also* adding the original directories...

this sounds very similar to the problem I’ve discussed a bunch of times in the past, where it’s very difficult to apply different configurations per target, so you’re forced into...

Try this: In your `.buckconfig` file: ``` [gsoyka] is_ci = false ``` In a `BUCK` file somewhere: ``` build_go_binary = not read_config("gsoyka", "is_ci", false) go_binary( name = "hello", srcs =...

You could make a macro. From a bzl file somewhere: ``` build_go_binary = not read_config("gsoyka", "is_ci", false) def my_rule_macro(name, srcs, deps): go_binary( name = "hello", srcs = glob(["*.go"]), deps =...