Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-test #17

Open
wants to merge 14 commits into
base: merge-base-5.2.1
Choose a base branch
from
Open

Auto-test #17

wants to merge 14 commits into from

Conversation

shym
Copy link
Owner

@shym shym commented Nov 26, 2024

No description provided.

shym added 14 commits November 26, 2024 11:41
* Add missing `defined` in preprocessor test

When `HAS_CLOCK_GETTIME_NSEC_NP` is not defined,
`#elif HAS_CLOCK_GETTIME_NSEC_NP` triggers a warning

* Include `caml/config.h` before `HAS_GETTIMEOFDAY` is tested

Also remove a duplicate `errno.h`
When building a cross-compiler, the runtime will run on the target, not
the host so:
- set `cross_compiling` by comparing `build` to `target` (rather than to
  `host`), as this variable will be used later
- use `target` to set up the tool prefix,
- as the libtool configuration will configure a `build` to `host`
  toolchain, temporarily assign `host*` values to `target*` values
Instead of using `strip` unconditionally to build `tmpheader.exe`, use
the `strip` command detected by `libtool` during configure so that it is
replaced with `:` when the command is absent and it becomes easy to
override it if need be
GNU strip can be called safely on binaries generated by cl as well as by
MinGW GCC (even if it doesn't produce a smaller executable for
cl-generated binaries) so invoke strip also on Windows so that MinGW
binaries are properly stripped
Tested with GNU strip 2.42
Allow the use of *-*-ocaml or *-*-*-ocaml target triplets to stand for
freestanding cross-compilers by temporarily rewriting the target OS to
`none` when generating the canonical target

This allows to use *-*-ocaml and *-*-*-ocaml prefixes for cross-compiler
specific toolchains, so that all the specific tools (for instance
aarch64-solo5-ocaml-gcc, etc.) are automatically discovered
Make sure that we don't detect zstd on build when we are building a
cross-compiler, as the native zstd has no reason to be compatible with
the cross toolchain
Define cross.opt and cross-install targets

FIXME: Problems of inconsistencies between compilation options (only
about zstd?) between the native toolchain and the cross toolchain may
break the build?
Solo5 is single-core with no scheduler, so avoid the useless memory
waste

Note that since PR#13272 the maximum number of domains can set using a
parameter in OCAMLRUNPARAM so `getenv` might be a better place to set
this limit in the future
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant