Updates to the build system - modules definition

Hi

I wonder, what problems are we trying to solve?

The problems as I understand it are the following - Gaetan, please correct me if I haven't got this quite right, or if there are additions!

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. Information for each module is not readily available in one place and in a format which is parseable to human-readable text.   1.1 Information on other required modules is not readily available in a common format   1.2 How the inclusion of modules changes functionality of other modules is not readily available in a common format   1.3 Type of module is not readily available in a common format   1.4 Include path for applications that use the module is not readily available in a common format

2. The current build system doesn't allow developers to easily include modules in their applications, and they need to investigate cross-dependencies etc. They have to look in a range of different places rather than just one place to see what effects the inclusion of a module has.   2.1 Any module API/functionality changes to modules as a result of including other modules are difficult to find   2.2 Any other modules they need to include are difficult to find   2.3 The order in which they need to include the modules is difficult to figure out   2.4 The CFLAGS that are added and whether they're global or local to a module is difficult to figure out

3. The current build system doesn't allow developers to easily work on modules. This includes creating new modules, or changing current modules, either just to make them work or without introducing regression bugs in related modules. This is because module code and the way they're 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

@Gaetan, would you say this is the case or do you have any comments?

Maybe we could decide on the problems - i.e., refine/change this list - before moving on to discuss solutions? A good target might be to decide on the problems that need to be solved - i.e. the requirements - by a week on Friday then go on to a design/development phase?

Dan.

Hi Dan,

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?

2. The current build system doesn't allow developers to easily include modules in their applications

USEMODULE += module_name?

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?

Kaspar

Hi Kaspar,

Hi,

Hi Dan,

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.

Gaƫtan