Skip to content

Comments

feat(pkg): relocatable compiler support#13321

Draft
Alizter wants to merge 7 commits intoocaml:mainfrom
Alizter:push-ssmqlovpkqol
Draft

feat(pkg): relocatable compiler support#13321
Alizter wants to merge 7 commits intoocaml:mainfrom
Alizter:push-ssmqlovpkqol

Conversation

@Alizter
Copy link
Collaborator

@Alizter Alizter commented Jan 15, 2026

This PR adds a way for us to detect if a compiler in our "package universe" is relocatable. Knowing this means we can avoid the use of our toolchains functionality and instead build the compiler like a regular package.

The current chosen heuristic for knowing so is by inspecting if we have the reloctable-compiler meta-package available (for interoperability with David's relocatable opam repository) or by checking the compiler version to be 5.5, the next release of the compiler which is relocatable.

We add a test checking the checking behaviour and making sure that compiler-like packages are able to be cached in these cases.

To try it out for yourself, put the following in dune-workspace:

(repository
 (name dra27-relocatable)
 (url "git+https://github.com/dra27/opam-repository.git#relocatable"))

(lock_dir
 (repositories dra27-relocatable :standard))

@Alizter Alizter mentioned this pull request Jan 15, 2026
10 tasks
Alizter referenced this pull request Jan 15, 2026
According to [1] and [2], `build-id` is a SHA256 hash identifying the
precise package version with all its dependencies.

Consumers of this variable, such as the process.sh script in [3], use
this to identify specific packages in existing opam switches. In [3]
this is used to find an already-built relocatable OCaml compiler.

In dune we wish to re-use [3] for choosing the relocatable compiler,
therefore we need to substitute the value with something that will not
be picked up as a hash from an existing opam valuation of build-id.

For now we choose a magic number that is easily recognizable in case
anything needs to be debugged.

[1]
https://github.com/ocaml/opam/blob/master/src/state/opamPackageVar.ml
[2]
https://github.com/ocaml/opam/wiki/Spec-for-Extended-package-specific-variables
[3] https://github.com/dra27/opam-repository/tree/relocatable

Addressing relevant concern in:
- #13229
@Alizter Alizter force-pushed the push-ssmqlovpkqol branch 5 times, most recently from 96d4bac to eaaebab Compare January 26, 2026 10:22
@Alizter Alizter force-pushed the push-ssmqlovpkqol branch 3 times, most recently from b604e28 to 4fcca47 Compare February 3, 2026 00:34
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
When a package is absent from the solution, its 'installed' variable is
known to be false. This change evaluates it at solve time in both filter
contexts and string interpolation contexts, enabling further simplification.

Signed-off-by: Ali Caglayan <alizter@gmail.com>
…solve time

Extends the absent package variable evaluation to also handle 'pinned' and
'enable' variables, which are also false for absent packages.

Also skips wrapping constant filters with catch_undefined_var since they
cannot throw undefined variable exceptions.

Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
Signed-off-by: Ali Caglayan <alizter@gmail.com>
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