Re: [cmake-developers] Handling of Config specific imported targets?
Stephen Kelly wrote: Yes, ok I'll take that approach. This is just a documentation change: -- 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
Re: [cmake-developers] Handling of Config specific imported targets?
Stephen Kelly wrote: Yes, ok I'll take that approach. This is just a documentation change: https://codereview.qt-project.org/#change,26541 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
Re: [cmake-developers] Handling of Config specific imported targets?
Brad King wrote:
On 05/17/2012 09:41 AM, Stephen Kelly wrote:
Great, so choosing the correct imported configuration a solved problem.
I'll point the documentation in of the Qt 5 CMake stuff to that so.
Note that MAP_IMPORTED_CONFIG_CONFIG should not be set by package
configuration files. It should only be set in the CMakeLists.txt files
of the project *loading* them. Only the application knows its own list
of configurations. The documentation of the package should list the
valid configurations to which one may map.
Am I right that it is appropriate to create imported targets without a
_${Config} though?
It shouldn't be necessary to create the non-config one. If only
IMPORTED_LOCATION_DEBUG and IMPORTED_LOCATION_RELEASE are set and not
IMPORTED_LOCATION then the default behavior will still choose one of
the available configurations. Just be sure to list all the available
configurations in IMPORTED_CONFIGURATIONS.
Yes, ok I'll take that approach.
I'll also reverse the order of creating those IMPORTED_CONFIGURATIONS too so
that Windows users will get Release unless they use Debug or do the mapping
stuff. That way they will also get the Release version if they use
RelWithDebInfo or MinSizeRel, which seem to be built into CMake.
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
[cmake-developers] Handling of Config specific imported targets?
Hi there,
In Qt 5 we currently generate IMPORTED_LOCATION_${Config} for the Debug or
Release (or both, depending on platform), depending on how Qt is configured.
If both exist (on windows) and the caller uses CMAKE_BUILD_TYPE == Debug or
Release, the correct location should be used. However, this doesn't account
for having a different or empty CMAKE_BUILD_TYPE.
If the Config doesn't match any available IMPORTED_LOCATION_${Config}, then
it seems from my testing that the first one set is chosen. This means that
for example if I have a PROFILING Configuration, which should use the
release libraries, but Debug appears first in the generated Config file (as
it does), then the wrong IMPORTED_LOCATION would be used.
I have written a patch that changes the behavior to not create a
IMPORTED_LOCATION_${Config} for both Debug and Release unless necessary. If
only building Debug or only building Release, only the IMPORTED_LOCATION
will be specified. If building debug_and_release, then IMPORTED_LOCATION
will refer to the Release location, and IMPORTED_LOCATION_DEBUG will refer
to the debug location.
https://codereview.qt-project.org/#change,26116
I'm looking for some review of the approach, and some confirmation of how
non-matching configurations are handled. Does it make sense?
In particular, with this set-up, how would a downstream create a
configuration which should use the debug libraries, but where they have
built Qt with debug_and_release (the default on Windows)? Would they have to
create another IMPORTED_LOCATION_Foo for all targets themselves?
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
Re: [cmake-developers] Handling of Config specific imported targets?
On 05/16/2012 06:42 AM, Stephen Kelly wrote:
In Qt 5 we currently generate IMPORTED_LOCATION_${Config} for the Debug or
Release (or both, depending on platform), depending on how Qt is configured.
If both exist (on windows) and the caller uses CMAKE_BUILD_TYPE == Debug or
Release, the correct location should be used. However, this doesn't account
for having a different or empty CMAKE_BUILD_TYPE.
We already have some logic to account for a mismatch between the set of
valid configurations in the exporting v. importing project. See logic
here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v2.8.8#l4093
and these properties:
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#prop_tgt:LOCATION_CONFIG
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#prop_tgt:MAP_IMPORTED_CONFIG_CONFIG
CMake code should only ever *set* the IMPORTED_LOCATION properties.
If it wants to *get* the location it should use LOCATION_CONFIG.
CMake will follow the above approach to find a suitable match for
the requested CONFIG.
-Brad
--
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
