Fabian is back! > On 04/02/16 14:49, Fabian Greif wrote: >> To solve these issues a possible solution is extract the system builder >> part of the SCons system (basically everything in /architecture) into a >> separate tool and make the remaining parts more modular. One approach for >> this would be the library builder . > > […] > Maybe you could suggest a list of modules, to start a discussion about the > amount of modularity.
Let’s do this step by step and build a prototype first. The means doing xpcc/architecture or xpcc/architecture/platform first, then worrying about the rest later. At the very least, driver/core, driver/gpio and perhaps driver/uart. The complicated stuff is the code generation especially with parameters. If that works well, we can apply the lessons learnt to other modules. > I would like to add scons support to the library builder. > Could you point be to a small example project to prototype that? > Is there a plugin API for build systems? > And btw. what build systems do you want to support? CMake? Make? If I understand the library builder source code correctly, it will only copy files and templates, it will not actually build them. So lbuild is completely build system agnostic, right? >> I would start to >> migrating code from the xpcc repository over, separating it into >> independent modules. +1. Anything we can review and learn from. >> The device driver generation part of SCons would be extracted into a >> separate tool which generates the content of the architecture folder. This >> will be the biggest amount of work. This tool will then be used by the >> library builder to combine the architecture stuff with the other parts of >> the library. > > Is every device driver going to be its own module? Or do you plan to make a > big `architecture` module? > We need to be careful not to have two different build systems: The library > builder for the modules and the device file code for the `architecture` > module. This would imho be redundant. +1. The device files and driver files are essentially already modules. I don’t know enough of lbuild to say whether or not it can be generalized. > In general I would recommend you go ahead and start migrating code for a > single platform to the mbed repository so that we can start playing around > with your library builder solution and so that we have concrete examples to > discuss. +1. May I suggest STM32F407? It is the most well tested, most understood platform we have. Also not a simple as an AVR, so we might spot design problems earlier. > start migrating code […] to the mbed repository Thewhatnow?!? I think I’m way ahead of you on that one ;-) Cheers, Niklas _______________________________________________ xpcc-dev mailing list firstname.lastname@example.org http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev