2016-02-18 07:11:59 -08:00
|
|
|
#**************************************************************************
|
|
|
|
|
#* *
|
|
|
|
|
#* OCaml *
|
|
|
|
|
#* *
|
|
|
|
|
#* Xavier Leroy, projet Cristal, INRIA Rocquencourt *
|
|
|
|
|
#* *
|
|
|
|
|
#* Copyright 1999 Institut National de Recherche en Informatique et *
|
|
|
|
|
#* en Automatique. *
|
|
|
|
|
#* *
|
|
|
|
|
#* All rights reserved. This file is distributed under the terms of *
|
|
|
|
|
#* the GNU Lesser General Public License version 2.1, with the *
|
|
|
|
|
#* special exception on linking described in the file LICENSE. *
|
|
|
|
|
#* *
|
|
|
|
|
#**************************************************************************
|
2007-11-06 07:16:56 -08:00
|
|
|
|
2016-03-12 20:52:55 -08:00
|
|
|
# Common Makefile for otherlibs
|
|
|
|
|
|
|
|
|
|
ROOTDIR=../..
|
2020-04-17 05:53:49 -07:00
|
|
|
include $(ROOTDIR)/Makefile.common
|
2019-07-28 02:36:38 -07:00
|
|
|
include $(ROOTDIR)/Makefile.best_binaries
|
2018-03-29 05:38:33 -07:00
|
|
|
|
2016-03-12 20:52:55 -08:00
|
|
|
CAMLRUN ?= $(ROOTDIR)/boot/ocamlrun
|
|
|
|
|
|
2019-07-28 02:36:38 -07:00
|
|
|
CAMLC := $(BEST_OCAMLC) -nostdlib -I $(ROOTDIR)/stdlib
|
|
|
|
|
CAMLOPT := $(BEST_OCAMLOPT) -nostdlib -I $(ROOTDIR)/stdlib
|
|
|
|
|
|
2018-06-20 04:39:09 -07:00
|
|
|
OC_CFLAGS += $(SHAREDLIB_CFLAGS) $(EXTRACFLAGS)
|
2020-05-01 02:13:14 -07:00
|
|
|
OC_CPPFLAGS += -I$(ROOTDIR)/runtime $(EXTRACPPFLAGS)
|
2007-11-06 07:16:56 -08:00
|
|
|
|
2016-03-12 20:52:55 -08:00
|
|
|
# Compilation options
|
2016-08-01 07:06:59 -07:00
|
|
|
COMPFLAGS=-absname -w +a-4-9-41-42-44-45-48 -warn-error A -bin-annot -g \
|
|
|
|
|
-safe-string -strict-sequence -strict-formats $(EXTRACAMLFLAGS)
|
2020-06-17 00:29:56 -07:00
|
|
|
MKLIB=$(CAMLRUN) $(ROOTDIR)/tools/ocamlmklib$(EXE)
|
2016-03-12 20:52:55 -08:00
|
|
|
|
2019-04-28 01:09:51 -07:00
|
|
|
# Variables that must be defined by individual libraries:
|
|
|
|
|
# LIBNAME
|
|
|
|
|
# CAMLOBJS
|
|
|
|
|
|
|
|
|
|
# Variables that can be defined by individual libraries,
|
|
|
|
|
# but have sensible default values:
|
|
|
|
|
COBJS ?=
|
|
|
|
|
EXTRACFLAGS ?=
|
2020-05-01 02:13:14 -07:00
|
|
|
EXTRACPPFLAGS ?=
|
2019-04-28 01:09:51 -07:00
|
|
|
EXTRACAMLFLAGS ?=
|
|
|
|
|
LINKOPTS ?=
|
|
|
|
|
LDOPTS ?=
|
|
|
|
|
HEADERS ?=
|
2016-03-12 20:52:55 -08:00
|
|
|
CMIFILES ?= $(CAMLOBJS:.cmo=.cmi)
|
|
|
|
|
CAMLOBJS_NAT ?= $(CAMLOBJS:.cmo=.cmx)
|
|
|
|
|
CLIBNAME ?= $(LIBNAME)
|
|
|
|
|
|
2019-02-25 07:47:18 -08:00
|
|
|
ifeq "$(COBJS)" ""
|
|
|
|
|
STUBSLIB=
|
|
|
|
|
else
|
|
|
|
|
STUBSLIB=lib$(CLIBNAME).$(A)
|
|
|
|
|
endif
|
|
|
|
|
|
2018-06-03 00:04:48 -07:00
|
|
|
.PHONY: all allopt opt.opt # allopt and opt.opt are synonyms
|
2019-02-25 07:47:18 -08:00
|
|
|
all: $(STUBSLIB) $(LIBNAME).cma $(CMIFILES)
|
2016-03-12 20:52:55 -08:00
|
|
|
|
2019-02-25 07:47:18 -08:00
|
|
|
allopt: $(STUBSLIB) $(LIBNAME).cmxa $(LIBNAME).$(CMXS) $(CMIFILES)
|
2018-06-03 00:04:48 -07:00
|
|
|
opt.opt: allopt
|
2016-03-12 20:52:55 -08:00
|
|
|
|
|
|
|
|
$(LIBNAME).cma: $(CAMLOBJS)
|
2019-02-25 07:47:18 -08:00
|
|
|
ifeq "$(COBJS)" ""
|
|
|
|
|
$(CAMLC) -o $@ -a -linkall $(CAMLOBJS) $(LINKOPTS)
|
|
|
|
|
else
|
2016-03-12 20:52:55 -08:00
|
|
|
$(MKLIB) -o $(LIBNAME) -oc $(CLIBNAME) -ocamlc '$(CAMLC)' -linkall \
|
|
|
|
|
$(CAMLOBJS) $(LINKOPTS)
|
2019-02-25 07:47:18 -08:00
|
|
|
endif
|
2016-03-12 20:52:55 -08:00
|
|
|
|
|
|
|
|
$(LIBNAME).cmxa: $(CAMLOBJS_NAT)
|
2019-02-25 07:47:18 -08:00
|
|
|
ifeq "$(COBJS)" ""
|
|
|
|
|
$(CAMLOPT) -o $@ -a -linkall $(CAMLOBJS_NAT) $(LINKOPTS)
|
|
|
|
|
else
|
2016-03-12 20:52:55 -08:00
|
|
|
$(MKLIB) -o $(LIBNAME) -oc $(CLIBNAME) -ocamlopt '$(CAMLOPT)' -linkall \
|
|
|
|
|
$(CAMLOBJS_NAT) $(LINKOPTS)
|
2019-02-25 07:47:18 -08:00
|
|
|
endif
|
2016-03-12 20:52:55 -08:00
|
|
|
|
2019-02-25 07:47:18 -08:00
|
|
|
$(LIBNAME).cmxs: $(LIBNAME).cmxa $(STUBSLIB)
|
2018-09-06 07:12:42 -07:00
|
|
|
$(CAMLOPT_CMD) -shared -o $(LIBNAME).cmxs -I . $(LIBNAME).cmxa
|
2016-03-12 20:52:55 -08:00
|
|
|
|
|
|
|
|
lib$(CLIBNAME).$(A): $(COBJS)
|
2018-09-06 07:12:42 -07:00
|
|
|
$(MKLIB_CMD) -oc $(CLIBNAME) $(COBJS) $(LDOPTS)
|
2016-03-12 20:52:55 -08:00
|
|
|
|
|
|
|
|
install::
|
|
|
|
|
if test -f dll$(CLIBNAME)$(EXT_DLL); then \
|
2018-03-29 05:24:51 -07:00
|
|
|
$(INSTALL_PROG) \
|
makefiles: use 'install' instead of 'cp' in 'make install' targets
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.
2018-03-28 08:46:34 -07:00
|
|
|
dll$(CLIBNAME)$(EXT_DLL) \
|
|
|
|
|
"$(INSTALL_STUBLIBDIR)/"; \
|
|
|
|
|
fi
|
2019-02-25 07:47:18 -08:00
|
|
|
ifneq "$(STUBSLIB)" ""
|
|
|
|
|
$(INSTALL_DATA) $(STUBSLIB) "$(INSTALL_LIBDIR)/"
|
2016-03-12 20:52:55 -08:00
|
|
|
cd "$(INSTALL_LIBDIR)"; $(RANLIB) lib$(CLIBNAME).$(A)
|
2019-02-25 07:47:18 -08:00
|
|
|
endif
|
2018-05-14 00:15:44 -07:00
|
|
|
|
|
|
|
|
$(INSTALL_DATA) \
|
|
|
|
|
$(LIBNAME).cma $(CMIFILES) \
|
|
|
|
|
"$(INSTALL_LIBDIR)/"
|
|
|
|
|
ifeq "$(INSTALL_SOURCE_ARTIFACTS)" "true"
|
2018-03-29 05:24:51 -07:00
|
|
|
$(INSTALL_DATA) \
|
2018-05-14 00:15:44 -07:00
|
|
|
$(CMIFILES:.cmi=.mli) \
|
makefiles: use 'install' instead of 'cp' in 'make install' targets
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.
2018-03-28 08:46:34 -07:00
|
|
|
$(CMIFILES:.cmi=.cmti) \
|
|
|
|
|
"$(INSTALL_LIBDIR)/"
|
2018-05-14 00:15:44 -07:00
|
|
|
endif
|
2016-03-12 20:52:55 -08:00
|
|
|
if test -n "$(HEADERS)"; then \
|
2018-03-29 05:24:51 -07:00
|
|
|
$(INSTALL_DATA) $(HEADERS) "$(INSTALL_LIBDIR)/caml/"; \
|
makefiles: use 'install' instead of 'cp' in 'make install' targets
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.
2018-03-28 08:46:34 -07:00
|
|
|
fi
|
2016-03-12 20:52:55 -08:00
|
|
|
|
|
|
|
|
installopt:
|
2018-03-29 05:24:51 -07:00
|
|
|
$(INSTALL_DATA) \
|
makefiles: use 'install' instead of 'cp' in 'make install' targets
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.
2018-03-28 08:46:34 -07:00
|
|
|
$(CAMLOBJS_NAT) $(LIBNAME).cmxa $(LIBNAME).$(A) \
|
|
|
|
|
"$(INSTALL_LIBDIR)/"
|
2016-03-12 20:52:55 -08:00
|
|
|
cd "$(INSTALL_LIBDIR)"; $(RANLIB) $(LIBNAME).a
|
|
|
|
|
if test -f $(LIBNAME).cmxs; then \
|
2018-03-29 05:24:51 -07:00
|
|
|
$(INSTALL_PROG) $(LIBNAME).cmxs "$(INSTALL_LIBDIR)/"; \
|
makefiles: use 'install' instead of 'cp' in 'make install' targets
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.
2018-03-28 08:46:34 -07:00
|
|
|
fi
|
2016-03-12 20:52:55 -08:00
|
|
|
|
|
|
|
|
partialclean:
|
|
|
|
|
rm -f *.cm*
|
|
|
|
|
|
|
|
|
|
clean:: partialclean
|
|
|
|
|
rm -f *.dll *.so *.a *.lib *.o *.obj
|
2020-04-17 06:11:22 -07:00
|
|
|
rm -rf $(DEPDIR)
|
2016-03-12 20:52:55 -08:00
|
|
|
|
2020-04-17 06:11:22 -07:00
|
|
|
.SUFFIXES: .ml .mli .cmi .cmo .cmx
|
2016-03-12 20:52:55 -08:00
|
|
|
|
|
|
|
|
.mli.cmi:
|
|
|
|
|
$(CAMLC) -c $(COMPFLAGS) $<
|
|
|
|
|
|
|
|
|
|
.ml.cmo:
|
|
|
|
|
$(CAMLC) -c $(COMPFLAGS) $<
|
|
|
|
|
|
|
|
|
|
.ml.cmx:
|
|
|
|
|
$(CAMLOPT) -c $(COMPFLAGS) $(OPTCOMPFLAGS) $<
|
|
|
|
|
|
2020-04-17 06:11:22 -07:00
|
|
|
ifeq "$(COMPUTE_DEPS)" "true"
|
|
|
|
|
ifneq "$(COBJS)" ""
|
|
|
|
|
include $(addprefix $(DEPDIR)/, $(COBJS:.$(O)=.$(D)))
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
$(DEPDIR)/%.$(D): %.c | $(DEPDIR)
|
|
|
|
|
$(DEP_CC) $(OC_CPPFLAGS) $< -MT '$*.$(O)' -MF $@
|
