This moves the configure-generated parts of Makefile.common to a
separate (generated) Makefile, allowing Makefile.common to be a normal
Makefile.
OCaml's build system Makefile's now include Makefile.build_config (which
itself includes Makefile.config) but Makefile.config is still installed
as before. This allows configure to generate variables which are
specific to the build process and are not intended to be exported to the
installation.
Switch ocamldebug to compiler-libs in order to avoid hidden dependencies issue.
In particular, the Env module is only fully initialized after the Typemod and Includemod modules have been linked. Calling `Env.find_type` before that initialization may result in an assert false when functor-derived types are involved.
This commit makes e.g. make -s world.opt completely
silent when everything works, in order to increase the visibility of
any unexpected message occurring during the build.
This will be useful for instance during CI, in particular it should
make it easier to catch undefined build variables.
The implementation is straightforward. The OCAMLLEX_FLAGS variable is
defined in Makefile.common.in and then used consistently by all
lexing recipes.
In addition, in tools/Makefile, the two rules producing the lexers
from cvt_emit.mll and make_opcodes.mll have been replaced by a
pattern-rule and the useless .SUFFIXES target has been removed.
* Various file moves in the middle end: this is the first stage of improving separation between the middle end and backend.
* Creation of file_formats/ directory (with associated file moves) to hold the definitions of compilation artifact formats.
* Creation of lambda/ directory (with associated file moves) to hold Lambda language definition files, transformation passes and construction passes from Typedtree.
* Disable (hopefully temporarily) dynlink, debugger and ocamldoc for the dune build.
After consultation on the core developers' list I am proposing this patch to remove support for compiler plugins.
The main motivations for removing compiler plugins are:
- They are a potential security risk.
- They increase the complexity of the build system and make maintenance of the Dynlink libraries more difficult (although actually, this complexity could probably be reduced after #2268 is merged).
- Many applications of plugins should be able to be expressed by building custom compiler drivers that link against compilerlibs.
* Remove compiler plugins and hooks
* Add new function Dynlink.unsafe_get_global_symbol but keep it outside the documented API.
* Remove otherlibs/dynlink/nodynlink.ml
* Update Changes
Persistent_env is a new module that handles the relation between the
type-checking state and the "persistent" typing information laying in
.cmi files on the filesystem. In particular, it handles the collection
and production of CRC information for the .cmi files being read and
written to the filesystem; the using modules (in our case, only Env)
are in charge of turning the cmi files into higher-level information
(components and signatures).
Persistent_env exposes a type `'a t` of a persistent environment,
which acts as a mutable store of `'a` values. There is no global state
in the module itself: while Env (and thus the OCaml type-checker) uses
a single global persistent environment, it should be possible to
create several independent environments to represent, for example,
several independent type-checking sessions.
- Add a Load_path module which caches files lookup
- Instead of falling back to the external environment, allow to
declare in the environment that a module comes from the external
world. This allows persistent structures to shadows non-persistent
ones
This change should be a refactoring no-op.
Before, a DEPFLAGS variable existed in some makefiles to contain
include directories to be passed to ocamldep invocations, but no
support for easily adding command-line flags to ocamldep was available
(invocations would systematically use -slash, which was duplicated
across callsites).
With this PR, a new DEPINCLUDES variable contains the include
directories, and DEPFLAGS is repurposed to contain other command-line
flags for the tool -- currently "slash".
- The code responsible for printing Syntaxerr errors is moved to the
Parse module (so that it can depend on the variable printer in
Pprintast).
- Pprintast becomes a dependency for a few tools that link some
compiler modules in an ad hoc way (they would better be implemented
in terms of compiler-libs).
In order to prepare the transition to autoconf, this commit moves the
configuration Makefile out of the config directory which will disappear
and gives it the name it will have once intstalled, namely Makefile.config.
I can observe weird performance bottlenecks on my machine caused by
the use of 'cp' in the 'install' scripts of OCaml. When installing
into a directory that is already populated by an existing
installation, 'make install' can routinely take 10s on my machine¹. After this
change it reliably takes 1.5s, independently of whether the
destination is already populated or not.
¹: a brtfs filesystem on an old-ish SSD
Why I care
----------
An extra 10s delay due to 'make install' can be noticeable in tight
change-build-install-test feedback loops for a compiler change where
we change the compiler, have a fast 'make world.opt' due to
incremental builds, install the change and test it -- possibly after
installing a couple opam packages, which can be fairly quick.
Partial diagnosis
-----------------
The performance issue seems to be caused by the fact that 'cp' (at
least the GNU coreutils version), when the file already exists,
replaces it by opening it in writeonly+truncate mode and writing the
file content ('strace' shows that the delay is caused within an
'openat' call). In particular, using the --remove-destination option
(which changes 'cp' to just remove the destination file before
copying) removes the performance issue, but this option seems missing
from the BSD/OSX 'cp' so it could cause portability issue.
Change
------
The present commit rewrites the 'install' targets of all Makefiles to
use the 'install' command instead. 'install' by default gives
executable-like permission to the destination file, instead of reusing
the source file's permissions, so we specify manually the permission
modes, depending on whether the installed file is an executable (or
dynamically-linked library) or just data (including other compiled
object files).
Testing
-------
I checked manually that the permissions of the installed files are
identical to the ones of the current 'cp'-using targets, except for
some '.mli' file in middle_end which currently have +x bits enabled
for no good reason.
Remark: To test this, playing with the DESTDIR variable is very useful
(this lets you install to a new directory (or the same as before)
without having to re-run the configure script). I used the following,
fairly slow shell script to collect permissions:
for f in $(find $DESTDIR); do \
echo $(basename $f) $(ls -l $f | cut -d' ' -f1); \
done | sort
Remark: it is important to run `sync` in-between 'make install' runs
to avoid timing effects due to filesystem or disk caching
strategies. I believe that this corresponds to the natural time delay
(and unrelated disk activity) that would occur in realistic
change-install-test feedback loops.
(Patch by Adrien Nader!)
Several commits ago, I made a change that replaced includes for
"otherlibs/unix" with "otherlibs/$(UNIXLIB)", making it possible to
include "win32unix".
Apparently I forgot to do it for debugger/Makefile or skipped it on
purpose since it only matters for cross-compilation and cross-compiling
the debugger is not supported (yet).
Change it now rather than forget it later.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14164 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
listing more accurate.
Also move the yes_or_no function to it's own module Question to avoid a
module dependency cycle, since Lexer use Parser types and Parser
implementation use Input_handling that defined yes_or_no that use Lexer.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@7767 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Cela corrige le PR#1064.
- Les CRC des modules constituant un programme sont stockes dans
l'executable bytecode, section CRCS. Revu Dynlink pour utiliser ces
CRC au lieu d'attendre de l'utilisateur qu'il les fournisse.
MAJ du debugger en consequence.
- Introduction et utilisation du fichier stdlib/StdlibModules.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@5272 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Gabriel Scherer
David Allsopp
Florian Angeletti
Jeremie Dimino
Sébastien Hinderer
Mark Shinwell
alainfrisch
Xavier Clerc
Nicolás Ojeda Bär
Gabriel Radanne
Runhang Li
Damien Doligez
Wojciech Meyer
Damien Doligez
Xavier Leroy
Nicolas Pouillard
Jacques Garrigue
Daniel de Rauglaudre
Pierre Weis