My issue is that those full paths are messing up my third party project linking against DCMTK, since the file C:/builds/acme-clinical/dicom/dcmtk/obj/vcpkg_installed/x64-windows-static/lib/libpng16.lib is part of one gitlab project while I am building from another one ?
What should I be using here instead (Is there a REALLY_PRIVATE keyword for target_link_libraries…) ?
It is strange that you get full absolute paths there. I also use vcpkg for resolving 3rd-party dependencies in my projects, and I also link to PNG in one of those projects, but what I get is:
set_target_properties(mMap PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
INTERFACE_LINK_LIBRARIES "\$<LINK_ONLY:someThing>;\$<LINK_ONLY:jpeg-turbo::turbojpeg-static>;\$<LINK_ONLY:draco::draco>;\$<LINK_ONLY:png>;..." # and so on
)
It probably has to do with the way you link to PNG, because I see you are linking to its actual libraries (${PNG_LIBRARIES}) instead of its CMake target.
Is there a REALLY_PRIVATE
As far as I know, there is no such thing, and I probably misunderstood what you are asking here, but it is possible to “hack” this linking out from your library’s exported CMake config with something like this:
# a dirty hack to remove a target from INTERFACE_LINK_LIBRARIES when it isn't actually needed
#
# from CMake 3.27 there is $<COMPILE_ONLY:...>, which should be better way
#
get_target_property(YOUR_PROJECT_INTERFACE_LINK_LIBRARIES ${PROJECT_NAME} INTERFACE_LINK_LIBRARIES)
if(NOT "${YOUR_PROJECT_INTERFACE_LINK_LIBRARIES}" STREQUAL "YOUR_PROJECT_INTERFACE_LINK_LIBRARIES-NOTFOUND")
list(REMOVE_ITEM YOUR_PROJECT_INTERFACE_LINK_LIBRARIES [=[$<LINK_ONLY:TARGET_YOU_WANT_TO_REMOVE>]=])
set_target_properties(YOUR_PROJECT
PROPERTIES
INTERFACE_LINK_LIBRARIES "${YOUR_PROJECT_INTERFACE_LINK_LIBRARIES}"
)
endif()
but then in consuming project you will for sure encounter linking problems, as PNG symbols will be missing at the “final” linking.
Either way, hopefully you won’t need to go this way, as your problem is likely because of linking “directly” to the libraries instead of the target.
That isn’t something specific to the PNG’s Find* module, it is how target_link_libraries() works in general - there is an explanation there about what one can link to (targets versus libraries).
This is incorrect. PNG::PNG will be properly propagated (PRIVATE-becomes-PUBLIC), but the major change is that the full path is not hard-coded anymore. I can build yet another vcpkg/PNG in my third party application (same exact ABI) and then my original symptoms are now solved.
-- Configuring done
CMake Error at CMakeLists.txt:2 (add_library):
Target "foobar" links to target "PNG::PNG" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
-- Generating done
Pay attention that will be required to add the missing find_package not before the add_library call, but before the actual find_package(DCMTK).
That’s hardly any news
This is just how CMake packages/configs work by design: either project maintainer takes care of this in the package config with find_dependency(), or his users will have to add find_package() in their projects.