Commit Graph

29 Commits

Author SHA1 Message Date
Stephen Kelly 77cecb778f Add includes and compile definitions with target_link_libraries.
This establishes that linking is used to propagate usage-requirements
between targets in CMake code. The use of the target_link_libraries
command as the API for this is chosen because introducing a new command
would introduce confusion due to multiple commands which differ only in
a subtle way.
2013-01-31 17:34:20 +01:00
Stephen Kelly 0b92602b81 Add the $<LINKED:...> generator expression.
This is both a short form of using a TARGET_DEFINED expression
together with a TARGET_PROPERTY definition, and a way to strip
non-target content from interface properties when exporting.
2013-01-31 17:34:20 +01:00
Stephen Kelly 7bf490e9bb Make subclasses responsible for joining content.
This way we can add handling of relative/absolute paths and of
-D in compile definitions.
2013-01-29 19:34:04 +01:00
Stephen Kelly f6b16d4b06 Don't allow targets args in the new target commands. 2013-01-29 18:44:54 +01:00
Brad King 76ace2b95a Merge topic 'disallow-IMPORTED-interface-porcelain'
b98d14d Disallow porcelain to populate includes and defines of IMPORTED targets.
48a4cf2 Revert "Allow target_link_libraries with IMPORTED targets."
2013-01-23 15:11:40 -05:00
Stephen Kelly b98d14d400 Disallow porcelain to populate includes and defines of IMPORTED targets.
With similar reasoning to the parent commit, as downstreams, we can't
determine what $<CONFIG> generator expressions would be appropriate.

Upstream would have populated the INTERFACE_INCLUDE_DIRECTORIES with
config-specific generator expressions, possibly appropriate for
their DEBUG_CONFIGURATIONS. In theory, if we would add include
directories for a DEBUG intent, we would have to match the upstream
configurations for that.

Rather than attempting to discover the appropriate configurations
at this time, simplify the feature instead. The use of IMPORTED targets
with these commands could still be added in the future if targets
would export their DEBUG_CONFIGURATIONS somehow.
2013-01-21 12:32:46 +01:00
Stephen Kelly 48a4cf2182 Revert "Allow target_link_libraries with IMPORTED targets."
This reverts commit 9cfe4f1b76.

It turns out that correctly adding the content to
the IMPORTED_LINK_INTERFACE_LIBARIES_<CONFIG> of an upstream target
from the buildsystem of a downstream project is not simple.

If upstream had added the INTERFACE content, the config-specific
properties would  be determined by the DEBUG_CONFIGURATIONS of
upstream.

As downstream, we don't have any information about what
the DEBUG_CONFIGURATIONS of upstream were, so we can't determine
which configuration-specific properties to populate. The best we can do
is add it to all of them or add it to the ones downstream considers to
be DEBUG_CONFIGURATIONS, neither of which is a good solution.

So, removing the porcelain API for that is the best approach. A human
can still determine which properties to populate and use
the set_property API to populate the desired properies.

Another solution to this would be for upstream targets to publish
what they consider DEBUG_CONFIGURATIONS, but that can be added in
a future release.
2013-01-21 12:19:39 +01:00
Stephen Kelly 24dcf0c007 Make sure generator expressions can be used with target_include_directories.
Handle the case that a generator expression is used before treating
a non-target as an error.
2013-01-16 22:16:46 +01:00
Stephen Kelly 2bee6f5ba5 Add the TARGET_DEFINED generator expression
This tests whether the parameter is a usable target.
2013-01-14 00:08:47 +01:00
Stephen Kelly 77d2646784 Allow generator expressions in LINK_INTERFACE_LIBRARIES.
The Config and IMPORTED_ variants may also contain generator
expressions.

If 'the implementation is the interface', then the result of
evaluating the expressions at generate time is used to populate
the IMPORTED_LINK_INTERFACE_LIBRARIES property.

1) In the case of non-static libraries, this is fine because the
  user still has the option to populate the LINK_INTERFACE_LIBRARIES
  with generator expressions if that is what is wanted.

2) In the case of static libraries, this prevents a footgun,
  enforcing that the interface and the implementation are really
  the same.

  Otherwise, the LINK_LIBRARIES could contain a generator
  expression which is evaluated with a different context at build
  time, and when used as an imported target. That would mean that the
  result of evaluating the INTERFACE_LINK_LIBRARIES property for
  a static library would not necessarily be the 'link implementation'.

  For example:

    add_library(libone STATIC libone.cpp)
    add_library(libtwo STATIC libtwo.cpp)
    add_library(libthree STATIC libthree.cpp)

    target_link_libraries(libtwo
      $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>)
    target_link_libraries(libthree libtwo)

  If the LINK_LIBRARIES content was simply copied to the
  IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but
  executables linking to libthree will not link to libone.

3) As the 'implementation is the interface' concept is to be
  deprecated in the future anyway, this should be fine.
