[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