Updates to the build system - modules definition

Dear RIOT developers,

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. This would allow software architecture/configuration informations to be parseable by external tools without reading source code and without an application context.

My need is allowing a graphical interface to describe, configure applications with possibly external modules and generate the Makefile.

I want to start a task force on this in two weeks after some preliminary discussions on the concepts.

Current state

Some of these module information is already present but not in a easy to get way so it does not fit my need.

To highlight some of the problems:

  • it is scattered in different centralized files
  • Makes it hard to add external modules
  • Needs different files to get one module metadata- some is defined in a Turing complete language
  • Hard to parse
  • only available in a compilation context- some information/configuration only in source files


I am thinking about adding declaratively defined information/metadata on modules distributed to each module directory. This could be achieved by changing to a new build system with these features already included. However, integration into the current build system would be preferred in order to be able to incrementally integrate, test and document new changes.

Roadmap- Initial feedback period of two weeks

  • Define and break down intermediate tasks
  • Iteration cycles on each sub task and integration

Further steps

I would like to gather feedback on the concept here, and find interested people to start working on it, for reviewing, advices, giving their constraints and implementing if you have time.

I will give a two weeks time limit for the initial review until I start working onthis.

Thank you in advance.

Cheers, Gaëtan

Hi Gaëtan,

I think most of us are happy about any more structural approach to the build system, and me personally would prefer if we can stick to GNU standard tools. So in my opinion: go ahead. Maybe - as discussed offline - also start drafting some GitHub issues, outlining the drawbacks you found in more detail.

Kind Regards, Martine