2013-01-10 23:04:06 +01:00
Brad King 325e92fa22 Merge topic 'target-includes-defines-commands'
fc61a7a Add the target_compile_definitions command.
8a37ebe Add the target_include_directories command.
2013-01-10 10:22:46 -05:00
Brad King 2341470673 Merge topic 'tll-IMPORTED-targets'
9cfe4f1 Allow target_link_libraries with IMPORTED targets.
2013-01-10 10:22:26 -05:00
Stephen Kelly fc61a7a746 Add the target_compile_definitions command.
This is a convenience API to populate the corresponding properties.
2013-01-10 09:46:58 -05:00
Stephen Kelly 8a37ebec78 Add the target_include_directories command.
This is a convenience API to populate the corresponding properties.
2013-01-10 09:46:57 -05:00
Brad King a9f1bf4380 Merge topic 'LINK_LIBRARIES-property'
7653862 Add LINK_LIBRARIES property for direct target link dependencies
40cf3fb Make linking APIs aware of 'head' target
2013-01-08 14:32:41 -05:00
Stephen Kelly 9ce1b9ef29 Add CMAKE_BUILD_INTERFACE_INCLUDES build-variable.
This makes

 set(CMAKE_BUILD_INTERFACE_INCLUDES ON)

add the equivalent of

 set_property(TARGET tgt APPEND PROPERTY
   INTERFACE_INCLUDE_DIRECTORIES
   $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}>
 )

to every target.

If the headers are in CMAKE_CURRENT_SOURCE_DIR, and the generated headers
are in CMAKE_CURRENT_BINARY_DIR, this is a convenient way to build a target
bar, which depends on foo, just by using target_link_libraries() and adding
the INTERFACE_INCLUDE_DIRECTORIES to the INCLUDE_DIRECTORIES of the target
being linked. There will be more-convenient porcelain API to consume the
property in the future.
2013-01-08 14:14:27 -05:00
Stephen Kelly 9cfe4f1b76 Allow target_link_libraries with IMPORTED targets.
This makes it possible to use:

 target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar)

where foo is an IMPORTED target. Other tll() signatures are not
allowed.
2013-01-08 18:58:18 +01:00
Stephen Kelly 7653862798 Add LINK_LIBRARIES property for direct target link dependencies
Previously we kept direct link dependencies in OriginalLinkLibraries.
The property exposes the information in the CMake language through the
get/set_property commands.  We preserve the OriginalLinkLibraries value
internally to support old APIs like that for CMP0003's OLD behavior, but
the property is now authoritative.  This follows up from commit d5cf644a
(Split link information processing into two steps, 2012-11-01).

This will be used later to populate the link interface properties when
exporting targets, and will later allow use of generator expressions
when linking to libraries with target_link_libraries.

Also make targets depend on the (config-specific) union of dependencies.
CMake now allows linking to dependencies or not depending on the config.
However, generated build systems are not all capable of processing
config-specific dependencies, so the targets depend on the union of
dependencies for all configs.
2013-01-08 09:02:43 -05:00
Brad King 2c4969a131 Merge topic 'fix-test-warnings'
b6346f2 Tests: Fix warning about unused variable
2013-01-03 13:53:30 -05:00
Stephen Kelly b6346f2556 Tests: Fix warning about unused variable
Resolve this warning:

 ".../Tests/CMakeCommands/target_link_libraries/depB.cpp", line 8: warning:
          variable "a" was declared but never referenced
    DepA a;
         ^
2013-01-03 13:50:55 -05:00
Stephen Kelly 3096202932 Make targets depend on the link interface of their dependees. 2013-01-03 13:31:50 -05:00
Brad King 55b2aa884c Use generalized RunCMake test infrastrucure for build_command test
The CMakeCommands.build_command test performs output/error checking
so move it over to RunCMake to re-use the generalized infrastrucure.
This is the only test left using Tests/CMakeCommands/CMakeLists.txt
so remove it.
2012-03-12 09:33:21 -04:00
Brad King eb33000d75 Use generalized RunCMake test infrastrucure for find_package test 2012-03-12 09:33:21 -04:00
Brad King c5ae733166 find_package: Test that REQUIRED aborts processing correctly
Verify that the command produces a FATAL_ERROR if and only if the
missing package is REQUIRED.
2012-03-07 11:34:59 -05:00
Brad King eeaaffcb2f find_package: Test error and warning messages in failure cases
Add a "CMakeCommands.find_package" test to run CMake on a bunch of cases
in which find_package fails.  Check that the process return code and
warning/error messages are as expected.  Record expected test output in
corresponding files for reference by the check.  These files will also
serve as a reference for the message text in each case.
2012-02-28 13:34:53 -05:00
Brad King 5e1a5c44da Add infrastructure for CMakeCommands tests
Generalize the build_command test framework as a macro to add the
test.  Process the CMakeCommands subdirectory explicitly.
2012-02-28 11:34:10 -05:00
Rolf Eike Beer 0541a03a4c GenerateExportHeader test: add newlines before end of file 2012-01-18 00:01:08 +01:00
Stephen Kelly 914382224d target_link_libraries: Add LINK_(PUBLIC|PRIVATE) options
Makes it possible to specify the link dependencies and link
interfaces in one command without repetition.
2011-11-22 16:52:35 -05:00
David Cole 0b38bb4c53 Fix issue #2336 - honor the -C arg to ctest. Honor it for all stages of running -D dashboards from the command line and running ctest_configure, ctest_build and ctest_test commands in -S scripts. Also, allow a script to change it by setting the CTEST_CONFIGURATION_TYPE variable: allows for multiple configuration build/test cycles within one script. Add a new signature for the cmake command build_command that accepts CONFIGURATION as one argument. The original build_command signature is still there, but now marked as deprecated in the documentation. Of course... also add CTestConfig tests to verify that -C is honored for -D dashboards and -S scripts. 2009-12-04 12:09:01 -05:00