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 file is meant to be included by the per-directory makefiles
of otherlibs/*/Makefile; its target cannot be run directly from
otherlibs/. We would like to propose targets from otherlibs/,
in a new Makefile.
* added otherlibs/unix/fsync.c and otherlibs/unix/unix.ml
* add Unix.fsync
* added otherlibs/win32unix/fsync.c
* Unix.fsync for windows
* big typo
* Rewrite Unix.fsync stub for Windows
* belts and braces: fail in the case of named pipe
* Add missing include
* corrected header
* better ocamldoc for fsync
* rm fsync.c from the UNIX_FILES list
* updated Changes for Unix.fsync
* Use _commit instead of FlushFileBuffers
* Include <io.h>
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.
Unix.{in,out}_channel_of_descr now check that descr has stream semantics.
These functions fail if the given file descriptor is not suitable for
character-oriented I/O, e.g. a block device or a datagram socket.
Fixes part of MPR#7238.
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.
This is a follow-up to GPR #997 with a different implementation that creates fewer dependencies.
We add to the runtime a `byterun/bigarray.c` file that contains the bigarray creation functions that used to be in `otherlibs/bigarray/bigarray_stubs.c`. In the latter file we keep all primitives needed to implement the Bigarray interface. The functions in the new `byterun/bigarray.c` make it possible to create bigarrays both from the bigarray library and from the unix library.
The header file `bigarray.h` moves to `byterun/caml/bigarray.h` accordingly.
The `map_file` implementations move to `otherlibs/unix/mmap.c` and `otherlibs/win32unix/mmap.c`. Some bigarray allocation code shared between the two implementations is put in `otherlibs/unix/mmap_ba.c`.
Through a couple of `#ifdef`, the `map_file` implementations can also be compiled from within `otherlibs/bigarray` with the same semantics they had in 4.04.
As a consequence, the bigarray library still contains a standalone, Unix-independent implementation of `Bigarray.*.map_file`; the only difference with 4.04 is that it is marked deprecated.
Current status: compiled and lightly tested under Unix. Win32 implementation neither compiled nor tested.
David Allsopp
Sébastien Hinderer
Gabriel Scherer
Francois Berenger
Xavier Leroy
Xavier Leroy
ygrek
alainfrisch
Damien Doligez
Damien Doligez
Jacques Garrigue