(Simon Cruanes and Gabriel Scherer)
Use one of
-color auto
-color always
-color never
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16348 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This should cover all places involving filenames in the compiler.
There are a few more paths still using Latin-1 in other ways,
e.g. in ocamldoc.
From: Peter Zotov <whitequark@whitequark.org>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15727 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
I'm worried the previous algorithmically-naive implementation may
behave badly on larger-scale projects. We still keep a list around to
return results in the exact same order as previously.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15694 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
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 should append .exe extension to filename when looking for
executables and Sys.cygiwn is set (not only Sys.win32).
From: algoriddle <szilvasy@gmail.com>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15577 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
It kicks in for interface inference and compiler invocations.
safe_string does also alter the output of inferred types if
short_paths is used (since "bytes" is shorter than "string"),
but this requires a change to the ocamldoc driver and isn't
addressed in this PR.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15053 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