diff options
author | Stephen Kelly <steveire@gmail.com> | 2013-01-21 11:05:01 (GMT) |
---|---|---|
committer | Stephen Kelly <steveire@gmail.com> | 2013-01-21 11:19:39 (GMT) |
commit | 48a4cf21825c9ed5f53ac25d5f4577baaf92d1f7 (patch) | |
tree | 738af3c5e92e04eb13711c241c48bebc85e74307 /CompileFlags.cmake | |
parent | 3ded614e31e9dcc4afa3ee9885dadf830a05dd21 (diff) | |
download | CMake-48a4cf21825c9ed5f53ac25d5f4577baaf92d1f7.zip CMake-48a4cf21825c9ed5f53ac25d5f4577baaf92d1f7.tar.gz CMake-48a4cf21825c9ed5f53ac25d5f4577baaf92d1f7.tar.bz2 |
Revert "Allow target_link_libraries with IMPORTED targets."
This reverts commit 9cfe4f1b769597bd9ba179eba46572a9df27f64c.
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.
Diffstat (limited to 'CompileFlags.cmake')
0 files changed, 0 insertions, 0 deletions