When reporting a circular dependency, refine the printed filenames to
those that are really part of the cycle -- instead of those that
happened to be traversed during the DFS that found a cycle. This gives
much more readable error messages.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15693 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This allows to prevent the --infer option from being passed to Menhir
by using the negative tag -infer.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15598 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
ocamlbuild lazily traverses directory to build a vision of the
filesystem tree in which the build happens. During that traversals, it
parses any configuration file `_tags` it encouters. PR#6482 was caused
by the fact that the configuration-parsing code used the relative path
of the _tags file, which was correct at the time of traversal, but
stale at the time the lazy thunk was in fact forced (a Sys.chdir had
occured in between).
The first fix is to detect when relative paths become stale, and use
the correct absolute path in that situation.
The reason why this lazy thunk was only forced after a Sys.chdir is
that, at hygiene time, only the subtrees that are selected for hygiene
checking are forced. It is an unexpected behavior that non-hygienic
subtrees could remain unforced for so long (in particular, the
semantics of parsing a configuration file only much later in the build
process is more than unclear); this commit also removes this behavior
by always forcing the whole traversed subtree just before hygiene.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15000 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Building foo.cmo in an empty directory (so with in particular no
foo.ml) currently returns the following output:
> Solver failed:
> Ocamlbuild cannot find or build foo.ml. A file with such a name
> would usually be a source file. I suspect you have given a wrong
> target name to Ocamlbuild.
> Backtrace:
> - Failed to build the target foo.cmo
> - Building foo.cmo:
> - Failed to build all of these:
> - Building foo.ml:
> - Failed to build all of these:
> - Building foo.mly
> - Building foo.mll
> - Building foo.mli:
> - Building foo.mly
> - Building foo.mlpack
> - Building foo.mli:
> - Building foo.mly
> Compilation unsuccessful after building 0 targets (0 cached) in 00:00:00.
While the "Solver failed" part is nice and reasonably easy to
understand, users report that the "Backtrace" part is confusing
(it talks about files they don't know about) -- and it can be so large
that the explanation above is completely hidden.
This patch disables backtrace-printing by default; it is now only
shown when some "-verbose N" (N starting at 1) argument is passed.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14732 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Before this path, [Param_tags.init()] was run before
[Plugin.execute_plugin_if_needed()]. It had the downside of making
plugin compilation warn about any unknown parametrized tag present in
a _tags file, even those that would be defined by the plugin
itself. The fix is to [really_acknowledge] only the tags used for the
plugin compilation, and delay the full [Param_tags.init()] call to
after plugin execution.
This was discussed in detail in PR#5680, comment 0010186.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14015 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
If in the future we want to be able to use information from _tags when
compiling the myocamlbuild.ml plugin, we should compile the plugin
*after* the OCaml-tags rules of Ocaml_specific have been loaded
(OCaml_specific.init()). This patch does not change the plugin
compilation, but it delays it to the end of the initialization phase
to allow such future changes.
This means that the parsing of configuration files
(including traversing directories to find _tags files in depth) will
be done twice (once during the first run to compile the plugin, and
then once when run from the plugin). Of these operations, the only
that has user-visible consequences (and the first candidate to
performance degradations) is the hygiene checking, which we therefore
disable during the first run. Note that checksumming files is not
duplicated (it is done after the initialization phase).
Note that the semantics of _tags files in subdirectories is that they
are only ranging over files in that subhierarchy (even "true: foo"
lines do not apply to the files in ancestor or
sibling directories). This means that no _tags file in a subdirectory
can add tags to "myocamlbuild.ml". If performance of file traversing
ever was to become an issue, we could therefore skip it and read only
the root _tags file if present.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13998 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
You can still have a fine grained control using your _tags
file and the "traverse" tag.
There is no longer the "true: traverse" tag declaration by default.
To make ocamlbuild recursive use one of these:
1) Give the -r flag to ocamlbuild.
2) Have a _tags or myocamlbuild.ml file in your top directory.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@8669 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
.depends file was generated by an ugly rule that executed the ocamldep
command instead of returning it for later execution. Moreover this execution
was in order to read the output and store as a side effect. By doing this it
was more complicated to work with this command. Now the rule just returns the
command to execute as for other rules. And that's clients that wants
dependencies of a file that trigger the reading of this file.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@8566 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
There is now an abstract type to ensure that resource_patterns are not mixed
with resources. Rules are now 'a gen_rules where 'a is the type of production
resources (either a resource or a resource_pattern).
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@8547 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Gabriel Scherer
Xavier Leroy
Damien Doligez
Wojciech Meyer
Jonathan Protzenko
Xavier Clerc
Nicolas Pouillard