Hello Tomasz,
* Tomasz Gajewski <tomga@...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:
Prepare spec with dependencies containing libc - just like it is right now
make deps - build dependencies and install headers somewhere - this is probably done right now in current build system
Run configure in this prepared environment. Running it without prepared environment fails when testing if genode-x86-gcc can create binaries - so quite quickly :-)
make - real porting work - hopefully not much
make install - to some prepared place?
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