Porting applications strategy

[Norman Feske]

Hello Tomasz,

> After fighting with my lack of knowledge about advanced make usage I've
> managed to prepare a version of noux.mk for a library (without noux
> dependency) and build libunistring - without any source changes. I
> haven't tested it yet though.
> 
> 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.

it is not as simple as that. Actually, it is far too easy to mix things
up. For a structured discussion, I propose to keep different topics
cleanly separated:

1. Integration of 3rd-party code with Genode's genuine code
   (Genode's ports mechanism)
2. Building Genode components (the Genode build system)
3. Introducing the notion of "source code packages" (does not exist
   yet). A source-code package may be structurally similar to what a
   Genode source repository is today, but it would contain 3rd-party
   source code also.
4. Introducing the notion of "binary packages" (does not exist yet).
   A binary package may be similar to what a build directory is
   today, but specific for a certain source-code package and its
   dependencies.
5. Building binary packages out of source packages
6. Deployment of binary packages on top of Genode system
7. Distribution of source and binary packages
8. Updating packages

Apparently, Emery's Nix line of work is primarily concerned about the
last three points. The discussion about the GNU build system vs. the
Genode build system is just a detail of point 5. Of course, it is
possible to wrap the GNU build system as I did with the (arguably ugly)
noux.mk wrapper. But for low-level libraries in particular, it is
sensible to realize their build procedure directly with the Genode build
system to benefit from Genode's inner- and inter-library dependency
tracking and to accommodate work flows where no "packages" are used,
like the run-script-based work flow we use today.

Until May, I'll try to develop a tangible notion of what we understand
as a "source package". Once this is in place, we can move on with the
points 6 to 8. Does this make sense to you? ;-)

Btw, it might be insightful to revisit the previous discussion on the
subject at our issue tracker:

  https://github.com/genodelabs/genode/issues/1082

> I think that using guix and guile could be a better approach due to
> using general purpose language (although not liked too much :-) ) and
> Genode specific requirements, which could be harder to achieve in a
> language dedicated specifically to build packages. But I have to check
> it myself first. If I'm able to have a proof of concept and know more
> about Emery's work I'll try to make some conclusions share them with you
> here.
> 
> libunistring that I compiled is a dependency for guile and compiling it
> is first step in my attempt to check if guix can become package manager
> for Genode.

Interesting. Personally, I do not think that there needs to be one
single way of package management for Genode. What I like about Emery's
work is that he managed to keep even the existence of the Nix mechanism
hidden from the "user". The more we experiment, the better our
understanding of the problem will get. So your initiative is very much
appreciated.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth