It's the macOS default installed version still. The dependency generation
inadvertently relies on behaviour introduced in GNU make 3.82 a decade ago.
The fix in otherlibs/systhreads/Makefile also corrects missing
NATIVE_CPPFLAGS when generating st_stubs.n.d, so st_stubs.n.o now
correctly depends on caml/stacks.h instead of caml/stack.h
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.
This commit deduplicates some of the Makefile rules used to compile C files.
Rather than having one such rule per Makefile for each directory
containing C files, the relevant rules are moved to Makefile.common.in.
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).
This commit renames a few C compiler related build variables so that
they are reserved for the build system. They will then be re-introduced,
but this time as user varialbes whose value can be freely customized
when compiling the package, without risking to conflict with those
command-line flags that are required by the build system itself.
Here are the variables this commit renames:
- CFLAGS -> OC_CFLAGS
- CPPFLAGS -> OC_CPPFLAGS
- LDFLAGS -> OC_LDFLAGS
Note: before this commit the compilation of scheduler.c in
otherlibs/threads was relying on make's implicit rule to compile C files.
Since this commit stops using the standard variables for flags,
it is necessary to introduce an explicit rule to compile C files
and that makes use of the newly introduced variables.
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.
The CPP variable tells the build system how to invoke the C preprocessor.
Before this commit, this variable was defined by the Windows Makefiles
but not by the Makefile generated by configure. This commit fixes this.
This commit also fixes a few makefiles: to compute dependencies for C files,
they incorrectly called $(CPP) -MM instead of $(CC) -MM.
Before this commit, the dependencies computed for st_stubs were
useless because they were generated for st_stubs.o whereas what is actually
built is st_stubs_b.o and st_stubs_n.o.
ocamlmklib produces bytecode dynamic link libraries for the threads
library but these are (intentionally) not installed.
The cleaning of them got lost in the merge of the two build systems.
Before this commit, it was not possible to build the object files for
st_stubs_b and st_stubs_n in parallel, because both builds were performed
by first building an st_stubs object file and then renaming it, resulting
in a filename clash in case of parallel build.
This commit fixes this situation by giving the C compiler the right options
so that object files are created with the right name from the beginning
and do not need to be renamed afterwards.
* Make sure the PTHREAD_CAML_LINK variable is defined everywhere.
* Merge makefiles in otherlibs/systhreads
Before this commit, the .cma and .cmxa libraries were linked using -linkall
under Windows but not under Unix.
It was not possible to clarify why -linkall was useful, but given the small
size of the involved modules and the fact that, for most modules, it
does not seem to make much sense to use one without the others, it has been
decided to use -linkall everywhere.
This commit also stops building the .cmxs shared library under Windows, for
consistency reasons (it was built only under Windows before).
- Removed MacOS X support, long dead.
- Added support for PowerPC 64 bits, big-endian, ELF v1 ABI
(tested, mostly works, some issues remain with marshaling of code pointers)
- Added support for PowerPC 64 bits, little-endian, ELF v2 ABI
(completely untested)
git-svn-id: http://caml.inria.fr/svn/ocaml/branches/ppc64@16226 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02