[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] [ANN] IPv6 on Mirage!



On 20 Nov 2014, at 15:07, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> 
> It would be useful to know what the problems with using a switch were.
> It would make packaging the TLS stuff easier if we didn't need e.g.
> separate gmp.unix/gmp.xen, ctypes.unix/ctypes.xen, etc packages, when
> the only difference between them is the platform they're compiled for.
> 
> Could the mirage tool manage switches for us?

That's what it did before: mirage ran "opam --switch=<foo> install" and
everything got installed under there.  A few of the problems:

- The pinning workflow is now more complex, since pins are per-switch,
  so for development we had to interrupt an installation under another
  switch in order to prepare it with a pin.

- This is a build system issue, but OASIS' behaviour of caching setup.data
  meant that sometimes the wrong switch would get picked up for a pinned
  package, leading to very confusing cross-switch behaviour.

- Build times are significantly longer with a fresh switch since the
  library chain needs to be rebuilt, especially with lots of 'make clean'
  due to the previous point.

- Editors had to deal with build artifacts showing up under a different
  switch, so tools like annot had to look in unexpected places.

Overall it wasn't entirely terrible, but the current model of making
everything a clean library is a lot more natural to work in a single
switch, and save an alternate switch for global options such as profiling
or debug symbols that have to be activated once.

I also think that the current model is 'keeping us honest' with respect
to portability via functors.  It's awkward in the short term, but I'm
hopeful that as a new generation of package description tools emerge such
as the mythical Assemblage, it will get easier to have more fine-grained
subpackages.

-anil

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.