Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

[CHEVRIER, Marc]

Hi,

I identify the root of the problem: if I specify version 3.4 in 
cmake_minimum_required, generated link command (stored in file link.txt) for an 
executable does not contains value specified in variable 
CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem. So 
this is a regression introduced in 3.4.

Problem can be reproduced using this very simple CMakeLists.txt:
cmake_minimum_required (VERSION 3.4)

project (TEST LANGUAGES CXX)

file (WRITE test.cpp "// empty\n")

add_executable (test_exe test.cpp)

This problem occurs on all platforms (tested on AIX and Linux).

Marc




On 09/12/15 15:41, "cmake-developers on behalf of CHEVRIER, Marc" 
 wrote:

>
>Oops !
>You are right, on a simple example, all is OK. So the problem seems on my side.
>I will investigate this curious behaviour…
>
>Sorry for the noise.
>
>Marc
>
>
>
>
>On 09/12/15 15:15, "Brad King"  wrote:
>
>>On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote:
>>> You are right. I missed this capability.
>>> My first idea was to apply to exec the same approach as for shared lib but 
>>> I didn’t found appropriate variable: something like 
>>> CMAKE_EXE_CREATE__FLAGS
>>> Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the 
>>> usage of the *_INIT variables.
>>
>>Actually the old code has it in two places:
>>
>>> - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # 
>>> -shared
>>> - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS 
>>> "-Wl,-brtl,-bnoipath,-bexpall") # +s, flag for exe link to use shared lib
>>
>>The CREATE_ value is used when linking a shared library itself.
>>The LINK_ value is used to link executables.  Both should already
>>be getting the flag with no changes.
>>
>>-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
-- 

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] Please comment on ios-universal topic

[Ruslan Baratov via cmake-developers]

On 10-Dec-15 13:55, Gregor Jasny wrote:

Hello,

On 09/12/15 10:21, Ruslan Baratov wrote:

IOS_INSTALL_COMBINED_BINARY


Just to clarify you want to leave only one variable
IOS_INSTALL_COMBINED_BINARY for the device + simulator on iOS platforms.
Other platforms (in future) will be controlled by using *_ARCHITECTURES
variables, right?


Right. Any objections to that property name?

Thanks,
Gregor


TL;DR I'm finding it a little bit confusing but can't propose any better 
alternatives so I have no objections :)


Some thoughts:
* arm64 + armv7 is a universal binary, arm64 + armv7 + i386 - well, 
still universal binary too :)
* OSX_ARCHITECTURES affect architectures on iOS. Probably it should be 
IOS_ARCHITECTURES or just ARCHITECTURES (though MACOSX_BUNDLE works same 
way)
* OSX_ARCHITECTURES=armv7 -> build armv7, OSX_ARCHITECTURES=armv7,arm64 
-> build universal armv7+arm64, but OSX_ARCHITECTURES=armv7,arm64,i386 
doesn't build armv7+arm64+i386 binary
* hard to say anything about future improvements, like if it will be 
easier to implement universal binary in build directory on Android, then 
*_ARCHITECTURES looks better. but if it will be easier to build one 
architecture then add extra code to add more on install then 
INSTALL_UNIVERSAL_BINARY for all platforms looks better


Ruslo
--

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][PATCH] AIX RPATH handling

[Brad King]

On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote:
> I identify the root of the problem: if I specify version 3.4 in
> cmake_minimum_required, generated link command (stored in file link.txt)
> for an executable does not contains value specified in variable
> CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem.
> So this is a regression introduced in 3.4.

It is not technically a backward incompatibility because project code
that worked in 3.3 will still work the same way in 3.4.  Only after
modifying the code to require 3.4 does the behavior change, but the
new behavior is a regression.  This is policy CMP0065:

 https://cmake.org/cmake/help/v3.4/policy/CMP0065.html

introduced here:

 CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9784af1b

The bug is that CMAKE_SHARED_LIBRARY_LINK__FLAGS is intended
to be equivalent to "-rdynamic" on Linux, but the AIX platform file
is using it for other flags too:

> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall")

This should be just

 set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-bexpall")

and the `-Wl,-brtl,-bnoipath` flags should move elsewhere.  One could
add them directly to the CMAKE_${lang}_LINK_EXECUTABLE command line,
for example.

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] [CMake][PATCH] AIX RPATH handling

[CHEVRIER, Marc]

Ok. I see the problem. Thanks for your investigation.
I will work on that and submit a patch to solve this problem.

Marc





On 10/12/15 14:42, "Brad King"  wrote:

>On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote:
>> I identify the root of the problem: if I specify version 3.4 in
>> cmake_minimum_required, generated link command (stored in file link.txt)
>> for an executable does not contains value specified in variable
>> CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem.
>> So this is a regression introduced in 3.4.
>
>It is not technically a backward incompatibility because project code
>that worked in 3.3 will still work the same way in 3.4.  Only after
>modifying the code to require 3.4 does the behavior change, but the
>new behavior is a regression.  This is policy CMP0065:
>
> https://cmake.org/cmake/help/v3.4/policy/CMP0065.html
>
>introduced here:
>
> CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9784af1b
>
>The bug is that CMAKE_SHARED_LIBRARY_LINK__FLAGS is intended
>to be equivalent to "-rdynamic" on Linux, but the AIX platform file
>is using it for other flags too:
>
>> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall")
>
>This should be just
>
> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-bexpall")
>
>and the `-Wl,-brtl,-bnoipath` flags should move elsewhere.  One could
>add them directly to the CMAKE_${lang}_LINK_EXECUTABLE command line,
>for example.
>
>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] set(CACHE) and the local scope

[Brad King]

On 12/09/2015 05:35 PM, Ben Boeckel wrote:
> So some behavior I was unaware of until today came up:
> 
> set(var ON)
> option(var "description" OFF)
> message("var: ${var}")
> 
> outputs "OFF" for the first configure and "ON" for subsequent
> configures. This is because set(var CACHE) does unset(var) *if* the
> cache was touched. This is not done on the second time around since it
> is already in the cache.

That is a long-standing subtlety introduced without discussion, review,
or tests here:

 BUG: change in how set cache overrides local definitions. Should mainly be a 
NOP change for most cases
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2

IIRC there was confusion at the time in the case of

 set(var 1)
 set(var 2 CACHE STRING ...)
 message("${var}") # prints "1" before the above change.

> I think a policy to remove the unset(var) behavior should be added since
> the current behavior means that clean builds can be wildly different
> than incremental builds.

One reason a policy has not been introduced for this before is that
producing a warning for the policy may be very verbose unless it is
delayed until variable dereference, but the latter would be a huge
performance hit to check.  Still, I think things would be better off
in the long run with some policy for it.

> Related, I have a branch on the stage (update-variable-docs) which
> attempts to clarify some darker corners of the set() command and the
> *VARIABLES directory properties.

The "LOCAL_VARIABLES" change uses "SCOPE_VARIABLES" in some places.
The release note should only cover the new feature.

-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] [PATCH] Support multiple directories by "cmake -E make_directory" command

[Brad King]

On 12/09/2015 03:01 PM, Bartosz Kosiorek wrote:
> support for multiple directories for make_directory command.

Thanks.  Applied with minor documentation tweak:

 cmake: Teach -E make_directory to support multiple input directories
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7984ac5e

-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] set(CACHE) and the local scope

[Ben Boeckel]

On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote:
> That is a long-standing subtlety introduced without discussion, review,
> or tests here:
> 
>  BUG: change in how set cache overrides local definitions. Should mainly be a 
> NOP change for most cases
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2
> 
> IIRC there was confusion at the time in the case of
> 
>  set(var 1)
>  set(var 2 CACHE STRING ...)
>  message("${var}") # prints "1" before the above change.

The above commit has the same behavior as it does today: first configure
!= subsequent configure, so I don't see the confusion as being *less*
after the fix since any existing tree wouldn't say "2" either, but I
suppose it was something about dashboards doing clean builds.

> On 12/09/2015 05:35 PM, Ben Boeckel wrote:
> > I think a policy to remove the unset(var) behavior should be added since
> > the current behavior means that clean builds can be wildly different
> > than incremental builds.
> 
> One reason a policy has not been introduced for this before is that
> producing a warning for the policy may be very verbose unless it is
> delayed until variable dereference, but the latter would be a huge
> performance hit to check.  Still, I think things would be better off
> in the long run with some policy for it.

Like with some of the more disruptive policies (e.g., CMP0054), it's a
clarification of some potentially^Wconfusing behavior which can bite you
in certain cases pretty hard (CI vs. developer builds).

> The "LOCAL_VARIABLES" change uses "SCOPE_VARIABLES" in some places.
> The release note should only cover the new feature.

Oops. Updated. Also reordered the branch so the feature is at the end of
the branch.

--Ben
-- 

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] [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Bartosz Kosiorek]

Hello.


With CMake 3.5 it is possible to put Resources into the Bundle (Frameworks and 
Applications)


More information:

https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/prop_tgt/RESOURCE.rst


So with code:

  add_executable(ExecutableTarget
addDemo.c
resourcefile.txt
appresourcedir/appres.txt
  )

  target_link_libraries(ExecutableTarget heymath mul)

  set(RESOURCE_FILES
resourcefile.txt
appresourcedir/appres.txt
  )

  set_target_properties(ExecutableTarget PROPERTIES
MACOSX_BUNDLE TRUE
MACOSX_FRAMEWORK_IDENTIFIER org.cmake.ExecutableTarget
RESOURCE "${RESOURCE_FILES}"
  )

