09:38 <mato> dmj`: The virtio.pc file not getting created would happen if you're not building virtio for some reason. That can happen if you're either doing only "make ukvm", or if configure.sh is busted for some reason (check what's in Makeconf, you should have BUILD_VIRTIO=yes in there).

09:39 <mato> dmj`: FWIW, Solo5 is not really set up to be used out-of-tree other than in the context of OPAM, so not sure there's much point in packaging it at the moment.

14:41 <dmj`> mato: hmm, I believe I see a BUILD_VIRTIO=yes… there’s quite a few “make -C”’s I see. Here is the build output, the make’s called, and the resulting tree of build outputs.

14:41 <dmj`> https://gist.github.com/dmjio/f91dbf0a8c2aee4cf5d04439bd14cf94#gistcomment-2068761

14:41 <dmj`> The second comment has all the calls to “make -C"

14:43 <dmj`> mato: cat’ing Makeconf shows

14:43 <dmj`> https://www.irccloud.com/pastebin/KIuQ08Kr/

14:46 <mato> dmj`: Oh, hang on, I misread what you were asking. You're after the '.pc' files? What for? Those are only intended to be used from OPAM at the moment.

14:47 <mato> dmj`: If you look at the solo5-kernel-xxx.opam files, you'll see that they call "make opam-xxx-install" which are the targets that create those files.

14:55 <dmj`> mato: well, the Cabal library uses pkg-config to find compilation / linker options. But if not available, we can just use c-sources and include-dirs

14:55 <dmj`> I just wasn’t sure really

14:56 <dmj`> And the solo5 build initially failed until I commented out the pkgconfg portion, but I didn’t want to lose any valuable info

15:01 <dmj`> was curious is uvkm should be in a separate repo altogether

15:02 <dmj`> s/is/if

15:03 <mato> dmj`: As I said before, Solo5 (and ukvm) are not currently set up to be used out-of-tree in any other way than via OPAM (for MirageOS).

15:04 <mato> dmj`: This will/can of course change if there's a use case (other downstream consumers), but that doesn't exist right now so it's (IMO) kind of pointless to address it in a vacuum.

15:05 <mato> dmj`: As for ukvm moving to a separate repository, there are no plans for that right now as the guest (Solo5) and monitor (ukvm) are tightly coupled right now.

15:05 <mato> dmj`: And I definitely don't want to deal with a proliferation of repositories there.

15:22 <dmj`> mato: Totally agree, multiple repositories are never fun to deal with. In all honesty, I think the .pc file /should/ be getting generated with a call to “make -C virtio” (line 71 of GNUMakefile). So maybe I can play with it more to see as to why it’s not.

15:23 <dmj`> Supporting downstream consumers seems to be a chicken and egg problem then. This should be good enoug though.

15:24 <mato> dmj`: The reason the .pc files are not getting generated by the default build is because they are currently intended for OPAM use only.

15:24 <mato> (i.e. not a bug)

15:29 <mato> dmj`: ... I've no idea if the .pc files will work outside of the context they're being used by OPAM/MirageOS for. So, not wanting to discourage you but I don't think there's much point in installing those. You'd also have to install the other artifacts, and again that only makes sense if there's a downstream consumer that uses them to test against.

15:34 <dmj`> Ok cool, I'm not really familiar with opam. For now I'll omit them.

15:34 <dmj`> mato:^

15:39 <dmj`> But I'm still going to try and use them to see what happens, just cause