Porting applications strategy

[Tomasz Gajewski]

Josef Söntgen <josef.soentgen at ...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.

-- 
Tomasz Gajewski