We’re exploring augmenting CMake targets generated by Conan’s CMakeDeps generator with custom properties. Since Conan creates INTERFACE targets, we were originally going to likewise use INTERFACE_* custom properties … until we happened across this mention in EXPORT_PROPERTIES.
Should set_target_properties guard against setting “reserved” properties? Or at least should the doc warn against doing so?
I wasn’t aware of that recommendation. Does the doc mention that anywhere?
We’ve apparently been misusing? custom INTERFACE_* properties for a while now, but only accidentally learned about it when I stumbled across the mention in EXPORT_PROPERTIES.
Was just curious if the “reserved” nature of INTERFACE_* AND IMPORTED_* was a general recommendation or specific to exporting.
They’re reserved in that CMake doesn’t worry about “is anyone else using this?” if it wants to make a new property in that namespace. It seems I only added a release note, not a documentation bit when I implemented it way back when.
Makes sense. Where Ryan and I have used them thus far is a custom property FOO that I want to do “transitive inheritence” ala the usual CMake PUBLIC/PRIVATE/INTERFACE for. Thus, INTERFACE_FOO as the name for the version that is inherited.
I think the main example thus far is MANIFEST_ASSEMBLYIDENTITY, MANIFEST_DEPENDENCY and INTERFACE_MANIFEST_DEPENDENCY (which I then use to generate the MSVC /manifestDependency switches for isolated/side-by-side builds). Which Iist really just MSVC linker features CMake doesn’t currently have an abstraction for. So it’s probably best resolved by proposing an MR merging this into Windows-MSVC.cmake, documenting the properties, and seeing if we can just make this into upstream functionality with officially-blessed names. Something for the TODO list
I don’t know what adding it to a compiler support file would do. CMake needs to be aware of this when it is putting together compile and link command lines (or VS project file XML elements).
Right. I made an WinSxS.cmake that implements such an abstraction, more or less in the way I wished CMake would have, and in doing so stepped into a namespace that is “reserved”. So trying to upstream it makes sense.
I don’t know what adding it to a compiler support file would do. CMake needs to be aware of this when it is putting together compile and link command lines
Presumably set CMAKE_*_FLAG variables or add new <…> placeholders in the link rule telling CMake whether this linker supports manifest dependencies and how to construct the command-line, like it does for many other such features. Right now my util script is more hard-coded, but I’d have to clean that up to be suitable for an upstream MR. I’ll give it some thought and see what I can come up.
