Could you please advise on how to get these lists _expectedTarget (and _targetsNotDefined,_expectedTargets) into the myprojectConfig.cmake configuration file which is being generated by cmake from template myprojectConfig.cmake.in and retrieved by consuming project via find_package(myproject). Can new variable be put into myprojectConfig.cmake with such list or unset() statements be blocked in myprojectConfig.cmake? Note I don’t want to track every target installed by individual sub-projects in my code since cmake already tracks them via these lists for better maintainability.
Second question: cmake writes lines into export_target_nameTargets.cmake
…Create imported target targetx
add_library(targetx INTERFACE IMPORTED)
Why is the INTERFACE attribute added here by cmake? What difference will it make comparing to just IMPORTED? Are there any additional properties that could be set or get for “INTERFACE IMPORTED” target comparing to IMPORTED or INTERFACE target?
Thanks for your feedback. Definition for INTERFACE library does not limit it to only “header-only” library although it might be most common use of INTERFACE library : INTERFACE Library. I am able to build with normal external library which is added as an INTERFACE add_library(…INTERFACE…) library but I have to install its binary files (.so,etc) using install(DIRECTORY…) besides install(TARGETS…)
So are you suggesting that the definition is not complete and actually cmake does not support any property setting to indicate location of library files (.so|.a|.dll…) ?
The use of combined properties " INTERFACE IMPORTED" is still not quite clear as if I export library as INTERFACE (without IMPORTED) I am able to add it as either add_library(… IMPORTED …) or as add_library(…INTERFACE…) in consuming project.
The cmake documentation indicates at the endof INTERFACE library section " An INTERFACEImported Target may also be created with this signature." which means INTERFACE IMPORTED would have same properties as INTERFACE library which has GLOB visibility, but then it also says " It may be referenced like any target built within the project" . “Any” target means target that has LOCATION property storing path to .so|.a… files. However this section mixes in definition of IMPORTED library which has its own separate section and makes this paragraph confusing.
I think you meant INTERFACE IMPORTED library is different from INTERFACE which is being built by the project and if it is just INTERFACE, then it is built, while INTERFACE IMPORTED attribute tells cmake it is external, right?. Then, let say library, is being built as normal with .so|.a|dll|dll.a objects / files and added as INTERFACE.
How in this case LOCATION could be specified for these objects?
When cmake distinguish these 2 types, it sets target property different. is there a way to see what are the differences?
I think you meant myprojectConfig.cmake.in file and you use different naming convention for config template as you also have " ```
project-config.cmake.in
I assume ```
SyslogTargets.cmake and SystemdTargets.cmake are NOT cmake -generated export name target lists despite the naming convention for auto-generated files bc they are included by project-config.cmake.in (while ..Targets.cmake automatically included into myprojectConfig.cmake)
``` therefore I am not clear how could adding logic to myprojectConfig.cmake.in as per "may add logic in your myprojectConfig.cmake" could affect these files.
Note I don’t want to track every target installed by individual sub-projects in my code since cmake already tracks them via these lists for better maintainability.
I do not understand your intention or the reason?
IMHO it is not necessary to know this details. Cmake does it right!
The cmake does write correct list of targets into myprojectTargets.cmake file. This file is autogenerated so it is not possible to make modification to this file and remove unset lines: unset(_targetsDefined) unset(_targetsNotDefined) unset(_expectedTargets)
Therefore the variables I need to use in myprojectConfig.cmake/myprojectConfig.cmake.in are not accessible. This is the question I posted, on how to get such access or more generally get the list of targets (_targetsDefined, etc listed in foreach () statement ) useable in myprojectConfig.cmake/myprojectConfig.cmake.in without tracking every target that is added in myriads of sub-projects of a project. cmake gets the list in the foreach(_expectedTarget … target1 target2…targetn) statement and potentially there could be a property or variable this list is obtained from (I checked cmake cache and did not find one).
The reason why to use such list(s) is as the following: print custom warning message to the user about each target imported, warn them that certain targets are imported and they should not import them directly, check versions and address conflicts if they arise with custom warning text rather than frequently meaningless cmake own error/warning.
Thanks for the example, but the cxx.simplelog/CMakeLists.txt shows statements that trigger cmake to create …Targets.cmake file but do not address this question