[cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King
brad.king at kitware.com
Mon Jan 28 15:07:50 EST 2013
On 01/26/2013 06:57 AM, Stephen Kelly wrote:
> Brad King wrote:
>> How can a package author allow old dependents using the old style to
>> keep working while also allowing new dependents using the new style
>> to work?
>
> So, the options I see are:
>
> 1) Upstream introduces a find_package-time variable to evaluate whether to
> populate the INTERFACE_INCLUDE_DIRECTORIES (similar to
> QT4_USE_IMPORTED_TARGETS). Upstream would likely have to clear the target
> property in that case after including the exported targets file.
This will require new downstreams to explicitly activate the new interface,
always :(
> 2) CMake introduces a standard documented way to not populate the target
> property in the exported targets file at all
> (<PACKAGE_NAME>_NO_INTERFACE_INCLUDE_DIRECTORIES, off by default).
How do we know the package name? It would have to be <EXPORT_NAME>, no?
> 3) Upstream introduces a new set of IMPORTED targets which have the
> INTERFACE_INCLUDE_DIRECTORIES set. CMake introduces a way to control at
> INSTALL(EXPORT) time whether to populate it. So upstream would do this:
>
> INSTALL(EXPORT fooTargets NAMESPACE Foo:: ...)
> INSTALL(EXPORT fooTargets EXPORT_INCLUDE_INTERFACE NAMESPACE FooNew:: ...)
I think that will create confusion over the purpose of the two copies.
If the upstream were CMake we could add a policy for this. We need to
do something similar without a policy in upstream CMake for every
project out there. If downstreams were to specify a required version
number in their find_package call then the upstream could activate the
new interface when the required version is high enough. This does not
help when no version is requested though, and that is very common.
The upstream could require that a version be requested if the downstream
wants the new interfaces to be available, but that does not allow a
downstream to optionally work with older versions of the upstream.
Perhaps it could work if the upstream provided an explicit variable
(option 1 above) that has meaning when the requested version is not
present or not new enough. Then downstreams would be able to use the
variable to get the new interfaces if the upstream is new enough to
provide them but still work with old upstreams.
-Brad
More information about the cmake-developers
mailing list