dc1d025 OS X: Add test for rpaths on Mac.
8576b3f OS X: Add support for @rpath in export files.
00d71bd Xcode: Add rpath support in Xcode generator.
94e7fef OS X: Add RPATH support for Mac.
RPATH support is activated on targets that have the MACOSX_RPATH
property turned on.
For install time, it is also useful to set INSTALL_RPATH to help
find dependent libraries with an @rpath in their install name.
Also adding detection of rpath conflicts when using frameworks.
This fixes bug #13797.
The kinds of changes applied in 373faae5 for frameworks are now
applied to CFBundle. The prefix and suffix for CFBundles are
now handled in cmTarget::GetFullNameInternal.
That will allow things like this:
find_package(Qt4)
qt4_generate_moc(myfile.h moc_myfile.cpp TARGET foo) # Note, foo target doesn't
# exist until below.
add_library(foo ...)
The qt4_generate_moc call would use the INCLUDE_DIRECTORIES from
the foo target using generator expressions. Currently it reads
the INCLUDE_DIRECTORIES directory property, meaning that include_directories()
is required.
Support for the TARGET is also added to qt4_wrap_cpp, but not qt4_automoc,
as that is deprecated in favor of the AUTOMOC target property.
The moc tool reports failure if the Q_INTERFACES macro is used with
an argument which has not appeared with Q_DECLARE_INTERFACE, so that is
the basis of the unit test.
The command line arguments are now always written to a file, which is
passed to moc as the @atfile. This was already the case on Windows, but
now it is used everywhere. The reason for that is that it is not currently
possible to expand the list of includes from a target directly in
a add_custom_command invokation (though that may become possible in the
future). There is not a big disadvantage to using the file anyway on
unix, so having one code path instead of two is also a motivation.
This corresponds to the g++ and clang++
option -fvisibility-inlines-hidden on linux. On Windows with MinGW,
this corresponds to -fno-keep-inline-dllexport. That option is
not supported by clang currently.
This is initialized by CMAKE_<LANG>_VISIBILITY_PRESET. The target
property is used as the operand to the -fvisibility= compile option
with GNU compilers and clang.
Currently it only adds the contents of the COMPILE_FLAGS target
property, but it can be extended to handle a new COMPILE_OPTIONS
generator expression enabled property.
Process all arguments in a single loop using a simple state machine.
While at it, fix some error message typos. Also allow LINK_LIBRARIES
with no actual libraries to disable use of the -DLINK_LIBRARIES=...
from the CMAKE_FLAGS. This was already possible in the old logic if
LINK_LIBRARIES was immediately followed by another keyword argument
instead of the end of the argument list, so allow it in general.
Update the RunCMake.try_compile test cases accordingly.
3aa9ce4 GenexEval: Fix evaluation of INCLUDE_DIRECTORIES target property.
0b39fef GenexEval: Extract a getLinkedTargetsContent from TargetPropertyNode.
53164ac cmTarget: Remove some hardcoding of transitive property names.
In commit 5b9149e0 (FindBoost: Overhaul caching and search repeat
behavior, 2012-09-24) we refactored the internal library search to use a
_Boost_FIND_LIBRARY macro to wrap around find_library calls. However,
CMake macros re-process escape sequences when evaluating calls inside
the macro after substituting placeholders (a historical bug). In order
to avoid escape sequences, convert backslashes to forward slashes before
passing arguments to the _Boost_FIND_LIBRARY macro.
This property should come from the content of the property itself,
plus the INTERFACE_INCLUDE_DIRECTORIES of the link *implementation*.
In contrast, when the INTERFACE_INCLUDE_DIRECTORIES is evaluated for
a target, the INTERFACE_INCLUDE_DIRECTORIES of the link *interface*
is used.
Similar logic applies for the COMPILE_DEFINITIONS target properties.
If the propertyName is already an INTERFACE_ variant of the property,
ie, the expression is similar to
$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>
then the INTERFACE_INCLUDE_DIRECTORIES of the link *interface* of foo
is used.
However, if the propertyName is not an INTERFACE_ variant, and the
interfacePropertyName is, ie, the expression is similar to:
$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>
then the INTERFACE_INCLUDE_DIRECTORIES of the link *implementation*
of foo is used.
This will be used to process transitive components of properties
which depend on linked targets. Currently only the link interface
of the target can be used as the source of the linked targets, but
in the next commit it will be possible to use the link implementation
as the source of link targets.
This commit does not change the semantics of the code.