[riot-notifications] [RIOT-OS/RIOT] Define requirements for configuration in the build system (#14027)
notifications at github.com
Wed May 6 10:26:11 CEST 2020
>I think this is hard to avoid. I know how much of an issue this is for Linux distribution when package A depends on B and B depends on A. In that case you have to e.g. build A first in a stripped down version that does not depend on B in order to build B. And often you have to loop rebuild them over and over until finally all features can be build.
>But the difference here is: In RIOT the headers will just always be available. Thus, it should be no issue to build A without B already being build in the other way round. (If this is a concern: We could write this down that we expect that every module should be able to compile without any of its dependencies being compiled yet - so that only at the linking stage all dependencies need to be available. But as every module happened to comply with this already, I guess this either is just so natural or so obvious, that we could just rely on this not going to happen without a written rule.)
I disagree here. IMO it is not hard to avoid circular dependencies. Nowadays, the typical programming 101 class teaches design patterns that avoid a strong coupling of modules .. Dependency hell is something that we ~~want to~~ **must** avoid, especially if we have a very nuanced dependency tree with a multitude of branches. Enforcing an acyclic dependency graph with a tool is IMO the correct way to go.
>Let's not forget Rust modules (which were difficult to support due to build order dependencies that RIOT's module system could not express), and maybe generated code. There are build order dependencies and logical dependencies between modules.
I would argue that build order dependencies closely follow the logical order dependencies. Otherwise, that would be very strange .. why would I need to build a module first and then the dependencies (in most cases this wouldn't even compile? And we don't support dynamic linking ..)
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...
More information about the notifications