[riot-notifications] [RIOT-OS/RIOT] Define requirements for configuration in the build system (#14027)

Marian Buschsieweke notifications at github.com
Thu May 7 11:30:57 CEST 2020

There seems to be an agreement that a dependency cycle like "A depends on B and B depends optionally on A" is not a dependency cycle. I assume this is based on the assumption that dependency cycles with at least one dependency of the cycle being optional is no problem to handle by the build system. On what is this based?

E.g. if use of stdio in core would be optional and the build system would first build core (without message) and then stdio. Wouldn't it now have to build core again (with messages) this time? Or would the build system just rely on the fact that dependency cycles in C (and C++) with the headers are being available at any point in time and just build core with messages in the first compilation step? If so, what is then the advantage of the "hard" dependency cycle being turned into a "weak" dependency cycle?

So: Is there any reason to believe that "weak" dependency cycles (with at least on dependency in the cycle being optional) has any any advantage in the context of C (or C++) code? It certainly has the disadvantage of many `#ifdef MODULE_FOO`...`#endif` pairs are added just to turn forbidden hard dependency cycles into allowed weak dependency cycles. And that in turn would not result easier to maintain code, but quite the opposite.

If everyone insists in outlawing dependency cycles, couldn't we at least have this less strict like e.g. this:

- C (and C++) modules having dependency cycles should provide sound reason why no better architecture avoid dependency cycles is feasible
- Modules written in a language in which build order matters (e.g. Rust) must not contain dependency cycles.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20200507/94bf3c4f/attachment.htm>

More information about the notifications mailing list