Roadmap 2021

Tomasz Gajewski tomga at
Tue Dec 22 19:51:49 CET 2020

Norman Feske <norman.feske at> writes:

> Even though there was a brief period of activity when Stefan made some
> progress, the topic [1] became stale again. I understand the slip of
> motivation. Even though I have enabled the Rpi (including working USB)
> originally, I would not consider picking it up again in my spare time.
> I'm sorry that the support from our side was insufficient for you to
> carry on. Unfortunately, I doubt that 2021 will look much different.
> [1]

I know the situation. And issue number looks familiar to me :-)

>> During this process once again I realized why I don't like build
>> system based on make and especially after I found out that recursive
>> make in case of Genode build system can be written with capitalized
>> "R" in recursive :-).
> Please let me address the statement regarding "recursive make" in
> Genode.
> What is commonly referred to as a unholy practice "recursive make" is
> the use of Makefiles scattered throughout a directory structure where
> the Makefile of the parent directory triggers the Makefiles of the
> child directories. Genode's build system does not do that. The
> instances of make spawned by the build system serves different and
> orthogonal purposes.
> - The frontend (Makefile in the build directory) consumes the build
>   configuration and triggers lib-dependency stage, the builds, and the
>   invocation of run scripts.
> - The library-dependency stage traverses target description files
>   without building anythin, to construct a library-dependency graph.
>   This could strictly be taken as an example of "recursive make" if
>   we decided to split hairs.
> - Orchestration of the library and target builds (executing the
>   library-dependency graph, which happens to be a Makefile).
> - Library build, building a single library.
> - Target build, building a single target.

Thank you for this description (although I already gathered knowledge
about this part). Adding run tool to this picture makes this picture a
little more "recursive" :-). Actually removing recursive interplay
between the run tool and build system is something I'd like to remove
but I don't know how and this will be a topic for discussion later.

> If you add the depot tools to the picture, this story continues
> because the depot tools are, well, based on make and invoke Genode's
> make-based build system.

I assume that it is similar to case with run tool but I'll know when I
get to it.

> Make is a can of worms, no question. Please excuse my polemics, but
> this argument can go towards all kinds of power tools [2]. ;-)
> [2]

I'll definitely read it. It looks very interesting.

> If I understand these points correctly, you are actually not after
> replacing Genode's build system but rather supplementing scons as
> another option? That would side-step the friction I feared, which
> would be pretty cool.

Generally roadmap is not a good place to actually anounce and discuss it
but I was kind of forced to do it here.

Generally I really, really like the consistency of definitions of
libraries and programs in Genode and my idea is to make it even more
strict with scons. After I release some initial version I'll start
discussion about some issues I found. But for a start - were you aware
that current build system forgives errors like in [1] :-)

>> I hope to finish those parts quickly and make it public this year.
> I'm looking forward to try it out.


>> Plans for next year
>> I plan to further develop build system based on scons at least until it
>> fullfills my own whishes about it or until I find some blocker that I
>> won't be able to overcome. As originally I plan to use it for
>> development for rpi. I know that I'll have to add some support for ports
>> (I plan only wrapper for current descriptions), depots and possibly
>> something more.
> I wonder, have you considered adding scons support to the Goa tool [3]?
> Goa is completely independent from Genode's build system and already
> supports make, cmake, autoconf, and qmake.
> [3]

I did not look at this tool yet. Using it to port something is in my
personal work queue and maybe then some extension ideas will come.


More information about the users mailing list