[riot-devel] Updates to the build system - modules definition

Gaëtan Harter gaetan.harter at fu-berlin.de
Thu Nov 30 19:04:53 CET 2017


On 11/30/2017 11:52 AM, Kaspar Schleiser wrote:
> Hi Dan,
> On 11/29/2017 02:33 PM, Daniel Petry wrote:
>> 1. The current build system isn't suitable to support the front end for
>> RAPstore that Hendrik developed for his bachelor thesis, which requires
>> that certain information can be displayed to the users.
> I hear about this for the first time. Are there any pointers?
Its not specific to the current version of the interface, but to what I 
would like to achieve for the RAPstore project.
Configure a firmware using a graphical interface by selecting modules 
and configuring them.
>> 2. The current build system doesn't allow developers to easily include
>> modules in their applications
> USEMODULE += module_name?
In our context, it could be important to know the consequences of this.
On my computer, when I say 'aptitude install PACKAGE' I am informed of 
the additional dependencies.
Here with interdependencies, and modules affecting the global 
configuration it can be more important than this.

The cbor_ctime pseudomodule, when used with newlib, makes every source 
files compile with -DGNU_SOURCE=1.
I would not know that when simply adding it to USEMODULE.

>> built can be affected by files/code outside the module directory
>> 	2.1 API changes as a result of including other modules aren't
>> immediately visible in that module
>> 	2.2 API changes on other modules as a result of including that module
>> isn't immediately visible
>> 	2.3 The complete build information for a module isn't localised only in
>> the module directory
> If modules are interdependent, they will affect each other. How can a
> different module definition help here?
Regarding 'interdependency', I think about module that behave 
differently => are compiled differently if another module is included.
The optional dependencies that affect either your code or your API.

Adding this to a definition would help as documentation. It still allow 
specific requirements, still allows strange architecture for compilation 
optimization, but at least its said somewhere.

It took me some time to understand that `at86rf231` and `at86rf212b` are 
pseudomodules and are both implemented by `at86rf2xx` which is compiled 
differently depending on which one is included. 'git grep at86rf231' 
says nothing about it.

It would of course require tooling to help writing and maintaining these 
modules definition.
And even more for each information that the build system is not using 
and enforcing.

> Kaspar
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

More information about the devel mailing list