Norman Feske <norman.fe...@genode-labs.com> 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] https://github.com/genodelabs/genode/issues/3247
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] https://github.com/satwikkansal/wtfpython 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] :-) https://github.com/genodelabs/genode/blob/master/repos/base-linux/src/test/lx_hybrid_errno/target.mk >> I hope to finish those parts quickly and make it public this year. > > I'm looking forward to try it out. Great. >> 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] https://github.com/nfeske/goa 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. Cheers Tomasz _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
