don't generate xen configuration files per-unikernel (by default? at all?)

[yomimono]

The main.xl (and main.xl.in, and libvirt.xml) files are currently generated (and any existing ones replaced) on any call to mirage configure -t xen (and also mirage configure -t qubes, which is probably a bug).

I've personally found this to be an annoyance more often than it has been a help even in the case where I am running on a vanilla Xen machine and therefore can use the configuration, which is a rare circumstance. It was helpful to me when I was new to Mirage and Xen (with which I was also unfamiliar) was the only non-UNIX backend, but I think very few people in that situation in 2018CE will be running unikernels on vanilla Xen where the user is in control of dom0 - I think the more common configuration, by far, is running via solo5, QubesOS, or (a distant third) on the public cloud.

Leaving the creation of these files to the user would allow us to simplify lib/mirage.ml considerably.

[samoht]

I agree that these files bring too much clutter and that they are not necessary in general for the experienced user; Maybe adding an option to generate these files on demand would be enough? (e.g. using mirage template)? Or simply put them somewhere on the wiki and add a line in the tool output to reference to that address?

[djs55]

I don't mind if these files aren't autogenerated as long as the docs still explain how to write them and have an example or two. The main thing I find useful about these files is that they remind me of the file syntax which I can never remember.

[hannesm]

how about a mirage stubs <type> (glad for suggestions instead of stubs) subcommand, where <type> may be either libvirt, xl, xe - or left empty to generate all of them. nothing will ever remove these files.

when reworking mirage for the 3.0 release I only for the xen (and maybe qubes) target have these files being generated, and see value in automatically generating these stubs to be modified by the developer at a later point.

[yomimono]

It sounds like something nonspecific would be sufficient. For example, rather than spitting out the header with the unikernel name, to say "put the filename of the compiled unikernel here, e.g. /home/user/myproject/unikernelname.xen". Then stubs (or whatever) can be independent of the configuration.

There's a PR to remove generation entirely for -t qubes at #895 .