When building for the first time, the only requirement is that generated
header files have been built (jumptbl.h, version.h and opnames.h).
Detailed dependency information is only required when headers have been
edited.
COMPUTE_DEPS in Makefile.config controls whether C dependency
information should be generated on a per-file basis. This variable is
controlled by a new --disable-dependency-generation in configure which
is enabled for Git checkouts and disabled for tarballs (i.e. releases).
The Microsoft C compiler (cl) cannot generate dependencies in a
consistent way which we can consume, so for a Git checkout configure
searches for an additional C compiler in order to compute dependencies.
This is obviously not required for a user-build.
As a result, the MSVC port can now safely run make alldepend, since only
OCaml dependency information is committed to the repo after this change.
CI does not need to waste time testing the dependency information,
because it only tests a single build. A single Travis job has been added
which tests the build system code to generate the dependency information
(and provides a single `make -j` run in CI, although Inria's CI also
tests parallel building continuously).
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.
The odoc_fhtml file required by this test seems to have been part of
the ocamldoc distribution sometime in the distant past (see
27934ab79a from 2002) but I can't find
traces of it in the git history of the compiler distribution.
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.
The Graphics library is now distributed as a separate package.
The sources are at https://github.com/ocaml/graphics .
Signed-off-by: Jeremie Dimino <jeremie@dimino.org>
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.
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".
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.
Some Makefiles were using export to set OCAML_FLEXLINK "globally" while
others set a variable FLEXLINK_ENV and set the environment explicitly.
All Makefiles now use FLEXLINK_ENV and also only invoke it on linking
commands (rather than, for example, all invocations of ocamlopt).
- inline Pervasives in Stdlib and re-add Pervasives as a deprecated
module that aliases all elements of Stdlib except the stdlib modules.
- remove special case for Stdlib.Pervasives in printtyp.ml
The error comes from #1680, which changed the install scripts for
ocamldoc, and was caught and reported by Valentin "sliquister"
Gatien-Baron, presumably as part of his own work on #1569.
This is the trunk counterpart of #1877 in 4.07, commit
9c9be40f9b6c55646e8f60ee7b5448c80eaa206f
Some makefiles (lex, stdlib, otherlibs) would only offer allopt, while
others (ocamldoc, tools) only offered opt.opt. It is inconvenient to
have to remember which target name to use while going through various
repositories.
The target names for the 'man' and 'html' files are
stdlib_{html,man}/Stdlib.{3o,html}
but these files are never produced by the corresponding rules,
so the rule is re-run on each "make world.opt".
This patch changes these target names to Pervasives.{3o,html}, which
is an actual file produced by the build. It is not fully clear to me
whether the authors of the original rule intended to also produced
documentation for a joint Stdlib module.
Before this patch, running "make world.opt" in an already-built directory
would take 10s on my machine. Now it takes 2s.
(no change entry needed)
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.
David Allsopp
Gabriel Scherer
Jacques Garrigue
Sébastien Hinderer
Nicolás Ojeda Bär
Mark Shinwell
Jérémie Dimino
Florian Angeletti
Damien Doligez
Jeremie Dimino