Hi,
> Fabian is back!
\o/
>> 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.
Agreed.
Nonetheless I think it is useful to have the code generation part as a
separate bundle of python functions/classes. Those can be then used by the
library builder to create the actual library. But it should make testing
easier if it is possible to invoke them separately.
>> 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?
Yes. The build process should later on be as simple as:
env = Environment(...)
env.Program('project', env.Glob('src/*.cpp'))
I already extracted the SCons part in xpcc and decoupled it from the
system building part for a different (work) project. This should become its
own library, independent from xpcc and modm.
>>> 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.
Should be doable.
If it is not I'll talk to the guy that wrote lbuild ... oh, wait ;-)
>> 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.
Ok.
>> start migrating code […] to the mbed repository
>
> Thewhatnow?!?
> I think I’m way ahead of you on that one ;-)
Lets just use the modm repository for now :-)
Cheers,
Fabian
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
