Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MPR#6234: surprising warn tag application order #153

Open
damiendoligez opened this issue Feb 24, 2017 · 0 comments
Open

MPR#6234: surprising warn tag application order #153

damiendoligez opened this issue Feb 24, 2017 · 0 comments
Assignees

Comments

@damiendoligez
Copy link
Member

PR transferred from https://caml.inria.fr/mantis/view.php?id=6234
[original reporter: @ygrek]

ocamlbuild tags are meant to be declarative, but unfortunately it is not always the case and the order matters.
Consider the following _tags:

true: annot
<a.*>: -annot

this example works and for a.cmo annot tag is canceled out - tags are applied from top to bottom.

Another example:

true: warn_A
<a.*>: warn_e

this also works (invoking -w A -w e) but contrary to the above changing the order of lines doesn't change the command line (!), looks like the tags are applied in the order of definition in ocamlbuild sources. In this specific case it makes sense..

Now the problem:

true: warn(+a)
<a.*>: warn(-e)

contrary to both of the above examples it will produce the command-line -w -e -w +a and all warnings are enabled. Looks like parameterized flags are applied from bottom to top.

The question is to sort this out and fixate for the coming generations and great good :)
And document the chosen behaviour so that it can be relied upon.

My proposition:
for the given command invocation tags are applied first in the order of definition in ocamlbuild and plugin sources, then in the order of appearance in _tags file. So the first two example remain the same, and the last one will produce -w +a -w -e.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants