Porting applications strategy

Jookia 166291 at ...9...
Thu Feb 25 01:20:03 CET 2016

On Thu, Feb 25, 2016 at 12:45:40AM +0100, emery at ...261... wrote:
> My take on this is that in the future it will be possible to construct 
> Noux environments such that autotools can be run in Noux to produce a 
> native Noux build (and maybe cross-compiling), but the practical thing 
> to do will be to try to and fool existing autotools tests, and only 
> inside Noux.

I think this is a good assumption 
> I do think that Nix can trick autotools into building on Noux, but first
> Noux needs to be faster and I want to find out how far merging file 
> systems can go before hitting the point of diminishing returns.
> On Wed, Feb 24, 2016 at 09:49:01PM +0100, Tomasz Gajewski wrote:
> > 
> > What I think I understand about current Genode build system it consists
> > of two layers:
> > 
> >  * a package manager like layer that maintains dependencies between
> >    programs/libraries
> > 
> >  * build rules for building concrete programs/libraries
> > 
> > Both are implemented using make. I believe (although I haven't verified
> > it) that work of Emery to port nix to Genode is an attempt to replace
> > the former layer with nix.
> Yes, I want to create an alternate layer for dependencies and locating
> the required makefiles. When the package output specification is ready
> then both build systems should produce cross-compatible packages.

> You might be right, sometimes I think that Nix is a bit heavyweight for
> simply generating text files like it often does, but I don't know much
> about Guile.

Guile's a bit more heavyweight I think. However, Guix has the ability to do a
lot of really cool stuff when it comes to build environments- I'm not sure if
Nix has the same support. One interesting thing I've been toying with recently
is the 'build a VM', which has some Guile code to take a derivation and run it
in a VM. I imagine we could have something like that in Noux, then take the
output and use that in Genode. This might be already how you do it though.

> As far as porting Guix, it might look like a good idea to try and 
> make it work on top of Noux, but my experience with Nix was that to 
> fix every required unix-ism will take more time and in the end you 
> will loose some important potential features. It may be possible to 
> reuse my Nix libraries for Guix, but I made some changes that break
> compabality with upstream Nix for the sake of security and content 
> addressing, which you might not agree with.

Guix is based on POSIX-isms which Noux could certainly help out with, currently
there's work to bring HURD support in which is testing Linux-specific
assumptions. It'd be very interesting to survey the assumptions Guix makes for
it's host-side code.

> The build controller component I have actually contains no 'Nix' code
> or libraries, so if Guix can produce the some low-level build recipe
> files, that would deduplicate a lot of work.

Assuming you mean the build controller just runs Bash code, then I imagine it'd
be a problem given instead of using shells to build, Guix uses a well-defined
subset of build-side modules that can run derivations.

> Cheers,
> Emery

More information about the users mailing list