Hi Fabian,
thank you for your efforts.
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].
I have one question about this:
How fine grained do you want to make the individual modules?
If we make them to big, we loose flexibility, if we make them to small,
we could end up with a dependency hell.
Generally, I think, we need to define a core system, that is available
on all platforms and that all other modules can depend on. This could be
a subset of the STL library and a module that contains the core xpcc
functionality like the timer and the clock.
When we do that, I would like to move our Container API to a STL
compatible version.
But how about the other modules? Do we add one math module? Or do we put
e.g. the Quaternion stuff into its own module?
Maybe you could suggest a list of modules, to start a discussion about
the amount of modularity.
The disadvantage mainly comes for the library developer, because the
generation of the library becomes a separate step. For most projects you do
this once at the beginning, after you selected your target architecture,
but for library development you generate the library all the time. It may
require a different workflow, by developing a new feature within a project,
and only after it is finished moving it into the library.
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?
So how to start the work on this:
Niklas already reserved modm-io on GitHub (modm stands for "Modular
Object-Oriented Development for Microcontrollers") to resolve the naming
issues between xpcc (the protocol) and xpcc (the library). I would start to
migrating code from the xpcc repository over, separating it into
independent modules. This requires a lot of structural changes which makes
it difficult to automatically merge changes from xpcc to 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.
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.
Best regards,
Kevin
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
