You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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?
The text was updated successfully, but these errors were encountered: