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

[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] How to set startup project in Visual Studio

[J Decker]

The setting is in a different file that's .vcproj.user (or .user.vcproj)

and cmake doesn't write that... would be nice if it could at least write
those entiries required... nice thing about xml should be that what's there
can be read and used and filled in with the rest of the settings?  Well I
guess that's really implementation dependant.

On Sun, Jun 19, 2016 at 2:42 PM, Mike Gelfand  wrote:

> Hello,
>
> On 06/18/2016 03:15 PM, Stephen Kelly wrote:
> > a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project
> in
> > Visual Studio. I tried it in the 3.6 RC and it works fine if I set the
> > property in the top-level directory, so thanks for that.
> >
> > However, the documentation does not say which directory to set it in, or
> why
> > it is a DIRECTORY property.
> >
> > Why is this not a GLOBAL property?
> My guess would be because CMake generates .sln file for each project()
> call (e.g. if you have additional project() calls in subdirectories
> apart from the top-level one), and then for each .sln file it would be
> possible to specify different startup [VS] project. So it's not exactly
> a directory, but a project property I would say, but there're no
> "project properties" in CMake.
>
> 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
>
-- 

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] How to set startup project in Visual Studio

[Mike Gelfand]

Hello,

On 06/18/2016 03:15 PM, Stephen Kelly wrote:
> a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project in 
> Visual Studio. I tried it in the 3.6 RC and it works fine if I set the 
> property in the top-level directory, so thanks for that.
>
> However, the documentation does not say which directory to set it in, or why 
> it is a DIRECTORY property. 
>
> Why is this not a GLOBAL property?
My guess would be because CMake generates .sln file for each project()
call (e.g. if you have additional project() calls in subdirectories
apart from the top-level one), and then for each .sln file it would be
possible to specify different startup [VS] project. So it's not exactly
a directory, but a project property I would say, but there're no
"project properties" in CMake.

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

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

[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

Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi Brad,

Am 17.06.2016 22:09 schrieb "Brad King" :
> Then I applied the patches with some revisions:
>
>  cmGeneratorTarget: Adopt Fortran module directory generation
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49f10f0d
>
>  cmLocalGenerator: Add method to get Fortran-specific compiler flags
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5467e794
>
>  cmLocalGenerator: Adopt target compile flag generation
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c488ce8
>
>  cmExtraSublimeTextGenerator: Use GetTargetCompileFlags
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802b36fb
>
> These have been merged to `next` for testing.

Wonderful! Thanks for improving the patches

I'll rebase my branch on top of these as soon as they hit master.

Best Regards,
Tobias
-- 

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] daemon-mode: Infrastructure

[Tobias Hunger]

Hi Brad,
Am 17.06.2016 22:24 schrieb "Brad King" :
>
> On 06/13/2016 08:00 PM, Tobias Hunger wrote:
> > * There will always be 1 client talking to a server.
> > * Client/Server communicate using JSON messages
>
> Yes.  IIRC it is using stdin/stdout (I haven't checked the code),
> so limiting to one client is implicit.

True. Still it does not hurt to state explicitly, especially considering
that I think of the stdin/out as an implementation detail. There is no
reason for the code not to switch to pipes or sockets for communication.

> In this case, is it actually a daemon?  It is not expected to outlive
> the client that started it.  Perhaps we should consider a different name.

I am bad at names:-)

Plus Stephen made quite a bit of PR for the CMake daemon idea.

> One possible problem with using stdin/stdout is that when CMake runs the
> configuration the project code can do things like execute_process that
> may share the stdout with the child process.  That may allow the child
> process to print content formatted to look like the protocol and trick
> the client.  Ideally all output handling would avoid printing things to
> stdout in server/daemon mode, but that may take some effort to achieve.

Yes, unexpected output on stdout could cause havok to the parser. So far
this worked well though, and the magic string before/after messages
prevented any unexpected interactions.

> > What do you think? Does this make sense?
>
> It sounds fine to me.  I'll state the caveat that I've had little
experience
> in maintaining versioned protocols like this though.  Hopefully others can
> review this too.

Yes, I hope other IDE developers will chime in at some point...

> On 06/14/2016 04:30 AM, Tobias Hunger wrote:
> > I think it would make perfect sense to ship the first cmake version with
> > included daemon-mode with a big, fat warning that the interfaces are not
> > finalized yet and will change in incompatible ways during the first
release
> > cycle (or maybe two:-).
>
> Yes.  Should we make the option to activate it different, and include
> "experimental" in its name?  I think the idea is that no clients should
> be released that depend on the experimental behavior in CMake.

I now added a patch that allows protocol versions to be marked as
experimental. These are only visible to clients that started "cmake -E
daemon --experimental".

The only existing protocol version is now marked experimental.

I think that makes it pretty clear what is experimental and what is not and
clients do not need to change (except for maybe dropping the --experimental
flag) to go to a stable interface once we are satisfied with the first
version.

Best Regards,
Tobias
-- 

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

[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