# Question about "reserved" CMake properties

**URL:** <https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104>\
**Category:** Code\
**Created:** [July 19, 2022, 9:04pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104 "2022-07-19T21:04:41Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![thorntonryan](https://discourse.cmake.org/user_avatar/discourse.cmake.org/thorntonryan/32/2609_2.png) [@thorntonryan](https://discourse.cmake.org/u/thorntonryan)\
**Post date:** [July 19, 2022, 9:04pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/1 "2022-07-19T21:04:41Z")

</div>

The documentation for [EXPORT\_PROPERTIES](https://cmake.org/cmake/help/latest/prop_tgt/EXPORT_PROPERTIES.html) 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](https://cmake.org/cmake/help/latest/command/set_target_properties.html?highlight=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!

Ryan

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [July 19, 2022, 9:37pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/2 "2022-07-19T21:37:04Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![thorntonryan](https://discourse.cmake.org/user_avatar/discourse.cmake.org/thorntonryan/32/2609_2.png) [@thorntonryan](https://discourse.cmake.org/u/thorntonryan)\
**Post date:** [July 20, 2022, 1:17am UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/3 "2022-07-20T01:17:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [July 20, 2022, 1:49pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/4 "2022-07-20T13:49:09Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![thorntonryan](https://discourse.cmake.org/user_avatar/discourse.cmake.org/thorntonryan/32/2609_2.png) [@thorntonryan](https://discourse.cmake.org/u/thorntonryan)\
**Post date:** [July 20, 2022, 2:44pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/5 "2022-07-20T14:44:02Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![puetzk](https://discourse.cmake.org/user_avatar/discourse.cmake.org/puetzk/32/2612_2.png) [@puetzk](https://discourse.cmake.org/u/puetzk)\
**Post date:** [July 21, 2022, 3:52pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/6 "2022-07-21T15:52:24Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [July 21, 2022, 4:34pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/7 "2022-07-21T16:34:29Z")

</div>

> [@puetzk](#):
>
> Which Iist really just MSVC linker features CMake doesn’t currently have an abstraction for.

I think making an abstraction would be better.

> [@puetzk](#):
>
> proposing an MR merging this into Windows-MSVC.cmake

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).

---

<div class="post-metadata">

**Author:** ![puetzk](https://discourse.cmake.org/user_avatar/discourse.cmake.org/puetzk/32/2612_2.png) [@puetzk](https://discourse.cmake.org/u/puetzk)\
**Post date:** [July 21, 2022, 4:49pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/8 "2022-07-21T16:49:13Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [July 21, 2022, 6:03pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/9 "2022-07-21T18:03:50Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![thorntonryan](https://discourse.cmake.org/user_avatar/discourse.cmake.org/thorntonryan/32/2609_2.png) [@thorntonryan](https://discourse.cmake.org/u/thorntonryan)\
**Post date:** [December 5, 2025, 11:54pm UTC](https://discourse.cmake.org/t/question-about-reserved-cmake-properties/6104/10 "2025-12-05T23:54:27Z")

</div>

No response needed. Just leaving breadcrumbs.

Ran into this again in a different context.

We had been trying to model the Location of our INRPOC COM SERVERS by using a custom target property called: `COM_INPROC_SERVER_LOCATION`

But were getting an inexplicable warning:

> The LOCATION property may not be read from target “XYZ”. Use the target  
> name directly with add\_custom\_command, or use the generator expression  
> $\<TARGET\_FILE\>, as appropriate.

We tracked it down to using:

```auto
COMMAND "${MT_EXECUTABLE}" ${_mt_ARGS} "/dll:$<PATH:GET_FILENAME,$<TARGET_GENEX_EVAL:${target},$<TARGET_PROPERTY:${target},COM_INPROC_SERVER_LOCATION>>>" "/out:${_mt_OUTPUT}"

```

And was fixed by renaming the property and dropping the `_LOCATION` from its name:

```auto
COMMAND "${MT_EXECUTABLE}" ${_mt_ARGS} "/dll:$<PATH:GET_FILENAME,$<TARGET_GENEX_EVAL:${target},$<TARGET_PROPERTY:${target},COM_INPROC_SERVER>>>" "/out:${_mt_OUTPUT}"

```

Seems like we hit the rules working around CMP00026