There was an idea to prevent cyclic dependencies between modules and organized them in cmake object libs to catch violations early.
It might not be possible to have those object libs since we already have cyclic dependencies between the modules. The error reporting already depends on components in concurrent and quite a lot depends on the error reporting, including some components in concurrent.
Coming up with a different structure might not solve the problem and we might just live with the dependencies between the modules. After all, the module structure is quite arbitrary and there is no technical reason why a component is in a specific module but only semantic reasons.
@FerdinandSpitzschnueffler @mossmaurice @dkroenke @MatthiasKillat @budrus @elfenpiff with the reasoning in the description I tend to just close the issue. Any objections?
Brief feature description
There was an idea to prevent cyclic dependencies between modules and organized them in cmake object libs to catch violations early.
It might not be possible to have those object libs since we already have cyclic dependencies between the modules. The error reporting already depends on components in concurrent and quite a lot depends on the error reporting, including some components in concurrent.
Coming up with a different structure might not solve the problem and we might just live with the dependencies between the modules. After all, the module structure is quite arbitrary and there is no technical reason why a component is in a specific module but only semantic reasons.
References
Comes from #1391