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
