Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006234OCamlOCamlbuild (the tool)public2013-11-11 12:082014-07-08 11:28
Reporterygrek 
Assigned Togasche 
PrioritynormalSeverityminorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version4.01.0 
Target Version4.03.0+devFixed in Version 
Summary0006234: surprising warn tag application order
Descriptionocamlbuild 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`.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0010614)
gasche (developer)
2013-11-11 12:33

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.
(0011794)
doligez (administrator)
2014-07-08 11:28

"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.

- Issue History
Date Modified Username Field Change
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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker