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

development story - the "unikernel as sample" in the same git repository as an opam package #1497

Open
hannesm opened this issue Feb 5, 2024 · 2 comments

Comments

@hannesm
Copy link
Member

hannesm commented Feb 5, 2024

Sometimes, unikernels are hosted side-by-side (in the same git repository) with opam package used by the unikernel.

I wasn't able to figure out a concise user story how such a development should be done...

Most recent experiments / discussion at robur-coop/caldav#34 (comment) - earlier discussion at mirage/mirage-crypto#166 and #1346

Suggestions from earlier discussions are to use mirage configure -f mirage/config.ml -- but I've no clue where (in the caldav repository) the Makefile is generated (the repository contains a top-level Makefile, and mirage (4.4.1) doesn't seem to overwrite it, or put the Makefile elsewhere) -- any hints are welcome.

For mirage-crypto, we embed a version number into opam files to get around lower/upper bounds generated by the mirage tool (see .test-mirage.sh).

For miragevpn, we copy the source manually to the duniverse -- this works mostly (but dependencies modified in a PR are not taken into consideration, since only the main repo opam file is used for dependency computations - see .cirrus.yml in the miragevpn repo).

Am I the only one encountering this issue?

@samoht
Copy link
Member

samoht commented Mar 18, 2024

My workflow is to use a mirage configure -f <path>/config.ml at the root of the repo (where I want to create the duniverse folder). I'm using a custom Makefile (which is not overwritten by the tool, as it checks if it has the right header to do so).

But that workflow could be better. I'm trying to work (slowly) on #1495 to clarify what is modifying the root files (like dune-project, dune-workspace, Makefile) vs what the files which are dependent on the project being built. I think I start to have a better idea on how to do this properly, patches will come out slowly.

What would be your ideal workflow?

@hannesm
Copy link
Member Author

hannesm commented Mar 19, 2024

I guess the issue is "have an opam package and unikernel(s) in the same repository".

The workflow should be something that is failsafe and works in all repostiories. Please take a look at the caldav issue opened by Armael, and have a try at "mirage configure -t mirage/config.ml", running into all sorts of issues (Makefile exists, thus make doesn't work; dune-project exists and specifies a version too low for dune; the caldav opam package is taken from opam instead of the repository itself).

At the time being, all I understand is "please do not embed unikernels within opam package repositories, but split them" -- to avoid various issues mentioned above.

Another complication is once a unikernel is compiled (with a duniverse directory), I encounter issues with dune build of the opam package since now stuff from duniverse is taken for the package build.

I don't have any solution, just questions on whether the situation in caldav, mirage-crypto, miragevpn can be improved? Or whether such a workflow can't be supported due to how things with dune and mirage work.

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

No branches or pull requests

2 participants