Call the C preprocessor through the C compiler rather than calling it
directly.
This required the definition of a new ocamltest variable,
ocaml_filetype_flag, which makes it possible to override the filetype
inferred by the compiler from the extnesion of the source file.
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>
This commit removes support for gprof-based profiling (the -p option to ocamlopt). It follows a discussion on the core developers' list, which indicated that removing gprof support was a reasonable thing to do. The rationale is that there are better easy-to-use profilers out there now, such as perf for Linux and Instruments on macOS; and the gprof support has always been patchy across targets. We save a whole build of the runtime and simplify some other parts of the codebase by removing it.
Most of the time, the C preprocessor needs to be invoked through the C
compiler, e.g. so that the paths to the header files are resolved properly.
In some cases, though, we really need to be able to call the C
preprocessor directly, just to expand macros in .ml files (this only
happens in the testsuite, at the moment). In those cases, it is
simply impossible to call the C preprocessor through the compiler,
e.g. because this would require the input files to have a '.c'
extension, which the OCaml compiler would misinterprete as meaning this file
should be compiled with the C compiler.
Thus, this commit clarifies the distinction between CPP and DIRECT_CPP
and provides both variables to the build system. The ocamltest build system
is also updated to take advantage of this.
We rely on autoconf's macros to detect how to call the C preprocessor
via the C compiler, except for the MSVC port where its value is hard-coded
to guarantee backward compatibility.
* Delete the deprecated vmthreads library
It was deprecated in 4.08.
* Remove the byte/native argument of init_path
It is no longer necessary.
* Error out when passing --{enable,disable}-vmthreads to ./configure
Signed-off-by: Jeremie Dimino <jeremie@dimino.org>
This patch removes support for 32-bit Darwin (macOS, iOS, etc) targets on Intel hardware. This enables various special cases to be removed in the i386 backend.
The current version of macOS (Mojave) is the last one that will support 32-bit x86 binaries. The current version of iOS does not support execution of 32-bit binaries any more.
Cygwin is based on newlib, not glibc, and the fma function is not
implemented. Split off HAS_WORKING_FMA from HAS_C99_FLOAT_OPS. Disable
fma for Cygwin64 so that the fma test passes.
Note: Typos found with https://github.com/codespell-project/codespell
Here is the (semi-manual) command used to get (and correct) the typos:
$ codespell -i 3 -w --skip=".png,.gif,./ocaml/boot,./ocaml/.git,./ocaml/manual/styles,./ocaml/manual/manual/htmlman" -L minimise,instal,contructor,"o'caml",cristal,pres,clos,cmo,uint,iff,te,objext,nto,nd,mut,upto,larg,exten,leage,mthod,delte,tim,atleast,langage,hten,iwth,mke,contant,succint,methids,eles,valu,clas,modul,que,classe,missings,froms,defaut,correspondance,differents,configury,reachs,cas,approche,normale,dur,millon,amin,oje,transfert
--disable-unix-lib, --disable-vmthreads and --disable-str-lib added to
prevent building these three libraries.
ocamldoc, the debugger and caml-tex are automatically disabled if their
prerequisites are not built. Using --enable-debugger and
--enable-ocamldoc will result in errors if these tools cannot be built.
Adds a fused multiply-add operation to the Float module.
The following changes are made:
- configure: check math.h for the C99 fma() operation.
- fma declarations in float.ml[i] (stdlib/).
- C fma() call or emulation in runtime/floats.c.
- dedicated tests in testsuite/tests/fma.
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.
Before this commit, this C preprocessor macro was defined in
byterun/caml/m.h by the configure script, but just on some architectures
and only in non-PIC mode.
This commit introduces the HAS_ARCH_CODE32 predicate which is inserted
in the m.h file when this is relevant, the ifdef block on PIC
being moved to config.h.
This is to prepare the switch to autoconf, since header files processed
by config.status are not allowed to contain ifdef blocks.
This commit simplifies the configure script by removing the support
for obsolete platforms. The list of removed platforms is documented
in the associated Changes entry.
The mechanism complicates the runtime system and is not very general
(only a few system functions are instrumented). There are other ways
to intercept system calls that are more general and require no
modification to the source code of the runtime system.
- Introduce `-dcamlprimc`, to keep the generated C file containing the primitive list
- Use `-fdebug-prefix-map` for compiling temporary C files when this option is supported
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.
In environments where the executables compiled to native code,
such as ocamlopt.opt, are always used in preference to the bytecode
versions then space can be saved by not installing the latter.
This patch provides a configure option to do such. It is relatively lightly
engineered; in particular, it won't complain if the native code executables
aren't themselves being built; but given this is an option for knowledgeable
users we think that it is reasonable.