Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005851OCamlOCamlbuild (the tool)public2012-12-12 01:092012-12-13 18:23
ReporterMatthieu Lemerre 
Assigned Toxclerc 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version3.12.1 
Target VersionFixed in Version 
Summary0005851: Ocamlbuild cannot resolve dependencies when there are no _tags file (but can with an empty _tags file)
DescriptionThere is a difference in behaviour between no _tags file and an empty one. Ocamlbuild succeed in building a simple project only if there is an empty _tags file in the directory.
Steps To ReproduceFirst create a project with the following files:

File: plu/bla.ml
#+begin_src ocaml
let bla = 3;;
#+end_src

File: plu/bli.ml
#+begin_src ocaml
let bli = Bla.bla;;
#+end_src

File: plu.mlpack
#+begin_example
plu/Bla
plu/Bli
#+end_example

File: use.ml
#+begin_src ocaml
Plu.Bla.bli
#+end_src


Try to compile:

#+begin_example
ocamlbuild use.byte
/usr/bin/ocamlc -c -o use.cmo use.ml
+ /usr/bin/ocamlc -c -o use.cmo use.ml
File "use.ml", line 1, characters 0-11:
Error: Unbound module Plu
Command exited with code 2.
#+end_example

It seems that the ocamlbuild solver does
not know how to build the =.cmo= out of the =.mlpack=:

#+begin_example
ocamlbuild plu.cmo
Solver failed:
#+end_example

However, if you create (even an empty) =_tags= file at the root of the
project, then everything works:

#+begin_example
ocamlbuild use.byte
/usr/bin/ocamldep -modules plu/bla.ml > plu/bla.ml.depends
/usr/bin/ocamldep -modules plu/bli.ml > plu/bli.ml.depends
/usr/bin/ocamlc -c -I plu -o plu/bla.cmo plu/bla.ml
/usr/bin/ocamlc -c -I plu -o plu/bli.cmo plu/bli.ml
/usr/bin/ocamlc -pack plu/bla.cmo plu/bli.cmo -o plu.cmo
/usr/bin/ocamlc -c -o use.cmo use.ml
/usr/bin/ocamlc plu.cmo use.cmo -o use.byte
#+end_example
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0008598)
xclerc (developer)
2012-12-12 17:09

 It is arguably a design choice. As of today, the subdirectories
of the current directory are marked as "traverse" iff there is
either a "_tags", or a "myocamlbuild.ml" file.

Of course, this default behavior could as well be changed.
I am pondering the implications of such a change over
existing projects. Any advice is welcome.
(0008601)
Matthieu Lemerre (reporter)
2012-12-13 14:42

 I was not aware of this "traverse" tag, this solves my problem. But this behavior is quite surprising: adding _tags file seems unrelated to the notion of traversing subdirectories.

I am not sure of how "traverse" interacts with the rest of the system, or what is its purpose. Is this only to improve performance by avoiding directory traversal?

It seems that directories added by the -I flag are traversed (at least, "ocamlbuild -I plu use.byte" works in my case), so I think the .mlpack case is comparable: at least the directories present in the .mlpack files should be traversable (or a warning/error should be issued if a referenced directory is not traversable).
(0008605)
xclerc (developer)
2012-12-13 18:23

 > I was not aware of this "traverse" tag, this solves my problem. But this behavior is quite surprising:
> adding _tags file seems unrelated to the notion of traversing subdirectories.

I do agree that is seems strange at first, and think it would be a good thing to
change that. I am just afraid of breaking something...


> I am not sure of how "traverse" interacts with the rest of the system, or what is its purpose. Is this
> only to improve performance by avoiding directory traversal?

That is also my understanding.


> It seems that directories added by the -I flag are traversed (at least, "ocamlbuild -I plu use.byte"
> works in my case), so I think the .mlpack case is comparable: at least the directories present in the
> .mlpack files should be traversable (or a warning/error should be issued if a referenced directory is
> not traversable).

OK, fixing the problem this way could indeed be better.

- Issue History
Date Modified Username Field Change
2012-12-12 01:09 Matthieu Lemerre New Issue
2012-12-12 17:09 xclerc Note Added: 0008598
2012-12-12 17:09 xclerc Assigned To => xclerc
2012-12-12 17:09 xclerc Status new => feedback
2012-12-13 14:42 Matthieu Lemerre Note Added: 0008601
2012-12-13 14:42 Matthieu Lemerre Status feedback => assigned
2012-12-13 18:23 xclerc Note Added: 0008605

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker