Open rgrinberg opened 3 years ago
To complement what Rudi said, the general idea is to add a new operation get_target_list : Path.Build.t -> String.Set.t
in addition to the gen_rules
one. I feel like it would clarify the control flow. For instance, get_target_list
is exactly what we need to evaluate the list of modules attached to a library
or executable
stanza.
@snowleopard do you think this is still relevant given the proposal #5251 ?
I think it would be nice to write up an RFC with an up-to-date plan for making rule generation more flexible, merging ideas from various places (possibly discarding some which are no longer relevant). I don't think I'll have time to do this in the next few weeks, but I'm happy to give feedback on the RFC if you get to it earlier.
I would say this RFC is generalized by #5251. The main distinction is:
So it should be easy enough to extend #5251 to cover this use as well.
This is an idea that came up in a meeting with @jeremiedimino.
It's useful to know the targets produced by a rule without evaluating the rules. For example, it would be nice to know the targets produced by
Simple_rules.user_rule
without evaluating the rule.So if we consider
Conceptually, we'd like this to be split into:
Notably, the
Super_context.t
parameter is absent fromuser_rule_targets
which allows us to drop theSuper_context
dependency inDir_contents
. The question that remains is how to share the computation the work between the two computations as much as possible.