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.
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.
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
May I suggest STM32F407? It is the most well tested, most understood platform
Also not a simple as an AVR, so we might spot design problems earlier.
> start migrating code […] to the mbed repository
I think I’m way ahead of you on that one ;-)
xpcc-dev mailing list