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

surprising warn tag application order #6234

Closed
vicuna opened this issue Nov 11, 2013 · 3 comments
Closed

surprising warn tag application order #6234

vicuna opened this issue Nov 11, 2013 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Nov 11, 2013

Original bug ID: 6234
Reporter: @ygrek
Assigned to: @gasche
Status: resolved (set by @damiendoligez on 2017-02-24T15:04:18Z)
Resolution: suspended
Priority: normal
Severity: minor
Version: 4.01.0
Target version: later
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues
Monitored by: @hcarty

Bug description

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.

@vicuna
Copy link
Author

vicuna commented Nov 11, 2013

Comment author: @gasche

The proposed semantics seems reasonable, but I wonder whether people wouldn't expect

<a.*>: -annot
true: annot

to behave as your example (instead of being equivalent to "true: annot"), intuitively a "priority to the more precise" order.

The good user interface would be to implement a reasonable order, and raise warnings for stuff that doesn't quite make sense: warn when a tag specification is completely shadowed one that is below (as it becomes useless). This would in particular warn as soon as the less-to-mose-precise order becomes incompatible with the top-to-bottom order.

Unfortunately development time is scarce, so I won't make any promise for a timeline on implementing this myself. I would be delighted to help you or someone else contribute a patch, but be aware that I have no idea how hard any of this would be.

@vicuna
Copy link
Author

vicuna commented Jul 8, 2014

Comment author: @damiendoligez

"user order" is both simple and intuitive

"priority to the more precise" needs to define exactly what "more precise" means, then to explain it to users. Looks like a lot of work and likely to fail.

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @damiendoligez

ocamlbuild is now a separate project that lives on GitHub.
PR transferred to ocaml/ocamlbuild#153

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

2 participants