Brad King wrote:
> 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?
Nope, I meant ${PACKAGE_FIND_NAME}
>
>> 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.
Probably. I was thinking something along the lines of inline namespaces
where it would be more common to have version numbers like Foo12:: for Foo
1.2, and Foo13:: for Foo 1.3, or more like SO numbers where they'd bump the
SO number (independent of the release number) and add a new set of targets
if they want to extend the interface.
This INTERFACE_INCLUDE_DIRECTORIES case is not going to be the only time an
upstream will want to add to its interface. In theory, any time they want to
add a directory to the INTERFACE_INCLUDE_DIRECTORIES they would have to bump
the compatibility number.
Also, just to shortcut a possible discussion point - this issue is
independent of whether tll() adds includes or a new command is added. If a
downstream is using a new command before the upstream adds
INTERFACE_INCLUDE_DIRECTORIES, the exact same issue comes up. Just to be
clear.
> 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.
Yes.
> This does not
> help when no version is requested though, and that is very common.
Yes.
> 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.
Why not? All downstream would have to do is use include_directories with the
variable still published by upstream before using tll() if relevant.
That might mean moving a include_directories() call above the tll() when
they change their find_package call to require the newer upstream version,
but it is possible.
> 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.
Yes.
> 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.
Yes. The policy emulation using combined version check and variable is
probably the best way forward.
In that case upstreamConfig.cmake would look something like this:
include("${CMAKE_CURRENT_LIST_DIR}/upstreamTargets.cmake")
if (PACKAGE_FIND_VERSION VERSION_LESS 2.3)
foreach(_target ${maintained_list_of_targets})
set_target_property(${_target}
INTERFACE_INCLUDE_DIRECTORIES ""
)
endforeach()
endif()
The maintained_list_of_targets would have to be hand-maintained currently.
It might be an idea to 'leak' a variable out of the targets file containing
the list of targets, but I'm not sure that's a good idea.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
