Why do private linked targets leak out in install targets ?

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

See CMake Error: install(EXPORT "ProjectTargets" ...) includes target "xxx" which requires target "yyy" that is not in any export set. - #6 by ben.boeckel

Thank you, interesting.

a4z::commonCompilerWarnings is the lib that is fetched
and it works, but wants the cmake files of commonCompilerWarnings in the install target.

changing like in the thread

target_link_libraries(sl3
    PRIVATE
#    a4z::commonCompilerWarnings
    "$<BUILD_LOCAL_INTERFACE:a4z:commonCompilerWarnings>"
)

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)

Maybe I understand the solution wrong?

I use BUILD_INTERFACE very often like this:

target_link_libraries(${TARGET_LIBRARY} PUBLIC $<BUILD_INTERFACE:${TARGET_LIBRARY}_project_options>)

Does not work for me.

I leave it as is until I have the source online.
Then it will be easier to talk about.

Ok, I can confirm this works with internal libraries that are defined in the project.

But it does not work with a library that I want to reuse like this one: GitHub - a4z/commonCompilerWarnings: Always the same CMake warnings as a library

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?

I guess the OVERRIDE_FIND_PACKAGE cause the problems. If it is installed, it is imported?

I do not think it is just the OVERRIDE_FIND_PACKAGE
If commoncompilerWarnings comes via cmake, its exactly the same

say I have a library sl3, that consumes commonCompilerWarnings like this

target_link_libraries(sl3
    PRIVATE
    a4z::commonCompilerWarnings
)

that’s what can be found in libsl3Targets.cmake

set_target_properties(a4z::sl3 PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "\$<LINK_ONLY:a4z::commonCompilerWarnings>;/Applications/Xcode-16.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.1.sdk/usr/lib/libsqlite3.tbd"
)

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

I have tested it and it works file, too if it is installed:

WOW !
Now, when copying it like this, it works indeed.

Cool, thank you so much!