fix: Allow anonymous actions to be directly attached to multiple aliases#15581
fix: Allow anonymous actions to be directly attached to multiple aliases#15581NatKarmios wants to merge 18 commits into
Conversation
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
I'm not sure if this is actually necessary; in my testing the action isn't rerun when multiple of its aliases are built. Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
e0ca6d8 to
5ea6006
Compare
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
There was a problem hiding this comment.
Don't worry about the x86 macos job atm, that's unrelated. Could you split the dune rules change + reflection stuff into a separate (followup) PR? That will make reviewing this a bit easier.
The idea of attaching multiple aliases to a rule or anonymous action is interesting, but I will need to think about it's implications a bit more.
| | Some a -> Alias.Name.to_string a ^ "-" ^ d | ||
| match act.aliases with | ||
| | [] -> d | ||
| | a :: _ -> Alias.Name.to_string a ^ "-" ^ d |
There was a problem hiding this comment.
This means that the digest of the action is determined by the first alias?
@rgrinberg do we really want to be digesting the alias names at all here?
There was a problem hiding this comment.
I suppose the question is how many times we expect:
(rule (alias a) (action (echo hi\n)))
(rule (alias b) (action (echo hi\n)))
when doing dune build @a @b.
With this change
(rule (alias a b) (action (echo hi\n)))
(rule (alias a c) (action (echo hi\n)))
dune build @b @c will only print hi once. But with
(rule (alias a c) (action (echo hi\n)))
(rule (alias b c) (action (echo hi\n)))
even dune build @c will print it twice.
There was a problem hiding this comment.
It does seem like a sensible decision to digest all the alias names then, but we obviously have to do so in some stable order.
There was a problem hiding this comment.
If the answer to my question on sharing actions with different aliases is that we want to share, then that would simplify the engine a bit since we wouldn't need to attach aliases to anon actions at all. It's not clear to me which one we want yet.
There was a problem hiding this comment.
Actually, can't this basename tweak be removed? The digest itself is computed based on all the aliases (execute_action_generic).
I've tweaked this to alphabetically sort the alias names before adding to the digest in ba35683, would that be sufficiently stable?
There was a problem hiding this comment.
Applying List.sort_uniq to the alias names before supplying them to the digest properly ensures that (aliases (a a)) doesn't run after (aliases (a)).
I think that the prepended basename isn't needed for normal operation, but a test (patch-back-source-tree.t) depends on it.
At the very least, I've made it select the (alphabetically) first alias name for prepending to ensure consistency.
Sure, done in 4d116a8 |
This reverts commit 758e8a4. Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
4d116a8 to
16eec08
Compare
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
NatKarmios
changed the title
…#15590) Related to #15576 & #15581 Adds 3 tests for anonymous actions with multiple aliases, specifically: - Building one of an action's aliases can pull in another alias - Duplicating or re-ordering aliases in a rule does not cause a re-run Note that all these tests currently fail, but are fixed by #15581: <details> <summary><b>Test results</b></summary> ```diff File "test/blackbox-tests/test-cases/alias/alias-multiple.t", line 1, characters 0-0: ------ test/blackbox-tests/test-cases/alias/alias-multiple.t ++++++ test/blackbox-tests/test-cases/alias/alias-multiple.t.corrected File "test/blackbox-tests/test-cases/alias/alias-multiple.t", line 139, characters 0-1: | |A rule attached to several aliases must not make one alias pull in unrelated |contributions to another alias. Here alias [a] also receives an unrelated |action; building [b] must run only the shared action. | $ cat > dune << EOF | > (rule | > (aliases a b) | > (action (echo "I have run\n"))) | > (rule | > (alias a) | > (action (echo "unrelated\n"))) | > EOF | | $ dune clean | $ dune build @b | I have run +| unrelated | |Building [a] still runs both the shared action and the action attached only |to [a]. | $ dune clean | $ dune build @A | I have run | unrelated | |The set of aliases determines the action's identity: neither duplicating an |alias nor reordering the aliases should re-run the action. | |Duplicating an alias does not re-run the action: | $ cat > dune << EOF | > (rule | > (aliases a) | > (action (echo "I have run\n"))) | > EOF | $ dune clean | $ dune build @A | I have run | $ cat > dune << EOF | > (rule | > (aliases a a) | > (action (echo "I have run\n"))) | > EOF | $ dune build @A +| Error: Dependency cycle between: +| alias a in dune:1 +| [1] | |Reordering the aliases does not re-run the action: | $ cat > dune << EOF | > (rule | > (aliases a b) | > (action (echo "I have run\n"))) | > EOF | $ dune clean | $ dune build @A @b | I have run | $ cat > dune << EOF | > (rule | > (aliases b a) | > (action (echo "I have run\n"))) | > EOF | $ dune build @A @b +| I have run ``` </details> --------- Signed-off-by: Nat Karmios <nat@karmios.com>
Signed-off-by: Nat Karmios <nat@karmios.com>
|
(Sorry, didn't mean to close/reopen) |
3 participants
Change registered anonymous actions from an
Anonymous_action.t Action_builder.tto a newAnonymous_action.Rule.t, which includes theloc,dir`, etc. (which was already computed ahead of time) and an ID (sharing ID space with regular rules).Fixes #15576
Checklist