Re: [cmake-developers] Imported Locations in FindBoost.cmake

2016-06-20 Thread Brad King 
Hi Folks,

For reference, there is an issue tracker entry for this problem:

 https://gitlab.kitware.com/cmake/cmake/issues/16091

Similar alternatives have been discussed there.

On 06/20/2016 01:32 AM, Andreas Weis wrote:
> On 6/19/2016 9:17 PM, Mike Gelfand wrote:
>> The suggested way to deal with this seems to be to use
>> MAP_IMPORTED_CONFIG_ target properties

That property is meant for client code to set when it has a different
set of configurations than those imported.  Technically that is true
here, but CMake should have better default behavior for the builtin
configurations like RelWithDebInfo.

> I'm still unsure what to make of the current
> fallback-to-first-configuration behavior. I did not find this mentioned
> anywhere in the docs, so I guess it's not a behavior one should rely upon?
> I was wondering whether it would make sense to properly define what
> CMake does in such a case. In particular since, as you mentioned,
> package configuration files might already rely on some assumptions there.

There is discussion about this in the above-linked issue.

I think switching the order of configurations is a good solution
to use until the alternatives can be considered:

 FindBoost: Make imported targets fall back to `Release`
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c9fca42f

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Imported Locations in FindBoost.cmake

2016-06-19 Thread Andreas Weis 

On 6/19/2016 9:17 PM, Mike Gelfand wrote:
>
> The suggested way to deal with this seems to be to use
> MAP_IMPORTED_CONFIG_ target properties, but I suppose it should
> only (?) be used when imported target (or target it's being linked to)
> has non-standard configurations, which isn't so in this case.
>

Alternatively, maybe it makes sense for FindBoost to simply set all
configurations explicitly?
By iterating over CMAKE_CONFIGURATION_TYPES (or inspecting
CMAKE_BUILD_TYPE for single-config generators) and using the global
property DEBUG_CONFIGURATIONS to determine whether a given configuration
needs the debug or the release binaries.

I'm still unsure what to make of the current
fallback-to-first-configuration behavior. I did not find this mentioned
anywhere in the docs, so I guess it's not a behavior one should rely upon?
I was wondering whether it would make sense to properly define what
CMake does in such a case. In particular since, as you mentioned,
package configuration files might already rely on some assumptions there.

Best regards,
Andreas
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Imported Locations in FindBoost.cmake

2016-06-19 Thread Mike Gelfand 
Hello,


On 06/19/2016 02:00 PM, Andreas Weis wrote:
> After fiddling around with the issue, I found that reversing the order
> in which the IMPORTED_LOCATION_* fields on the imported target are being
> set resolves the issue. It seems that the first configuration that's
> added here will be used as a default for the not explicitly added
> configurations?
Seems to be true for me as well. I don't think just reverting the order
is a proper fix though.

Consider exported target configuration files generated by the CMake
itself. They consist of .cmake and a set of -.cmake files which are included from the former in
unknown order. At east file(GLOB) documentation doesn't specify the
order, but even if it's sorted alphabetically then -debug.cmake always comes before -release.cmake or
-relwithdebinfo.cmake.

The suggested way to deal with this seems to be to use
MAP_IMPORTED_CONFIG_ target properties, but I suppose it should
only (?) be used when imported target (or target it's being linked to)
has non-standard configurations, which isn't so in this case. Mapping
Release to "Release;RelWithDebInfo" and RelWithDebInfo to
"RelWithDebInfo;Release" looks odd enough (and I didn't add MinRelSize
here). Maybe there should exist some default mapping built-in with the
similar effect?..

Regards,
Mike
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Imported Locations in FindBoost.cmake

2016-06-19 Thread Andreas Weis 
Hi there,

I ran into a small issue with the new imported target interface of
FindBoost.cmake.

Just like the old variable-based interface, the script only detects
Debug and Release configurations of installed Boost binaries.

In the old interface, the debug binaries where used only for debug
builds (care of the debug keyword in the classic target_link_libraries
function), while the release binaries were used for all other
configurations (optimized keyword).

It seems that with the new interface, this was inverted. On MSVC for
instance, the RelWithDebInfo and MinSizeRel configurations use the debug
binaries of Boost. This is not desirable and can even break those
configurations on MSVC due to inconsistent use of the debug runtime and
STL debug iterators.

After fiddling around with the issue, I found that reversing the order
in which the IMPORTED_LOCATION_* fields on the imported target are being
set resolves the issue. It seems that the first configuration that's
added here will be used as a default for the not explicitly added
configurations?

I attached a small patch to demonstrate what I mean, but I am unsure if
this is a proper fix for the issue.

Thanks and regards,
Andreas
From c201749b494c5aa44d7cc6c9139d8c71db849cf2 Mon Sep 17 00:00:00 2001
From: Andreas Weis 
Date: Sun, 19 Jun 2016 12:44:29 +0200
Subject: [PATCH] Switched order of adding locations to imported target

FindBoost only detects Debug and Release configurations; All other
configurations will fall back to whichever IMPORTED_LOCATION_ was
added *first*. This change makes sure that that is the Release
configuration. Adding Debug first is likely to cause conflicts on MSVC,
where the Debug runtime is not to be used for RelWithDebInfo and
MinSizeRel builds.
---
 Modules/FindBoost.cmake | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 6bf6401..2560459 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -1734,13 +1734,6 @@ if(Boost_FOUND)
 IMPORTED_LINK_INTERFACE_LANGUAGES "CXX"
 IMPORTED_LOCATION "${Boost_${UPPERCOMPONENT}_LIBRARY}")
 endif()
-if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
-  set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
-IMPORTED_CONFIGURATIONS DEBUG)
-  set_target_properties(Boost::${COMPONENT} PROPERTIES
-IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
-IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
-endif()
 if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}")
   set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
 IMPORTED_CONFIGURATIONS RELEASE)
@@ -1748,6 +1741,13 @@ if(Boost_FOUND)
 IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
 IMPORTED_LOCATION_RELEASE 
"${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}")
 endif()
+if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
+  set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
+IMPORTED_CONFIGURATIONS DEBUG)
+  set_target_properties(Boost::${COMPONENT} PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
+IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
+endif()
 if(_Boost_${UPPERCOMPONENT}_DEPENDENCIES)
   unset(_Boost_${UPPERCOMPONENT}_TARGET_DEPENDENCIES)
   foreach(dep ${_Boost_${UPPERCOMPONENT}_DEPENDENCIES})
-- 
2.5.0.windows.1

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers