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
The bug, reported by Jacques-Pascal Deplaix, was only in trunk -- it
appeared in the bootstrap->Makefile transition.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14471 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
14278
14277
14276
14176
14175
14173
14172
14171
14169
14168
14167
These changes need to mature on their own branch.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14329 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This script was built from ocamlcomp.sh.in through sed and is called
instead of "ocamlc" (for instance).
It makes it possible to switch from "ocamlc" to "ocamlc.opt" without
changing anything in the Makefiles, only calling sed.
I couldn't cleanly make it handle both a compiler for the target and for
the build. Instead I'm replacing it and doing as much as possible
directly in the Makefiles.
I hoped it would reduce the number of shell invocations, which would
speed things up quite a lot on Windows but I still had to have at least
one since it's not possible to update a make variable from inside a make
rule: i.e. it's not possible to do X=a, build a.opt and update X to be
a.opt.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14168 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
I plan to add at least documentation and deprecation information to
each flagset, so structuring it as a record is important.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14140 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The second test currently fails, because the plugin is not build if no
target is passed. This will be fixed shortly.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14137 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
I just got bitten by a weird issue where the test I expected to run
was ignored, and never appeared in test runs. I just forgot the final
`()` parameter to the `test` function, and `foo;;` was perfectly happy
to accept an input of non-unit type. Now using explicits `let () =` to
avoid that issue in the future.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14136 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
When both those features are used together, we use ocamlfind packages
instead of hardlinking unix.cmxa and ocamlbuildlib.cmxa during the
ocamlbuild plugin compilation. This helps to avoid double-linking
errors (with unix.cmxa and "-package unix") when -plugin-tags request
ocamlfind packages depending on unix (or ocamlbuild).
This change was designed and implemented in collaboration with Jun Maillard.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14069 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The previous approach to use _tags to get tags to compile
myocamlbuild.ml had one irritating downside: it would also take the
tags of the (true: foo) lines, which are certainly not intended by the
user to be applied to plugin compilation as well.
These additional tags looked mostly harmless. Of course, it turns out
that there is one case where they're not: as the plugin compilation
command already links "unix.cma" with the plugin, a user having
`true: use_unix` or `true: package(unix)` in its _tags file would get
a plugin compilation error due to double-linking of unix.cmxa. This
caused a regression breaking build in some projects, which is not
acceptable.
The current approach of using a specific command-line option is a bit
more annoying for end-users (you have to retype it each time, or script
ocamlbuild invocation from somewhere else), so we expect it to get
less widely used. It is still interesting for OASIS for example, or
people already using a convenience wrapper (eg. corebuild).
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14035 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
Gabriel Scherer
Damien Doligez
Jacques Garrigue
Alain Frisch
Xavier Leroy
Wojciech Meyer
Xavier Clerc