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 [1].
> 
> […]
> 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
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Reply via email to