Closed NOhs closed 5 years ago
I am not sure the following scenarios would work properly:
Two more aspects to think about:
To your first point, I am not sure. Your second point is valid. Your third point is correct in that flags are never "applied" so for header targets it wouldn't matter at all. Your fourth point, well having different cases for the different targets is not particularly "pretty" ;)
This may deviate from the definition that CMake uses, but to me interface flags make sense as something that is applied only to dependent targets that are actually linked (i.e. not headers, object files or archives).
To my first point: the shared library C cannot be linked into a static library (neither B nor A) and therefore needs to be linked into the executable or shared library that consumes A. This means the interface flags of B need to be forwarded further before being applied. To my fourth point: I agree that all the if-cases are not pretty, but it's important to keep the code easy to read. "Which flags are forwarded when" should not be a point of confusion.
We should make sure that linking dependencies is automatically done in this way. Since we have the dependency DAG, it should just automatically work to have e.g. "executable A -> static lib B -> shared lib C". I have opened the new issue #96 for this.
I believe this issue can be closed?
This should be more clear, now that PR #99 has been merged. Finally, everything will be consistent between include directories and flags with PR #76.
We have private public and interface level flags. Roughly speaking public = private + interface. Now we say that:
1) public flags of targets are always applied and forwarded 2) header and static libraries will forward interface flags of targets 3) executables and libraries will apply interface flags of targets
But my questions are:
a) Would it hurt if header and static libraries also applied interface flags? b) Would it hurt if executables and libraries would forward interface flags?
It would mean less code, less chance of confusion and less documentation needed. But maybe I am also not aware of issues this might cause.