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
