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