For OS X systems it will produce following directory structure::

  ExecutableTarget.app/
Contents
  Info.plist
  MacOS
ExecutableTarget
  Resources
appres.txt
resourcefile.txt


How it is officialy supported to tell CMake to create subdirectories inside 
"Resources" directory?


As the result I would like to get, following directory structure:

  ExecutableTarget.app/
Contents/
  Info.plist
  MacOS/
ExecutableTarget
  Resources/
appres.txt?

appresourcedir/

   ?resourcefile.txt?


I would like to update documentation to describe how to do that.


Thanks in advance

Bartosz

-- 

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] [PATCH] Add Clang support to FindOpenMP

[Chris Pavlina]

Hi,

Attached is a patch to add the correct option for building OpenMP code using 
Clang. Per the llvm release notes 
 it is 
necessary to give -fopenmp=libomp to build properly, not just -fopenmp. Tested 
on 64-bit Linux using clang 3.7.0.

Chris

>From f80164de4b51afc7cdcc053346c696ea2baaa4a4 Mon Sep 17 00:00:00 2001
From: Chris Pavlina 
Date: Thu, 10 Dec 2015 10:40:27 -0500
Subject: [PATCH] Add Clang support to FindOpenMP

---
 Modules/FindOpenMP.cmake | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Modules/FindOpenMP.cmake b/Modules/FindOpenMP.cmake
index a102c66..ee4bdd6 100644
--- a/Modules/FindOpenMP.cmake
+++ b/Modules/FindOpenMP.cmake
@@ -50,6 +50,8 @@ function(_OPENMP_FLAG_CANDIDATES LANG)
 " "
 #GNU
 "-fopenmp"
+#Clang
+"-fopenmp=libomp"
 #Microsoft Visual Studio
 "/openmp"
 #Intel windows
@@ -67,6 +69,7 @@ function(_OPENMP_FLAG_CANDIDATES LANG)
   )
 
   set(OMP_FLAG_GNU "-fopenmp")
+  set(OMP_FLAG_Clang "-fopenmp=libomp")
   set(OMP_FLAG_HP "+Oopenmp")
   if(WIN32)
 set(OMP_FLAG_Intel "-Qopenmp")
-- 
2.6.4

-- 

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] [PATCH] Add Clang support to FindOpenMP

[Brad King]

On 12/10/2015 10:49 AM, Chris Pavlina wrote:
> Attached is a patch to add the correct option for building OpenMP
> code using Clang.

Thanks, applied:

 FindOpenMP: Add Clang support
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1549927d

-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] set(CACHE) and the local scope

[Alexander Neundorf]

On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote:
> Hi,
> 
> So some behavior I was unaware of until today came up:
> 
> set(var ON)
> option(var "description" OFF)
> message("var: ${var}")

Assuming I wouldn't know about the subtle characteristics of normal vs. 
cache variables, I think I would expect that var has the value of the option 
afterwards.

I.e. on the first run it would be OFF (since that's the default value of the 
option), and all later runs it would have the value which is in the cache.

Alex

-- 

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] set(CACHE) and the local scope

[Brad King]

On 12/10/2015 03:20 PM, Alexander Neundorf wrote:
>> set(var ON)
>> option(var "description" OFF)
>> message("var: ${var}")
> 
> I.e. on the first run it would be OFF (since that's the default value
> of the option), and all later runs it would have the value which is in the 
> cache.

This is calling for the opposite change than Ben's proposal.  Ben
suggests never unsetting the local value to expose the cached value.
Alex is suggesting always doing so, even if the cache option is
not created by the command.

Alternatively the option() or set(CACHE) commands could also set
a local variable to the same value as the cache entry.

This is pretty fundamental behavior so if we are going to mess with
it through a policy we better get it right.

-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] set(CACHE) and the local scope

[Alexander Neundorf]

On Thursday, December 10, 2015 15:26:54 Brad King wrote:
> On 12/10/2015 03:20 PM, Alexander Neundorf wrote:
> >> set(var ON)
> >> option(var "description" OFF)
> >> message("var: ${var}")
> > 
> > I.e. on the first run it would be OFF (since that's the default value
> > of the option), and all later runs it would have the value which is in 
the
> > cache.
> This is calling for the opposite change than Ben's proposal.  Ben
> suggests never unsetting the local value to expose the cached value.
> Alex is suggesting always doing so, even if the cache option is
> not created by the command.
> 
> Alternatively the option() or set(CACHE) commands could also set
> a local variable to the same value as the cache entry.
> 
> This is pretty fundamental behavior so if we are going to mess with
> it through a policy we better get it right.

