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

Hi all, I want to give my opinion on the discussions that happened here in Berlin regarding the build system evolution. And also, choose the direction for next development steps. # Laze presentation # Kaspar presented his new tool that replaces the current Make based build system based on

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

Hiho Gaetan, wasn't it in particular that the current build system does not produce well-defined results in the sense that the outcome depends on the order and hidden interferences?? Wasn't it also that the current configuration system includes overloaded semantics and is thus rather intrans

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

Hi Matthias, On 12/01/2017 10:29 AM, Matthias Waehlisch wrote: >> When are you gonna take a look at my ninja-based build system? It >> solves 1-3 quite nicely, and more. You could save a lot of time. >> > Pointer? https://github.com/kaspar030/RIOT/tree/add_laze_buildfiles Don't expect a nice

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

On Thu, 30 Nov 2017, Kaspar Schleiser wrote: > When are you gonna take a look at my ninja-based build system? It > solves 1-3 quite nicely, and more. You could save a lot of time. > Pointer? Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://

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

Hi, On 11/30/2017 04:32 PM, Gaëtan Harter wrote: > 1. Configuration is not documented > 2. Information is not readable > 3. Modules definition is scattered but in RIOT global files > With these issues in mind, I propose to add parseable module meta-data > definitions in a file i

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

Hi, 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 t

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

Hi Thomas, Francisco, all, I will try to summarize with three aspects formatted as problems. Just for clarity, in the following text, use the words 'description', 'informations', 'configuration', 'dependencies' to describe all the meta-information that can be attached to a module in addition t

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

Hi Kaspar, On Thu, 30 Nov 2017, Kaspar Schleiser 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 th

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

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. A

Re: [riot-devel] 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 develope

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

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

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

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 so

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

On 11/24/2017 04:55 PM, Martine Lenders wrote: Hi Daniel, 2017-11-24 16:47 GMT+01:00 Daniel Petry >: […] 1) Move build information concerning a particular module into that module's Makefile 2) Make the module makefiles able to be written with

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

Hi Daniel, 2017-11-24 16:47 GMT+01:00 Daniel Petry : > […] > > 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 sys

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

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

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

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

[riot-devel] 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 exter