Question about "reserved" CMake properties

The documentation for EXPORT_PROPERTIES has this brief mention:

Properties starting with INTERFACE_ or IMPORTED_ are not allowed as they are reserved for internal CMake use.

But there’s seemingly no mention over here at set_target_properties

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?

Thanks for your support!


Custom properties can start with _ or a lowercase letter after 3.11 even on INTERFACE targets.

Thanks Ben!

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.

1 Like

That helps a lot. Thanks again for your help and support!

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 :slight_smile:

I think making an abstraction would be better.

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.

That will still require some C++ code either way.