Yes. :-)

My motivation: if the option() would just set/get the cache variable, and 
leave the local variable untouched, it would be a NOOP in the example 
above, and this is not obvious from seeing that code.

Alex

-- 

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] set(CACHE) and the local scope

[Ben Boeckel]

On Thu, Dec 10, 2015 at 21:20:21 +0100, Alexander Neundorf wrote:
> On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote:
> > So some behavior I was unaware of until today came up:
> > 
> > set(var ON)
> > option(var "description" OFF)
> > message("var: ${var}")
> 
> Assuming I wouldn't know about the subtle characteristics of normal vs. 
> cache variables, I think I would expect that var has the value of the option 
> afterwards.
> 
> I.e. on the first run it would be OFF (since that's the default value of the 
> option), and all later runs it would have the value which is in the cache.

The problem with this behavior is that if I do -Dinternal_var:BOOL=OFF,
it will override any variable of that name inside the project and it
cannot override it without knowing it is in the cache to unset it so
that the local variable is used again.

This behavior also breaks cmake_dependent_option as-is since it sets a
local variable to the fallback value if its requirements are not met
(which is how it remembers the user decision when it becomes a viable
option again).

--Ben
-- 

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] [PATCH] Imported targets for FindGTest

[rleigh]

Pushed to

  https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/gtest-
imported-targets

and merged into next for review and testing.

- Adds GTest::GTest and GTest::Main imported targets (including
Thread::Thread dependency for GTest::GTest and GTest::GTest for
GTest::Main; the latter might not be appropriate and could be removed if
needed--but I'm unaware of any situation where you would want to use
GTest::Main without GTest::GTest)
- Document imported targets
- Update documentation, adding sections, description lists and updated
examples
- Add unit test to test imported targets and existing variables


Kind regards,
Roger

-- 

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] [PATCH] Imported targets for FindGTest

[rleigh]

> - Adds GTest::GTest and GTest::Main imported targets (including
> Thread::Thread dependency for GTest::GTest and GTest::GTest for
> GTest::Main; the latter might not be appropriate and could be removed if
> needed--but I'm unaware of any situation where you would want to use
> GTest::Main without GTest::GTest)

Double-checking the gtest_main symbol table, it depends on symbols from
gtest, so the dependency is actually required, so please ignore the
above--it's definitely appropriate.

-- 

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] set(CACHE) and the local scope

[Nagger]

Am 10.12.2015 um 21:26 schrieb Brad King:
Alternatively the option() or set(CACHE) commands could also set a 
local variable to the same value as the cache entry. 


I would vote for that.
Maybe optional arguments to set(CACHE) could be introduced to switch the 
behavior.

Like set(... CACHED ... [UNSET_LOCAL] [OVERWRITE_LOCAL] [KEEP_LOCAL]).

What about locals in parent scopes, overwrite all of them?


Bug https://public.kitware.com/Bug/view.php?id=15448 is kind of related, 
and also shows some weird effects of the current implementation.



Marc



--

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] [PATCH] Imported targets for FindGTest

[rleigh]

> - Add unit test to test imported targets and existing variables

I should mention that to run the unit test, you must define the GTEST_ROOT
environment variable to point to the gtest build, due to gtest being
annoyingly crippled to be uninstallable for dubious reasons.  You can pass
-DGTEST_ROOT, but since the cmake build can't pass it through without
further changes, the environment variable is the only way to run the test
with the existing patches.


Regards,
Roger

-- 

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] [CMake 0015877]: Performance regression in file generation

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15877 
== 
Reported By:Jim King
Assigned To:
== 
Project:CMake
Issue ID:   15877
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-11 00:50 EST
Last Modified:  2015-12-11 00:50 EST
== 
Summary:Performance regression in file generation
Description: 
There was a significant performance regression between CMake 2.8 and 3.4
between "-- Configuring done" and "--Generating done" phases.  We have a rather
large project with a number of files and here are the timing results:

CMake-3.4

39.27user 10.14system 0:50.62elapsed 97%CPU (0avgtext+0avgdata
119384maxresident)k
40inputs+167408outputs (0major+254266minor)pagefaults 0swaps

CMake-2.8

21.97user 8.09system 0:32.09elapsed 93%CPU (0avgtext+0avgdata
163040maxresident)k
8400inputs+172200outputs (30major+266779minor)pagefaults 0swaps

We're generating on Ubuntu 14.04 LTS with the command:
CC=clang CXX=clang++ time /usr/bin/cmake -G"Eclipse CDT4 - Unix Makefiles"

I could not find a defect for this so I decided to add one.

Steps to Reproduce: 
See description.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-11 00:50 Jim King   New Issue
==

-- 

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