|Anonymous | Login | Signup for a new account||2017-05-28 01:18 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006234||OCaml||-for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues||public||2013-11-11 12:08||2017-02-24 16:04|
|Target Version||later||Fixed in Version|
|Summary||0006234: surprising warn tag application order|
|Description||ocamlbuild tags are meant to be declarative, but unfortunately it is not always the case and the order matters.|
Consider the following _tags:
this example works and for a.cmo annot tag is canceled out - tags are applied from top to bottom.
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:
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.
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`.
|Tags||No tags attached.|
The proposed semantics seems reasonable, but I wonder whether people wouldn't expect
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.
"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.
ocamlbuild is now a separate project that lives on GitHub.
PR transferred to https://github.com/ocaml/ocamlbuild/issues/153 [^]
|2013-11-11 12:08||ygrek||New Issue|
|2013-11-11 12:33||gasche||Note Added: 0010614|
|2014-05-30 15:13||shinwell||Assigned To||=> gasche|
|2014-05-30 15:13||shinwell||Status||new => acknowledged|
|2014-07-08 11:28||doligez||Note Added: 0011794|
|2014-07-08 11:28||doligez||Severity||major => minor|
|2014-07-08 11:28||doligez||Target Version||=> 4.03.0+dev / +beta1|
|2015-12-02 16:05||gasche||Target Version||4.03.0+dev / +beta1 => later|
|2017-02-23 16:34||doligez||Category||OCamlbuild (the tool) => for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues [^]|
|2017-02-23 16:44||doligez||Category||for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues [^] => -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues [^]|
|2017-02-24 16:04||doligez||Note Added: 0017451|
|2017-02-24 16:04||doligez||Status||acknowledged => resolved|
|2017-02-24 16:04||doligez||Resolution||open => suspended|
|Copyright © 2000 - 2011 MantisBT Group|