> Fabian is back!


>> On 04/02/16 14:49, Fabian Greif wrote:
>>> To solve these issues a possible solution is extract the system
>>> part of the SCons system (basically everything in /architecture) into
>>> 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.


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

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
>> 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 ;-)

Lets just use the modm repository for now :-)


xpcc-dev mailing list

Reply via email to