Add `(exec prog args...)` to generalize `jbuilder utop`

[ghost]

We could add an action (exec <prog> <args>...) whose behaviour would be to stop the current build and chain the execution to <prog> <args>.... This way jbuilder utop would be the same as jbuilder build @utop and users could use the same mechanism for their own tools:

(alias
 ((name mytop)
  (action (exec ./mytop.exe))))

One possible implementation would be to raise Exec (prog, args, ...) when evaluating an (exec ...) form. This exception would be catched at the toplevel in bin/main.ml and we would call Unix.exec at this point, after having done the necessary cleanups.

[bobot]

It is a nice feature that remove some built-in mechanism. Will you have some check that this alias doesn't produce more than one exec command? Do you think we can make a static check (after parsing jbuild file)? It is perhaps difficult because of recursive alias.

I would prefer that exec is an additional field of alias stanza. Same possibility to use chdir, env ... but no sequence and only exec as leaf. Because I think it could add non-determinism (two alias with an exec action used as dependency of a third). The exec would be used only for a non-rec use (or the only alias) of an alias directly given on the command line.

[ghost]

I'm not sure what the check would like like, it might end up being expansive. At least it seems easy to check that only a single (exec ...) is seen during one run of jbuilder. We need something like make -k BTW, probably as a default, which I think would make this weaker check enough in practice. Do you agree?

I would prefer that exec is an additional field of alias stanza. Same possibility to use chdir, env ... but no sequence and only exec as leaf. Because I think it could add non-determinism (two alias with an exec action used as dependency of a third). The exec would be used only for a non-rec use (or the only alias) of an alias directly given on the command line.

I see. Although, this might be complicated now that we load rules per directory. To check that an (alias_rec ...) doesn't produce more than one exec, you need to load all the rules for the sub-tree.

[rgrinberg]

How would this exec stanza work with the custom arguments that are allowed to be passed to utop? Are we going to have to pass these arguments to the rule that generates the action?

[ghost]

I guess we don't need to change dune utop, but this could be useful for third-party tools.