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

Daniel Petry daniel.petry at fu-berlin.de
Wed Nov 29 14:33:48 CET 2017


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.




More information about the devel mailing list