Hi, I think the problem to solve is that RIOT is very difficult to configure.
While working with other IoT operating systems, one can notice that RIOT is very hardly configurable, unless we are very familiar with the build system and specific RIOT CFLAGS and special key-words (USEMODULE, USEPKG, etc…). Besides, I have no knowledge of a tool that can parse RIOT makefiles and give an insight about module usage, dependencies, features, etc. Thus IMHO a way to make, first, RIOT more *friendly* configurable it’s a good and necessary feature. This would also allow to eventually build a dependency tree in a more human-readable fashion, as well as give some help to get different product lines according to the selected features. However, I’d say that *deep* modifications to the current build system can lead to instability or buggy builds. I’m not against any improvement to the build system, but maybe as a first approach some additions like files in any more descriptive (parseable) language can help to describe RIOT in a higher level, without affecting at all the underlying system. Then, with the knowledge obtained thanks to such a description, we can imagine to generate makefiles or make “make” calls with the specific RIOT CFLAGS, USEMODULE, etc. My 2c. Cheers, -- Francisco Javier Acosta Padilla Research Engineer at INRIA Saclay INFINE Team On 24 November 2017 at 19:16:29, Thomas C. Schmidt ([email protected]) wrote: Hi Dan, Gaetan, I wonder, what problems are we trying to solve? Maybe we can clearly enumerate them first so that we can check later, whether an improved solution really solves these problems. Cheers, Thomas On 24/11/2017 16:47, Daniel Petry wrote: > 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. > > _______________________________________________ > devel mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/devel > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° _______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
