Updates to the build system - modules definition

Development archive
1

Hi Gaetan

I would like to introduce some packaging concepts around RIOT. To consider modules like well defined distribution packages and not only source files added to an application firmware.

From what you're saying, I understand that the aim is to make modules

completely self-contained with respect to build definitions, and make those definitions much more human readable. In this way, an application developer can go to only one place to find out information regarding a module's build (dependency information, etc.), and a module developer only has to write/change the module directory Makefile and can do so with declarative language. Also, the information can be easily parseable for eg a user interface.

So the changes you're proposing are:

1) Move build information concerning a particular module into that module's Makefile 2) Make the module makefiles able to be written with purely declarative language 3) Retain backwards compatibility with the current build system

Is this correct?

I think 2) would be great for user friendliness, and 3) is a no-brainer. 1) is a bigger topic as there are a number of different ways in which dependencies are manifested for example, so I think this can be a point for further discussion... do you have any particular examples?

Dan.

2

Hi Daniel,

3

Hi, I may have mixed ‘Makefile’ and file written in a ‘GNUMake’ language in my description. They address different steps of the build: * Makefile is when you actually compile the source files to an archive with a given configuration (CC, CFLAGS, INCLUDES) * All the Makefile.dep/Makefile.include/Makefile.features files that prepare this configuration and say which Makefile to execute And its the part of configuration I would like to address. Regarding Makefile I just want to remove the DIRS += part of it. What I want is add another file module.desc grouping the existing information and metadata on the module: * Submodule * is it a pseudomodule * includes path * dependencies * global CFLAGS * … and add more. Regarding the “purely declarative”, I would like to express it in GNUMake syntax and restrict to setting specially named variables. My rational about this, is that if its written in XML, and let make parse them, it is still required to translate the information to variables that the make build system can understand. So still needs to have a syntax to describe, for example, that a module has an optional dependency on another, and so be definable in a gnu make syntax. Cheers, Gaëtan