[cmake-developers] Compatible INTERFACE user properties and string properties

Stephen Kelly steveire at gmail.com
Thu Jan 10 13:04:33 EST 2013


Now that the INTERFACE_PIC branch is in, the next topic I have in that line 
is the compatible-INTERFACE-user-properties topic I've just pushed to 
gitorious.

Because I'll be automatically linking the Qt4::qtmain library into 
executables which are WIN32_EXECUTABLEs, and because QtActiveX requires that 
Qt4::qtmain is not linked in to executables, I need some way to enforce 
that.

My solution is to check the QT4_NO_LINK_QTMAIN in the generator expression 
which links in Qt4::qtmain, and to set INTERFACE_QT4_NO_LINK_QTMAIN to OFF 
in the QtActiveX library. On its own, that has no effect, but the 
compatible-INTERFACE-user-properties topic allows us to use the same logic 
as is used for the PIC feature to implement that, if the user code populates 
the COMPATIBLE_INTERFACE_BOOL property:

 set_property(TARGET Qt4::QAxServer APPEND PROPERTY
      COMPATIBLE_INTERFACE_BOOL QT4_NO_LINK_QTMAIN)

I think that I can add some API to cmPropertyDefinitionMap via the cmake 
instance to ensure that built-in properties can not be used in that 
property. 

The topic is also missing documentation currently. I wanted to get feedback 
on the approach first.



Secondly, I've pushed the INTERFACE_PROPERTIES branch again. This topic is 
not something that I'd like to get into master soon, but something I thought 
I'd bring up. It generalizes the logic introduced in the INTERFACE_PIC topic 
to also be able to require 'equal strings', not only 'truthiness equal 
booleans'.

The reason for that is that I was thinking of C++11 support and how clang 
can be used with different stdlib implementations, -stdlib=libc++ or -
stdlib=libstdc++. The two are obviously not compatible, and a library using 
one should not be linked with a library using the other. Additionally, an 
executable using a library build with -stdlib=libc++ should also use libc++ 
itself.

This is very similar to the PIC situation, and is something we could 
implement support in CMake for. For example, setting the CXX_STDLIB property 
on a target to libc++ would pass -stdlib=libc++ if using clang. What it does 
for other compilers is up for debate. Linking a target to a library with 
INTERFACE_CXX_STDLIB=libc++ would set the CXX_STDLIB property on the target 
libc++ too etc, and un-equal strings in that property would be a generate-
time error.

If built into CMake as a feature, we would probably need to also handle 
other stl implementations like libstdc++-v2 libstdc++-v3, eastl, ustl, 
stlport etc and treat other strings as errors.

Similar to my first point above, this string equality requirement could also 
be extended to users with a COMPATIBLE_INTERFACE_STRING property. That would 
allow for example to set QT_SOVERSION to "4" on Qt4::QtCore and to "5" on 
Qt5::Core, so that a generate-time error is hit if they are accidentally 
used together.

What do you think?

Thanks,

Steve.





More information about the cmake-developers mailing list