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
The long-term goal is to allow composability of myocamlbuild.ml
plugins, as discussed in PR#5680 and PR#6093. The current attempt is
to give to the myocamlbuild.ml all the tags that apply to it according
to the _tags file and other configuration options passed to
ocamlbuild. For example, if -use-ocamlfind is used, any
(true: package(foo)) or ("myocamlbuild.ml": package(foo)) line would
have the ocamlfind package `foo` usable from myocamlbuild.ml.
The present implementation has two downsides:
(1) Relying on _tags is a bit unpleasant because people that write
(true: foo) lines do not expect it to get also applied to the
plugin compilation (though in fact the previous implementation
used "profile" and "debug" tags passed in this way). There might
be case of build breaking because the (true: tags) passed make
myocamlbuild.ml compilation fail. A workaround would be to add
("myocamlbuild.ml": -foo) for any problematic tag `foo` -- I don't
expect this situation to happen in practice, but you never know.
(2) The general tags passed to the myocamlbuild.ml compilation have
been rather arbitrarily set to (ocaml,program,link,byte)
(or native). OCamlbuild doesn't really have tags to describe going
straight from a .ml (or several) to an executable, as its usual
rules enforce separate compilation and linking steps. This means
that some ocamlbuild rule might misbehave due to the absence of
the "compile" step, but in practice most tag-driven compilation
options are such that the link-options are a superset of the
compile-options, so this will still work in many case
(in particular for ocamlfind packages). Long-term, it may be
better to split myocamlbuild.ml compilation in the usual compile
then link steps.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13999 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
The parameter ~tags of Rule.rule has been ignored and deprecated for
a while, but our own code in ocaml_specific.ml was still using it --
confusing several plugin writers. This patch, inspired by a patch
proposal by Anil Madhavapeddy on PR#6059, also makes Rule.rule emit
a warning when this parameter is used. Anil originally removed it
completely from the interface, but I would like to avoid breaking the
compilation of plugin code.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13987 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This change was recommend by daweil on the bugtracker. According to
the Bash documentation, the option -c that is already passed by
ocamlbuild should already imply --norc, but daweil reported a 30%
performance speedup with this change anyway. I'm a bit surprised, but
this cannot hurt...
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13969 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
ocamlfind library management has been around for while and is
considered to be installed by default on any OCaml system. Therefore
it's safe to assume that the default behavior of ocamlbuild should be
to use new ocamlfind support normally enabled explicitly by
-use-ocamlfind flag. The -use-ocamlfind flag has now a status of
depreceation and instead new flag -no-ocamlfind causes ocamlbuild to
not try to use new set of parametric tags for supporting ocamlfind.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13938 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The -thread option is only needed when creating a compilation unit
("compile" tag handled separated), or linking libraries into a final
program ("link";"program"). However, ocamlfind will fail with an error
if neither of -thread or -vmthread is passed into the command-line of
any linking step, such as when creating a cm(x)a archive. The present
fix enables the -thread option for all linking steps, which should fix
any -use-ocamlfind issue and be harmless in other cases.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13934 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
* -short-paths is activated via the "short_paths" tag
* -principal is activated via the "principal" tag
* -strict_sequence now has a "strict_sequence" tag to alias the
"strict-sequence" tag that was already there, to follow the
convention of command-line options having dashes replaced by
underscores. It's easy to mess this up since incorrect tags
are silently ignored by ocamlbuild.
Add test cases that check if principal and strict-sequence have
been passed, and tweak the test suite slightly to make it easier
to match on failing_msg output.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13859 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Xavier Leroy
Wojciech Meyer
Gabriel Scherer
Xavier Clerc