I have added a make install target to my library
, and this library links private against another one.
There are no build or runtime dependencies to other one.
Why do I need the other one in the export targets? How can I avoid that?
(the library linking against contains just a set of warnings and flags that are totally private and shall not leak out)
PS: The problem occourse only if the dependent library is fetched via fetch_content
This change adds a -la4z::commonCompilerWarnings to the linker line, and that does of course not work (using the non generator expression does not do that)
other project shall use this, and link against it, so there is one central place to manage warnings and other flags.
If I do a fetch content for this, or consume it via vcpkg, it lands in the export target, even if it is also linked PRIVAT, with or without $<BUILD_INTERFACE or $<BUILD_LOCAL_INTERFACE …
That is kind of inconsistent and unexpected, and it makes my idea about how to share compiler and linked flags between projects a not soo good one, even if is should work
Would it make sense to report that as a bug to CMake, or is that for some reasons I do not see expected behaviour?
that at least can work when the dependency is either available via cmake, or sl3 install calls the install of commonCompilerWarnings and commonCompilerWarnings cmake files are also there.
$<BUILD_INTERFACE or $<BUILD_LOCAL_INTERFACE … can not be used at all if the library comes via fetch_content of vcpkg (like it would be in the system), since this adds something to the linker line -la4z::commonCompilerWarnings
That’s all very surprising, unexpected, and not optimal.
PS: and I tried with OVERRIDE_FIND_PACKAGE, FetchContent_MakeAvailable and other variations, did not change anything dramatic