Jakob Degen

> but in the implementation of the rule itself, since I wouldn't even have to create any subtargets. Even beyond this use case though, just being able to access the...

I'm more worried about the macro side, not the rule side. You still need to make this compose with other things that people do in macros. For example, someone is...

Yes, this is expected behavior. The only caching that is available across daemon instances is whatever is provided by the RE action cache. We've considered improvements here, typically under names...

There is not, no, although this is an interesting alternative to dice rehydration that I hadn't considered. I think @scottcao knows some things about this, maybe he can weigh in

> 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. It does, but not across daemons....

> Just curious, what does DICE stand for? I keep seeing it and wondering. Distributed incremental computation engine. The "distributed" is ehhh... "future work" > What's the current status of...

This particular example is, I think, just a bug. But more generally, I don't think we always know. The possibility of having multiple outputs was added to buck2 because we...

I don't think we'd just approve it, I honestly think that more generally useful toolchain rules across languages is one of the highest value contributions buck2 could see right now....

Yeah, agreed with Thomas. I think it would be good to know what the state that you are expecting to keep around is, we may be able to provide a...

> 1. Never cache Yeah, so we've talked about adding support for this kind of a thing before, primarily under the name "volatile actions." I think the hypothetical API is...