Porting applications strategy

[Josef Söntgen]

Hello Tomasz,

* Tomasz Gajewski <tomga at ...300...> [2016-02-15 22:59:23 +0100]:
> I would like to be able to do:
> 
> ./configure --host=genode-x86 && make

At the first glance that would be convient indeed but on the second
not so much — mostly because it involves having a build environment
ready, which means having autotools, pkg-config and the like available.
That only works well if your host system is quite POSIXish and if the
distributed autotools files of the program/library in question are
aware of the host target.


> Longer story
> 
> List of compiled sources in libunistring depends on results of running
> configure and there is more than 500 source files. Even if I would
> prepare list of files to compile probably it would be different in next
> revision so it would have to be at least updated during upgrade. I feel
> it would be waste of resources.
> 
> From different perspective as on of the goals of Genode for this year is
> to have more software packages ported I think the procedure to port
> should be as straightforward as possible. Probably most of the ported
> software will be based on libc (I think that packages that will not be
> linked against libc mostly will constitute base of genode not userspace
> programs) and to be able to quickly port libc based libraries and
> applications build system should not replaced but reused.
> 
> My feeling is that current Genode build system is great for Genode
> specific components but for porting general purpose requires too much
> maintenance.

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.


> I don't know detailes underneath current makefiles based build system
> but I imagine steps to compile using configure could look somehow like
> this:
> 
> 1. Prepare spec with dependencies containing libc - just like it is
>    right now
> 
> 2. make deps - build dependencies and install headers somewhere - this
>    is probably done right now in current build system
> 
> 3. Run configure in this prepared environment. Running it without
>    prepared environment fails when testing if genode-x86-gcc can create
>    binaries - so quite quickly :-)
> 
> 4. make - real porting work - hopefully not much
> 
> 5. make install - to some prepared place?
> 
> 6. from installed files take headers in case of libraries and binaries -
>    this somehow works right now

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.


> Firstly I'd like to hear what you think about the idea in
> general.

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 would rather spend my time doing the actual porting work than messing
around with short comings of the original build system or breaking
things for one particular program while fixing the build tools another
one.

The other thing that annoys me about autotools is the fact, that
you would have to run it _every_ time you want compile the source,
although the target system has not changed at all. Sure, we could cache
the result for later use, but… In short, I would rather avoid the
checking and bookkeeping that comes free when using it altogether.


(*) One can argue that this is not the fault of the GNU build system
    itself but rather of the way it certainly is used in the wild.


> Eventually could you provide some technical informations where are the
> most important parts of build system where I should look to be able to
> make such changes?

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.


Regards
Josef