set target property project-wide

I lifted my C++ backtrace utility from another project. There was even a note in the source code about requiring -rdynamic to use. Originally, we were using CMake 3.3. When I upgraded to 3.17, I was silently bitten by CMP0065. I now see that I need to set the ENABLE_EXPORTS target property, in order to get the appropriate linker flag.

I’ve looked at How to share common cmake properties between exes?. @marc.chevrier had a response that hints at the solution I want, but I don’t want to set compile/link options directly; I want to use the abstraction of the ENABLE_EXPORTS property. Unfortunately, setting it on my utility library doesn’t translate into an inherited link flag for targets that use it.

I’d like to think that I could set a global-scope property that would apply to all targets, but it doesn’t appear that global-scope properties work that way.

I think it’s too much to ask of users of a library to know that if you call function backtrace in library util that you need to set the ENABLE_EXPORTS property on your executable. It’s even worse if some intervening library makes the call, the the executable writer has no idea.

Am I totally off base, or is there a better way?

Unfortunately, not really. CMake won’t propagate usage requirements across a PRIVATE boundary, so there’s no way for a “buried” library to communicate with an executable. You could create an INTERFACE library that you document that one should link to publicly when linking to your other library via PRIVATE (alas, they’ll need the same instructions for their consumers). This INTERFACE library can at least bring along the flag guarded by a $<STREQUAL:$<TARGET_PROPERTY:TYPE>,EXECUTABLE> genex conditional, but there’s no way to say “must set this property to X”. Though maybe the COMPATIBLE_INTERFACE_BOOL property could be used to at least get CMake to error if the property isn’t set properly?

But the variable CMAKE_ENABLE_EXPORTS can be used to set, for a whole project, property ENABLE_EXPORTS.

Yes, but that only works within a single project. If there’s no exported SDK for such a project, that solution is probably sufficient.

@ben.boeckel makes a valid point, and it would be nice for a library to be able to export this type of requirement for use in other projects. However, my near-term need is for a single project, and @marc.chevrier had just the ticket I needed.

Thanks all!