With the hope some opam-monorepo maintainer will read that and have some
time, I just opened https://github.com/tarides/opam-monorepo/pull/407
which puts "ocaml-compiler" into the set of "do not check for dune
compatibility".
I'm afraid I don't know why there's now ocaml-base-compiler 5.3.0,
ocaml-variants 5.3.0, ocaml 5.3.0, and ocaml-compiler 5.3.0.
Hannes
On 10/02/2025 11:12, Hannes Mehnert wrote:
Hi,
On 22/01/2025 18:11, Mindy Preston wrote:
Over the past few months, I have occasionally attempted to build some
MirageOS projects but very frequently I encounter some time-consuming
or work-halting problem with opam-monorepo, often a problem which
seems non-deterministic. I have a few questions:
(1) is this brittle for other people? Perhaps there’s something about
the environments where I’ve tried this (arch linux on aarch64, ubuntu
and a close cousin on x86_64, recent opam, vanilla compiler) that’s
problem-prone? Is it possible that build steps involving
opam-monorepo might cause inconsistent state if interrupted before
completing, which is something I do all the time?
It is brittle for me as well, over the years I opened various issues and
there's not much opam-monorepo activity unfortunately.
The latest issue I encounter is
https://github.com/tarides/opam-monorepo/issues/406 -- and my workaround
was to point my opam repository to something before 5.3:
opam repository set-url default
git+https://github.com/ocaml/opam-repository.git#2e81d1953c37347d78d994b71ede87c5f6f6e207
The running the `make lock pull` showed me some other error I was able
to fix, and voila re-setting my opam-repository to
opam repository set-url default https://opam.ocaml.org
Worked than fine. But as you mention, it is very very brittle. In
combination with very confusing error messages.
(3) I often work on a library and a unikernel that uses it in tandem,
so the `scope` argument to package config is essential, but I had to
go digging in functoria .mli’s to find it. Is there documentation that
I should have read about this? If so, I will go read it and maybe that
will enlighten me.
I never use the "scope" argument.
I’ve also tripped over things that are already in issue trackers like
‘mirage clean’ not cleaning out the duniverse directory and the
current problem with OCaml 5.3.0 not being usable at all. After
looking into the latter problem, I’m worried about the maintenance
status of `opam-monorepo` and the `opam-overlays` repository it uses.
The last commits were some time ago for both repositories, and it
doesn’t look like there are replies to recent issues and PRs.
True. Sad story.
Maybe time to find a different path. All we need is customly-built C
stubs -- no need for recompiling all OCaml code for a unikernel.
Eventually there are better ways than this "opam-monorepo". (Hint:
there's
https://github.com/mirage/ocaml-solo5/pull/144/commits/3eb1861fad33abc895a581521cd20d77247a0bf9 paving the way... but we still need some mechanism to tag packages that require building with the MirageOS/OCaml C cross-compiler.)
Of course, help (in terms of bugfixes, triaging issues, updating the
dune-opam-overlays) are very welcome.
Hannes
