Josef Söntgen <josef.soentgen@...1...> writes:
You have to maintain the build system either way. Since all of the projects using autotools are not aware of Genode you have to patch the various scripts, makefiles or m4 macros files to recognize it or rather you have to execute autoreconf — if the project even ships its .ac files — or replace the distributed files directly. Futhermore, nowadays pkg-config is used to query certain dependencies, so you have to provide the pkg-config database and to manage the .pc files as well.
In theory autoconf tests should test for features not for systems although reality is probably different.
I am not sure if that really saves you much time in the long run. Providing a mechanism that integrates well with the Genode build system is one thing. Making this mechanism useable by a majority of GNU build tool based build systems so that you can conviently just execute 'configure', is something completely different.
I understand your points but I can't imagine another way than incrementally adding support for different build systems/engines. Maybe I'm too much influenced by existing linux package systems though, where they use "native" packages' build systems.
To be honest I personally do not think that its such a good idea but that is mostly based on my past experience in dealing with autotools. Been there done that while using the OpenBSD ports system and when porting programs to Haiku — everytime I had to use autotools on a system that was unknown or slightly different than the status quo, e.g. GNU/Linux, it was uncomfortable to say the least(*). And I do not expect it be any different in this case.
I know that plenty of packages will not build on such system without modifications but what is the alterntaive? I believe that even maintaining lists of source files for some greater number of packges is infeasible. And maybe I'm naive but fixes for autoconf tests could be merged into source packages but Genode specific patches definitely not.
There is _repos/ports/mk/noux.mk_ which basically is a wrapper around the autotools suite for building noux-pkgs of programs that use it from within the Genode build system. This wrapper creates an environment that contains the important compiler options and flags to build the program for running in Noux. If you start from there and make your way along to _repos/base/mk_ you will hit the most important parts.
That was really the information that I needed. Thank you.
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.
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.