Re: [CMake] "Pre-configure" step in CMake

[Petr Kmoch]

Hi Matthaus,

do you need the pre-configure step to happen at build time? Would it be an
option for you to use file(WRITE) instead of configure_file(), and
execute_process() instead of add_custom_target()? Basically, perform the
pre-configure step as part of the first CMake run itself.

Alternatively, you could look into the ExternalProject module, which is (I
believe) designed for situations like yours:
http://cmake.org/cmake/help/v3.3/module/ExternalProject.html

The basic idea of ExternalProject is that you create one top-level,
"SuperBuild" project, which will include each dependency as an external
project, and your real project *as an external project too.* That way, you
can easily gather all dependencies by building the "SuperBuild". Then you
switch to working just with your own project inside the SuperBuild
structure, but all the dependencies are already there.

(Note: I've never used ExternalProject myself, this info comes from what
I've learned on this mailing list from other people using it).

Hope this helps,

Petr

On Wed, Sep 23, 2015 at 9:49 PM, Matthäus G. Chajdas 
wrote:

> Hi,
>
> I'm trying to solve the following the problem: I have a C++ application
> and a dependency fetching script. I want to simplify the initial build
> such that the following happens: On the first run of cmake, the compiler
> ID and version is passed to an external script, which fetches some
> pre-build binaries. It then writes a CMake file which contains basically
> only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir)
> commands. CMake would then read this file and subsequent find_library
> calls would pick up the values from this new CMake file. The idea is
> that "actual" build is dependent on this first dependency step, but it's
> already within the CMake framework so I can grab the compiler info and
> other build info.
>
> The obvious problem is that while I can easily run the external script
> by using configure_file, and have a custom target that does the
> dependency fetching and CMake configure file generation. But I don't see
> an easy way to get CMake to make the "rest of the project" depend on
> that configure file. How can I make such a "two-stage" build with CMake?
>
> Cheers,
>   Matthäus
> --
>
> 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
-- 

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

[CMake] Build log generation in a "custom" way

[Attila Krasznahorkay]

Dear All,

I'd like to ask for some advice about the following issue. We're migrating a 
very big project (millions of lines of code...) from a custom build manager to 
CMake.

The software is put together from separate "packages" that are all developed by 
a different set of people. Our nightly build system collects all these 
packages, and compiles all of them. In our old build system we could easily 
save package-specific build log files for the nightly system. Making it easy 
for the developers to quickly find build problems in their specific package.

Now we'd like to do something similar with CMake. To teach it how to generate 
separate build log files for the separate packages. (Packages in this context 
are really just subdirectories in the end.) The clumsy thing that we're doing 
now is to use a script that we set for RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, 
and RULE_LAUNCH_CUSTOM. This script writes log files in a non-too-perfect way, 
which need to be stitched together at the end of the build to get "package 
specific" build log files.

So the question is whether we could do something better. Does anyone have an 
idea/suggestion? I'm happy to give more information about our setup if needed.

Cheers,
  Attila
-- 

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

Re: [CMake] Generated .rc files silently ignored

[Mueller-Roemer, Johannes Sebastian]

Hej hej,

for some reason your mail was not delivered to me and I only stumbled upon it 
by chance in the archives (while trying to find out where another one of my 
mails to the list disappeared to).

In any case, yes, I am adding the .rc file to my add_library command. The issue 
I have is that if I use mylib.rc in add_library and have an 
add_custom_command(OUTPUT mylib.rc ...) nothing is created but no error message 
is produced either (i.e. silently ignored). I have to use 
${CMAKE_CURRENT_BINARY_DIR}/mylib.rc explicitly. For most files (such as 
generated .cpp files) using a relative path just works, because relative paths 
used in add_custom_command are interpreted relative to 
${CMAKE_CURRENT_BINARY_DIR}.

Original text:

Hej,

Some more information about how you setup things would be useful. For instance: 
you would need to add the filename of the generated .rc file to the 
executable/library for which it is generated: are you doing that?

In the application I currently work on, we have created a small function to 
wrap the generation of the .rc file. I just checked that we actually also build 
a full path. That actually makes sense, because the generated file is put in 
the ${CMAKE_CURRENT_BINARY_DIR} and *not* in the current source dir. In other 
words: we could never accomplish this with any type of 'relative' path anyway. 
Are you maybe also mixing up the *SOURCE_DIR and *BINARY_DIR?

Sincerely,
Jakob

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de  |  www.igd.fraunhofer.de

-- 

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

[cmake-developers] Patch: install universal iOS libraries

[Ruslan Baratov via cmake-developers]

Hi,

Patches help to install universal iOS (device + simulator) libraries by 
triggering some extra instructions (build + fuse) after "regular" 
library installation finished. This behavior controlled by CMake 
variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS.


= Example =

> cat CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(Foo)

add_library(foo foo.cpp)

install(TARGETS foo DESTINATION lib)

> cat toolchain.cmake
set(CMAKE_MACOSX_BUNDLE YES)
set(CMAKE_OSX_SYSROOT "iphoneos")
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer")
set(MACOSX_BUNDLE_GUI_IDENTIFIER "com.example")

> rm -rf _builds _install
> cmake -H. -B_builds -GXcode -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake 
-DCMAKE_INSTALL_PREFIX=_install ...


= Current functionality =

Device one arch (default):

> cmake ...
> cmake --build _builds --target install
> lipo -info _install/lib/libfoo.a
Non-fat file: _install/lib/libfoo.a is architecture: armv7

Simulator one arch:

> cmake ...
> cmake --build _builds --target install -- -sdk iphonesimulator
> lipo -info _install/lib/libfoo.a
Non-fat file: _install/lib/libfoo.a is architecture: x86_64

Device multi arch:

> cmake ... -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO
> cmake --build _builds --target install
> lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: armv7 arm64

Simulator multi arch:

> cmake ... -DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO
> cmake --build _builds --target install -- -sdk iphonesimulator
> lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: i386 x86_64

= This upgrade =

Device + simulator one arch:

> cmake ... -DCMAKE_IOS_INSTALL_UNIVERSAL_LIBS=YES
> cmake --build _builds --target install
> lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: armv7 x86_64

Device + simulator multi arch:

> cmake ... -DCMAKE_IOS_INSTALL_UNIVERSAL_LIBS=YES 
-DCMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH=NO

> cmake --build _builds --target install
> lipo -info _install/lib/libfoo.a
Architectures in the fat file: _install/lib/libfoo.a are: i386 armv7 
x86_64 arm64


Let me know if this looks acceptable, then I will add documentation part 
and tests.


Thanks, Ruslo
>From 81665dad37f6b102449cd5f36b2ea0a666cf9d68 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Thu, 24 Sep 2015 11:45:44 +0300
Subject: [PATCH 1/3] Get target name for universal iOS library install

Add method GetTargetNameForUniversalIosInstall to cmInstallTargetGenerator.

This method will return target name if:
 * Platform is iOS
 * Target is library
 * CMake variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS is ON

Otherwise an empty string will be returned.
---
 Source/cmInstallTargetGenerator.cxx | 29 +
 Source/cmInstallTargetGenerator.h   |  5 +
 2 files changed, 34 insertions(+)

diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx
index 30cf175..db0ed6e 100644
--- a/Source/cmInstallTargetGenerator.cxx
+++ b/Source/cmInstallTargetGenerator.cxx
@@ -869,3 +869,32 @@ cmInstallTargetGenerator::AddRanlibRule(std::ostream& os,
   os << indent << "execute_process(COMMAND \""
  << ranlib << "\" \"" << toDestDirPath << "\")\n";
 }
+
+std::string
+cmInstallTargetGenerator
+::GetTargetNameForUniversalIosInstall(cmInstallType type) const
+{
+  if(!this->Target->Target->GetMakefile()->PlatformIsAppleIos())
+{
+return "";
+}
+
+  switch(type)
+{
+case cmInstallType_STATIC_LIBRARY:
+case cmInstallType_SHARED_LIBRARY:
+case cmInstallType_MODULE_LIBRARY:
+  break;
+default:
+  return "";
+}
+
+  const char* var = "CMAKE_IOS_INSTALL_UNIVERSAL_LIBS";
+  const char* flag = this->Target->Target->GetMakefile()->GetDefinition(var);
+  if (cmSystemTools::IsOff(flag))
+{
+return "";
+}
+
+  return this->Target->GetName();
+}
diff --git a/Source/cmInstallTargetGenerator.h b/Source/cmInstallTargetGenerator.h
index a8f4a75..6335e31 100644
--- a/Source/cmInstallTargetGenerator.h
+++ b/Source/cmInstallTargetGenerator.h
@@ -109,6 +109,11 @@ protected:
   NamelinkModeType NamelinkMode;
   bool ImportLibrary;
   bool Optional;
+
+ private:
+  /** Get target name for installing universal iOS library. If target is not
+  an iOS library or universal build is disabled return empty string. */
+  std::string GetTargetNameForUniversalIosInstall(cmInstallType type) const;
 };
 
 #endif
-- 
1.9.3 (Apple Git-50)

>From 89e8b5aebb1fd8709f3a2bcff5ac77dc3e545a07 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Thu, 24 Sep 2015 12:04:27 +0300
Subject: [PATCH 2/3] CMake module for universal iOS library install

Add CMake module with function `install_universal_ios_library`.
Target name and destination passed to the function. This function will be run
after library installed: will trigger additional build instructions for missing
platform and fuse libraries into 

Re: [CMake] "Pre-configure" step in CMake

[Tamás Kenéz]

What if you call your dependency-fetcher script with a straight
macro/function call or `include` or `execute_process` instead of putting it
into a custom target? I'm thinking of something like this:

set(DEP_SCRIPT_OUT ${CMAKE_CURRENT_BINARY_DIR}/dep-script-out.cmake)
if(NOT EXISTS "${DEP_SCRIPT_OUT}")
  execute_process(${CMAKE_COMMAND}
-DC_COMPILER_ID=${CMAKE_C_COMPILER_ID}
-DC_COMPILER_VERSION=${CMAKE_C_COMPILER_VERSION}
-DDEP_SCRIPT_OUT =${DEP_SCRIPT_OUT}
-P dependency-fetcher.cmake)
endif()
include(${DEP_SCRIPT_OUT})

or, simply:

if(NOT DEPENDENCIES_FETCHED)
  include(dependency-fetcher.cmake)
  # fetch_dependencies() # call it in case it's implemented as a
macro/function
  set(DEPENDENCIES_FETCHED ON CACHE BOOL "" FORCE)
endif()

In the latter case there's no need to write the variables into a script
since the fetcher runs in the same scope.

Tamas


On Wed, Sep 23, 2015 at 9:49 PM, Matthäus G. Chajdas 
wrote:

> Hi,
>
> I'm trying to solve the following the problem: I have a C++ application
> and a dependency fetching script. I want to simplify the initial build
> such that the following happens: On the first run of cmake, the compiler
> ID and version is passed to an external script, which fetches some
> pre-build binaries. It then writes a CMake file which contains basically
> only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir)
> commands. CMake would then read this file and subsequent find_library
> calls would pick up the values from this new CMake file. The idea is
> that "actual" build is dependent on this first dependency step, but it's
> already within the CMake framework so I can grab the compiler info and
> other build info.
>
> The obvious problem is that while I can easily run the external script
> by using configure_file, and have a custom target that does the
> dependency fetching and CMake configure file generation. But I don't see
> an easy way to get CMake to make the "rest of the project" depend on
> that configure file. How can I make such a "two-stage" build with CMake?
>
> Cheers,
>   Matthäus
> --
>
> 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
-- 

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

Re: [cmake-developers] Help with diagnosing dashboard failure

[Stephen Kelly]

Brad King wrote:

> On 09/23/2015 03:13 PM, Stephen Kelly wrote:
>> The end result of the current fix-max-path-initialization branch is the
>> same as it was then.
> 
> Okay.  I can reproduce it with the current topic (ba7f7067..16354083). 
> Within the topic it bisects to:
> 
> --
> f287bd4a94afc8064762144c405cfdee502323f8 is the first bad commit
> commit f287bd4a94afc8064762144c405cfdee502323f8
> Author: Stephen Kelly 
> Date:   Sun Sep 13 20:32:33 2015 +0200
> 
> cmGlobalGenerator: Create local generator after configuring the
> makefile.
> --
> 
> With that version I can reproduce it on 64-bit Linux with Unix Makefiles
> in a CMAKE_BUILD_TYPE=Debug build.  This corresponds to the same result
> as my earlier post.
> 
> Can you reproduce it with that version?


Yes, I can now. I realized that I was using the Ninja generator instead of 
Makefiles.

Thanks!

Steve.


-- 

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] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES

[Domen Vrankar]

2015-09-23 17:00 GMT+02:00 CHEVRIER, Marc :
> Any comments about this problem?

Sorry I've forgotten about this mail... From what you're describing it
should work. I'll take a look later today and get back to you then.

Thanks,
Domen
-- 

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] generator expression for path slash conversion

[David Cole via cmake-developers]

Unfortunately, "pushd" is an inappropriate command to use when the
argument is quoted. It works just fine with "/" characters if the
argument is quoted...

For example:

C:\Users\davidcole>pushd C:\Windows\System32

C:\Windows\System32>pushd C:/dev
The syntax of the command is incorrect.

C:\Windows\System32>pushd "C:/dev"

C:\dev>

It would be better to use a test command that **actually** fails when
a "/" path is a quoted entity


HTH,
David C.




On Thu, Sep 24, 2015 at 9:05 AM, Kislinskiy, Stefan
 wrote:
> I factored out the code from cmOutputConverter::ConvertToOutputFormat() into 
> another helper method called ConvertDirectorySeparatorsForShell(), changed 
> the SHELL_PATH genex to accept only absolute paths, and changed its 
> documentation accordingly. I also added a BadSHELL_PATH test to the 
> RunCMake/GeneratorExpression tests, that use the SHELL_PATH genex with an 
> empty parameter as well as a relative path. I also fixed the TEST/CTEST typo 
> you discovered yesterday.
>
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Mittwoch, 23. September 2015 16:57
> To: Kislinskiy, Stefan
> Cc: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] generator expression for path slash conversion
>
> On 09/23/2015 10:45 AM, Kislinskiy, Stefan wrote:
>> I see. I would suggest that I add another output flag to
>> cmOutputConverter like SHELL_NO_ESCAPE then. If this flag is passed to
>> ConvertToOutputFormat() instead of SHELL, the call of
>> EscapeForShell() will be circumvented. This way there wouldn't be code
>> duplication and we would still cover the MSYS case (drive letter
>> conversion).
>
> The conversion code in question is about 10 lines and could be factored out 
> into another helper method.  Then the genex impl could just use the helper 
> directly.
>
>> Isn't it possible to specify parameters for generator expressions?
>
> Yes.
>
>> How about something like $?
>
> Neat idea.  However, for now I'd rather not try to predict the use cases for 
> which such parameters will be needed.  Instead we should just make sure the 
> interface leaves room for future extension.  Since "," is allowed in paths we 
> cannot simply disallow it or blindly use it as a separator.  Therefore we 
> should have the actual path always be the last parameter.
>
> For now I think you can just require (with an error) that the value given to 
> SHELL_PATH as input must be an absolute path (cmSystemTools::FileIsFullPath). 
>  Then in the future we could recognize things like 
> $ without ambiguity.  Please include test cases 
> for errors on relative paths (see Tests/RunCMake/GeneratorExpression).
>
> 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
-- 

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] generator expression for path slash conversion

[Kislinskiy, Stefan]

I factored out the code from cmOutputConverter::ConvertToOutputFormat() into 
another helper method called ConvertDirectorySeparatorsForShell(), changed the 
SHELL_PATH genex to accept only absolute paths, and changed its documentation 
accordingly. I also added a BadSHELL_PATH test to the 
RunCMake/GeneratorExpression tests, that use the SHELL_PATH genex with an empty 
parameter as well as a relative path. I also fixed the TEST/CTEST typo you 
discovered yesterday.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Mittwoch, 23. September 2015 16:57
To: Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] generator expression for path slash conversion

On 09/23/2015 10:45 AM, Kislinskiy, Stefan wrote:
> I see. I would suggest that I add another output flag to 
> cmOutputConverter like SHELL_NO_ESCAPE then. If this flag is passed to 
> ConvertToOutputFormat() instead of SHELL, the call of
> EscapeForShell() will be circumvented. This way there wouldn't be code 
> duplication and we would still cover the MSYS case (drive letter 
> conversion).

The conversion code in question is about 10 lines and could be factored out 
into another helper method.  Then the genex impl could just use the helper 
directly.

> Isn't it possible to specify parameters for generator expressions?

Yes.

> How about something like $?

Neat idea.  However, for now I'd rather not try to predict the use cases for 
which such parameters will be needed.  Instead we should just make sure the 
interface leaves room for future extension.  Since "," is allowed in paths we 
cannot simply disallow it or blindly use it as a separator.  Therefore we 
should have the actual path always be the last parameter.

For now I think you can just require (with an error) that the value given to 
SHELL_PATH as input must be an absolute path (cmSystemTools::FileIsFullPath).  
Then in the future we could recognize things like $ 
without ambiguity.  Please include test cases for errors on relative paths (see 
Tests/RunCMake/GeneratorExpression).

Thanks,
-Brad



shell_path_genex_v4.patch
Description: shell_path_genex_v4.patch
-- 

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-commits] CMake branch, next, updated. v3.3.2-3235-gd6b6e47

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  d6b6e47b1df0f6e8d1201be99ce9f8e5b28c9a04 (commit)
   via  bd189cc24e2292ab80dde7c0d0ac1cd9fafb2d35 (commit)
  from  43218affaaa2acd87e1b9e91f7de6947cc694e4d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d6b6e47b1df0f6e8d1201be99ce9f8e5b28c9a04
commit d6b6e47b1df0f6e8d1201be99ce9f8e5b28c9a04
Merge: 43218af bd189cc
Author: Brad King 
AuthorDate: Thu Sep 24 09:14:04 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Sep 24 09:14:04 2015 -0400

Merge topic 'install-directory-dest-genex' into next

bd189cc2 install: Allow generator expressions in DIRECTORY DESTINATION


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd189cc24e2292ab80dde7c0d0ac1cd9fafb2d35
commit bd189cc24e2292ab80dde7c0d0ac1cd9fafb2d35
Author: Robert Goulet 
AuthorDate: Wed Sep 23 17:15:29 2015 -0400
Commit: Brad King 
CommitDate: Thu Sep 24 09:13:03 2015 -0400

install: Allow generator expressions in DIRECTORY DESTINATION

diff --git a/Help/command/install.rst b/Help/command/install.rst
index 9c17bba..423899e 100644
--- a/Help/command/install.rst
+++ b/Help/command/install.rst
@@ -271,6 +271,10 @@ will install the ``icons`` directory to 
``share/myproj/icons`` and the
 file permissions, the scripts will be given specific permissions, and any
 ``CVS`` directories will be excluded.
 
+The install destination given to the directory install ``DESTINATION`` may
+use "generator expressions" with the syntax ``$<...>``.  See the
+:manual:`cmake-generator-expressions(7)` manual for available expressions.
+
 Custom Installation Logic
 ^
 
diff --git a/Help/release/dev/install-directory-dest-genex.rst 
b/Help/release/dev/install-directory-dest-genex.rst
new file mode 100644
index 000..2b83bbd
--- /dev/null
+++ b/Help/release/dev/install-directory-dest-genex.rst
@@ -0,0 +1,5 @@
+install-directory-dest-genex
+
+
+* The :command:`install(DIRECTORY)` command ``DESTINATION`` option learned to
+  support :manual:`generator expressions `.
diff --git a/Source/cmInstallDirectoryGenerator.cxx 
b/Source/cmInstallDirectoryGenerator.cxx
index 7593380..78cb5f0 100644
--- a/Source/cmInstallDirectoryGenerator.cxx
+++ b/Source/cmInstallDirectoryGenerator.cxx
@@ -12,6 +12,8 @@
 #include "cmInstallDirectoryGenerator.h"
 
 #include "cmTarget.h"
+#include "cmGeneratorExpression.h"
+#include "cmLocalGenerator.h"
 
 //
 cmInstallDirectoryGenerator
@@ -25,10 +27,16 @@ cmInstallDirectoryGenerator
   const char* literal_args,
   bool optional):
   cmInstallGenerator(dest, configurations, component, message),
+  LocalGenerator(0),
   Directories(dirs),
   FilePermissions(file_permissions), DirPermissions(dir_permissions),
   LiteralArguments(literal_args), Optional(optional)
 {
+  // We need per-config actions if destination have generator expressions.
+  if(cmGeneratorExpression::Find(Destination) != std::string::npos)
+{
+this->ActionsPerConfig = true;
+}
 }
 
 //
@@ -37,15 +45,43 @@ cmInstallDirectoryGenerator
 {
 }
 
+void cmInstallDirectoryGenerator::Compute(cmLocalGenerator* lg)
+{
+  LocalGenerator = lg;
+}
+
 //
 void
 cmInstallDirectoryGenerator::GenerateScriptActions(std::ostream& os,
Indent const& indent)
 {
+  if(this->ActionsPerConfig)
+{
+this->cmInstallGenerator::GenerateScriptActions(os, indent);
+}
+  else
+{
+this->AddDirectoryInstallRule(os, "", indent);
+}
+}
+
+void cmInstallDirectoryGenerator::GenerateScriptForConfig(
+  std::ostream& os,
+  const std::string& config,
+  Indent const& indent)
+{
+  this->AddDirectoryInstallRule(os, config, indent);
+}
+
+void cmInstallDirectoryGenerator::AddDirectoryInstallRule(
+  std::ostream& os,
+  const std::string& config,
+  Indent const& indent)
+{
   // Write code to install the directories.
   const char* no_rename = 0;
   this->AddInstallRule(os,
-   this->Destination,
+   this->GetDestination(config),
cmInstallType_DIRECTORY,
this->Directories,
this->Optional,
@@ 

[Cmake-commits] CMake branch, next, updated. v3.3.2-3241-gcad1b3e

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  cad1b3eca50f296a8eacf3252c9eae8bdb606d9b (commit)
   via  2e6063068c94d4045e699fed51e6d1e9af344bbf (commit)
   via  81739e9215ef10d870f14404b0ec5eb4bee16ce4 (commit)
  from  a0717a6812ae7c599267d57f6ba37ee6937a715c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cad1b3eca50f296a8eacf3252c9eae8bdb606d9b
commit cad1b3eca50f296a8eacf3252c9eae8bdb606d9b
Merge: a0717a6 2e60630
Author: Brad King 
AuthorDate: Thu Sep 24 10:22:31 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Sep 24 10:22:31 2015 -0400

Merge topic 'revert-cmake-W-options' into next

2e606306 Merge branch 'improve-variable-help-formatting' into 
revert-cmake-W-options
81739e92 Revert topic 'cmake-W-options' (#15747)

diff --cc Source/cmake.h
index 8ac8897,20e49e3..9d28cba
--- a/Source/cmake.h
+++ b/Source/cmake.h
@@@ -339,9 -338,11 +337,10 @@@ protected
void AddExtraGenerator(const std::string& name,
   CreateExtraGeneratorFunctionType newFunction);
  
 -  cmPolicies *Policies;
cmGlobalGenerator *GlobalGenerator;
cmCacheManager *CacheManager;
-   std::map WarningLevels;
+   bool SuppressDevWarnings;
+   bool DoSuppressDevWarnings;
std::string GeneratorPlatform;
std::string GeneratorToolset;
  

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e6063068c94d4045e699fed51e6d1e9af344bbf
commit 2e6063068c94d4045e699fed51e6d1e9af344bbf
Merge: 81739e9 3bb707f
Author: Brad King 
AuthorDate: Tue Sep 22 13:57:08 2015 -0400
Commit: Brad King 
CommitDate: Tue Sep 22 13:57:08 2015 -0400

Merge branch 'improve-variable-help-formatting' into revert-cmake-W-options

Resolve conflicts in

 Help/variable/CMAKE_ERROR_DEPRECATED.rst
 Help/variable/CMAKE_WARN_DEPRECATED.rst

by integrating changes from both sides.

diff --cc Help/variable/CMAKE_ERROR_DEPRECATED.rst
index 43ab282,39dc4a8..277a4cc
--- a/Help/variable/CMAKE_ERROR_DEPRECATED.rst
+++ b/Help/variable/CMAKE_ERROR_DEPRECATED.rst
@@@ -3,6 -3,10 +3,6 @@@ CMAKE_ERROR_DEPRECATE
  
  Whether to issue deprecation errors for macros and functions.
  
- If TRUE, this can be used by macros and functions to issue fatal
+ If ``TRUE``, this can be used by macros and functions to issue fatal
  errors when deprecated macros or functions are used.  This variable is
- FALSE by default.
+ ``FALSE`` by default.
 -
 -These errors can be enabled with the ``-Werror=deprecated`` option, or
 -disabled with the ``-Wno-error=deprecated`` option, when running
 -:manual:`cmake(1)`.
diff --cc Help/variable/CMAKE_WARN_DEPRECATED.rst
index 7b2510b,7b8533c..662cbd8
--- a/Help/variable/CMAKE_WARN_DEPRECATED.rst
+++ b/Help/variable/CMAKE_WARN_DEPRECATED.rst
@@@ -3,5 -3,9 +3,5 @@@ CMAKE_WARN_DEPRECATE
  
  Whether to issue deprecation warnings for macros and functions.
  
- If TRUE, this can be used by macros and functions to issue deprecation
- warnings.  This variable is FALSE by default.
+ If ``TRUE``, this can be used by macros and functions to issue deprecation
+ warnings.  This variable is ``FALSE`` by default.
 -
 -These warnings can be enabled with the ``-Wdeprecated`` option, or
 -disabled with the ``-Wno-deprecated`` option, when running
 -:manual:`cmake(1)`.

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=81739e9215ef10d870f14404b0ec5eb4bee16ce4
commit 81739e9215ef10d870f14404b0ec5eb4bee16ce4
Author: Brad King 
AuthorDate: Tue Sep 22 13:51:40 2015 -0400
Commit: Brad King 
CommitDate: Tue Sep 22 13:53:09 2015 -0400

Revert topic 'cmake-W-options' (#15747)

The changes in commit c96fe0b4 (cmake: Add -W options to control
deprecation warnings and errors, 2015-07-28) fail to account for
-Wdev warnings produced by places in CMake other than message().
This causes a regression in which -Wno-dev fails to suppress such
warnings.  Revert the feature until it can be revised accordingly.

diff --git a/Help/manual/OPTIONS_BUILD.txt b/Help/manual/OPTIONS_BUILD.txt
index b65b7c7..4207db4 100644
--- a/Help/manual/OPTIONS_BUILD.txt
+++ b/Help/manual/OPTIONS_BUILD.txt
@@ -77,49 +77,10 @@
  Suppress developer warnings.
 
  Suppress warnings that are meant for the author of the
- CMakeLists.txt files. By default this will also turn off
- deprecation warnings.
+ CMakeLists.txt files.
 
 ``-Wdev``
  Enable developer warnings.
 
  Enable warnings that are meant for the author of 

Re: [cmake-developers] Add command line options for deprecation message control

[Brad King]

On 09/22/2015 08:53 AM, Brad King wrote:
> In this case we have a bug in a new feature that was
> introduced in post-3.3 development so we need to either fix it or
> remove the offending parts of the new features before Oct 1 for 3.4.

In preparation for the 3.4 freeze I've added a topic to revert
the entire change:

 Revert topic 'cmake-W-options' (#15747)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=81739e92

Currently it is in 'next' for testing.  I will merge to 'master'
before 3.4 if the regression cannot otherwise be fixed by then.

-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] Build log generation in a "custom" way

[Bill Hoffman]

On 9/24/2015 7:47 AM, Attila Krasznahorkay wrote:

Dear All,

I'd like to ask for some advice about the following issue. We're
migrating a very big project (millions of lines of code...) from a
custom build manager to CMake.

The software is put together from separate "packages" that are all
developed by a different set of people. Our nightly build system
collects all these packages, and compiles all of them. In our old
build system we could easily save package-specific build log files
for the nightly system. Making it easy for the developers to quickly
find build problems in their specific package.

Now we'd like to do something similar with CMake. To teach it how to
generate separate build log files for the separate packages.
(Packages in this context are really just subdirectories in the end.)
The clumsy thing that we're doing now is to use a script that we set
for RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM.
This script writes log files in a non-too-perfect way, which need to
be stitched together at the end of the build to get "package
specific" build log files.

So the question is whether we could do something better. Does anyone
have an idea/suggestion? I'm happy to give more information about our
setup if needed.



You might want to look into CDash (www.cdash.org).

http://www.kitware.com/media/html/CDashSubprojects.html

Here is an example in the Trilinos project:
http://testing.sandia.gov/cdash/index.php?project=Trilinos=2015-09-23

-Bill

--

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

[Cmake-commits] CMake branch, next, updated. v3.3.2-3238-ga0717a6

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  a0717a6812ae7c599267d57f6ba37ee6937a715c (commit)
   via  8adf6ab5be58d130dc294a897b23f113dfc08220 (commit)
   via  7de868c4d7c8bfe35d201ed480328f3177a1325b (commit)
  from  d6b6e47b1df0f6e8d1201be99ce9f8e5b28c9a04 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a0717a6812ae7c599267d57f6ba37ee6937a715c
commit a0717a6812ae7c599267d57f6ba37ee6937a715c
Merge: d6b6e47 8adf6ab
Author: Brad King 
AuthorDate: Thu Sep 24 10:17:16 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Sep 24 10:17:16 2015 -0400

Merge topic 'genex-SHELL_PATH' into next

8adf6ab5 Genex: Add a SHELL_PATH expression
7de868c4 Tests: Simplify GeneratorExpression check implementation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8adf6ab5be58d130dc294a897b23f113dfc08220
commit 8adf6ab5be58d130dc294a897b23f113dfc08220
Author: Stefan Kislinskiy 
AuthorDate: Thu Sep 24 12:33:01 2015 +0200
Commit: Brad King 
CommitDate: Thu Sep 24 09:50:23 2015 -0400

Genex: Add a SHELL_PATH expression

Some commands on Windows do not understand forward slash paths and
require backslashes.  In order to help projects generate shell
invocations of such commands, provide a generator expression to convert
paths to the shell-preferred path format for the current generator.
This will allow custom commands to generate paths the same way CMake
does for compiler command invocations.

diff --git a/Help/manual/cmake-generator-expressions.7.rst 
b/Help/manual/cmake-generator-expressions.7.rst
index 189c3ef..13ee4bd 100644
--- a/Help/manual/cmake-generator-expressions.7.rst
+++ b/Help/manual/cmake-generator-expressions.7.rst
@@ -278,3 +278,7 @@ Available output expressions are:
   object of type ``OBJECT_LIBRARY``.  This expression may only be used in
   the sources of :command:`add_library` and :command:`add_executable`
   commands.
+``$``
+  Content of ``...`` converted to shell path style. For example, slashes are
+  converted to backslashes in Windows shells and drive letters are converted
+  to posix paths in MSYS shells. The ``...`` must be an absolute path.
diff --git a/Help/release/dev/genex-SHELL_PATH.rst 
b/Help/release/dev/genex-SHELL_PATH.rst
new file mode 100644
index 000..86af720
--- /dev/null
+++ b/Help/release/dev/genex-SHELL_PATH.rst
@@ -0,0 +1,6 @@
+genex-SHELL_PATH
+
+
+* A new ``$``
+  :manual:`generator expression `
+  has been added.
diff --git a/Source/cmGeneratorExpressionNode.cxx 
b/Source/cmGeneratorExpressionNode.cxx
index 31b6766..1c350ab 100644
--- a/Source/cmGeneratorExpressionNode.cxx
+++ b/Source/cmGeneratorExpressionNode.cxx
@@ -13,6 +13,7 @@
 #include "cmGeneratorExpressionNode.h"
 #include "cmGlobalGenerator.h"
 #include "cmAlgorithms.h"
+#include "cmOutputConverter.h"
 
 //
 std::string cmGeneratorExpressionNode::EvaluateDependentExpression(
@@ -1792,6 +1793,27 @@ static const
 TargetFilesystemArtifactNodeGroup targetPdbNodeGroup;
 
 //
+static const struct ShellPathNode : public cmGeneratorExpressionNode
+{
+  ShellPathNode() {}
+
+  std::string Evaluate(const std::vector ,
+   cmGeneratorExpressionContext *context,
+   const GeneratorExpressionContent *content,
+   cmGeneratorExpressionDAGChecker *) const
+  {
+if (!cmSystemTools::FileIsFullPath(parameters.front()))
+  {
+  reportError(context, content->GetOriginalExpression(),
+  "\"" + parameters.front() + "\" is not an absolute path.");
+  return std::string();
+  }
+cmOutputConverter converter(context->Makefile->GetStateSnapshot());
+return converter.ConvertDirectorySeparatorsForShell(parameters.front());
+  }
+} shellPathNode;
+
+//
 const cmGeneratorExpressionNode*
 cmGeneratorExpressionNode::GetNode(const std::string )
 {
@@ -1846,6 +1868,7 @@ cmGeneratorExpressionNode::GetNode(const std::string 
)
 nodeMap["JOIN"] = 
 nodeMap["LINK_ONLY"] = 
 nodeMap["COMPILE_LANGUAGE"] = 
+nodeMap["SHELL_PATH"] = 
 }
   NodeMap::const_iterator i = nodeMap.find(identifier);
   if (i == nodeMap.end())
diff --git a/Source/cmOutputConverter.cxx 

Re: [cmake-developers] generator expression for path slash conversion

[Kislinskiy, Stefan]

Great, thank you, Brad & David.

Regarding the ExternalProjectShellPathGenex test: I wrongly assumed that the 
WIN32 variable wouldn't be set when using MSYS and the like. Would it make 
sense to keep the test when changing the WIN32 check to MSVC? Good to know that 
pushd is working for quoted paths. As I didn't use paths with spaces, the 
argument wasn't quoted and the test worked like expected for me (succeeded with 
the SHELL_PATH genex and failed when I removed the SHELL_PATH genex). We could 
ensure that there isn't any space character in the argument by using a 
top-level path like C:/. Not hard coded but derived from a variable like 
CMAKE_SOURCE_DIR. Or, of course, there is a standard Windows command out there 
that cannot handle slashed even if they are quoted (any idea?). I chose pushd, 
as that was the command that started it all (used indirectly by the Boost build 
scripts).

Regarding the nice bracket tweak: Maybe the minimum required version in 
Tests/GeneratorExpression/CMakeLists.txt should be updated to 3.0.0 then?

Stefan

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Donnerstag, 24. September 2015 16:22
To: Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] generator expression for path slash conversion

On 09/24/2015 09:05 AM, Kislinskiy, Stefan wrote:
> I factored out the code from 
> cmOutputConverter::ConvertToOutputFormat()
> into another helper method called 
> ConvertDirectorySeparatorsForShell(),
> changed the SHELL_PATH genex to accept only absolute paths, and 
> changed its documentation accordingly. I also added a BadSHELL_PATH 
> test to the RunCMake/GeneratorExpression tests, that use the 
> SHELL_PATH genex with an empty parameter as well as a relative path. I 
> also fixed the TEST/CTEST typo you discovered yesterday.

Thanks.  I started with a change to simplify the test infrastructure slightly:

 Tests: Simplify GeneratorExpression check implementation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7de868c4

Then I applied your changes with minor tweaks and merged to 'next'
for testing:

 Genex: Add a SHELL_PATH expression
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8adf6ab5

I left out the ExternalProjectShellPathGenex test because it fails on the 
Ninja, MSYS Makefiles, and MinGW Makefiles generators on Windows.  The 'pushd' 
and 'popd' commands do not work there due to the way the build tool runs the 
command in a shell.  It passed for me only in a VS IDE generator.  See also 
David Cole's sibling response about this test.

-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] Generator expressions for install destination

[Brad King]

On 09/23/2015 05:18 PM, Robert Goulet wrote:
> Here is the patch to support genex for install(DIRECTORY) command
> DESTINATION option.

Thanks.  Applied with minor tweaks:

 install: Allow generator expressions in DIRECTORY DESTINATION
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd189cc2

-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] generator expression for path slash conversion

[Brad King]

On 09/24/2015 09:05 AM, Kislinskiy, Stefan wrote:
> I factored out the code from cmOutputConverter::ConvertToOutputFormat()
> into another helper method called ConvertDirectorySeparatorsForShell(),
> changed the SHELL_PATH genex to accept only absolute paths, and changed
> its documentation accordingly. I also added a BadSHELL_PATH test to the
> RunCMake/GeneratorExpression tests, that use the SHELL_PATH genex with
> an empty parameter as well as a relative path. I also fixed the
> TEST/CTEST typo you discovered yesterday.

Thanks.  I started with a change to simplify the test infrastructure slightly:

 Tests: Simplify GeneratorExpression check implementation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7de868c4

Then I applied your changes with minor tweaks and merged to 'next'
for testing:

 Genex: Add a SHELL_PATH expression
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8adf6ab5

I left out the ExternalProjectShellPathGenex test because it fails
on the Ninja, MSYS Makefiles, and MinGW Makefiles generators on
Windows.  The 'pushd' and 'popd' commands do not work there due to
the way the build tool runs the command in a shell.  It passed for
me only in a VS IDE generator.  See also David Cole's sibling
response about this test.

-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

[CMake] CPack picks up AppleDouble files when running in OS X

[Segev BenZvi]

Hi all,

I've run into an annoying issue making package sources with CPack in OS X
(Mavericks and Yosemite).

I set up CPack to produce a tarball of my source tree with bzip, but in OS
X tar will pick up the AppleDouble files in the source folder and stuff
them into the archive too. As a result my tarball is full of duplicate
source files (i.e., source.cc and its double ._source.cc), which causes
problems when building the source later.

This is **not** the fault of CPack; it is a known issue with tar in OS X.
The way to suppress the AppleDouble files when running tar on the command
line is to set the environment variable COPYFILE_DISABLE=1, e.g.,

$> COPYFILE_DISABLE=1 tar cjf package.tbz2 /path/to/src

This works just fine for me. Unfortunately, even if I have COPYFILE_DISABLE
set in my environment, CPack doesn't seem to pick it up when calling tar.
As a result the AppleDouble files keep showing up in my archive when I call
"make package_source." While it's not a blocker for me -- I can produce the
source package on a Linux box -- I do most of my development on my MacBook
so this is pretty annoying.

I tried some other tricks, like including the line

SET (CPACK_SOURCE_IGNORE_FILES "[.]_.*;")

in my top-level CMakeLists.txt, but that doesn't help.

I looked through the cmake email archives but couldn't find anyone else who
has raised this issue... so either I've missed the right emails or there is
an obvious fix I'm overlooking. Any ideas what I'm doing wrong?

Thanks for your attention!

Best regards,
Segev BenZvi
-- 

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

[Cmake-commits] CMake branch, master, updated. v3.3.2-1272-gcbfae8c

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  cbfae8c3f2c971441d4943a630efe7b186ee0c44 (commit)
   via  69ab5f55026c7e884a70f04aa7ddef776f74305b (commit)
   via  17aa6fd36284ad937bfce370cf8d5e5de87a334b (commit)
  from  02ccef2ae586ce342cb76eaec61db0e2132081a4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cbfae8c3f2c971441d4943a630efe7b186ee0c44
commit cbfae8c3f2c971441d4943a630efe7b186ee0c44
Merge: 02ccef2 69ab5f5
Author: Brad King 
AuthorDate: Thu Sep 24 10:28:54 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Sep 24 10:28:54 2015 -0400

Merge topic 'install-files-dest-genex'

69ab5f55 Tests: Cover install(FILES) with a genex DESTINATION
17aa6fd3 install: Allow generator expressions in FILES DESTINATION


---

Summary of changes:
 Help/command/install.rst   |4 
 Help/release/dev/install-files-dest-genex.rst  |5 
 Source/cmInstallFilesGenerator.cxx |   25 
 Source/cmInstallFilesGenerator.h   |6 -
 Tests/ExportImport/Export/CMakeLists.txt   |4 ++--
 .../FILES-DESTINATION-bad-result.txt}  |0
 .../FILES-DESTINATION-bad-stderr.txt}  |0
 Tests/RunCMake/install/FILES-DESTINATION-bad.cmake |1 +
 Tests/RunCMake/install/RunCMakeTest.cmake  |1 +
 Tests/SimpleInstall/CMakeLists.txt |4 ++--
 Tests/SimpleInstallS2/CMakeLists.txt   |4 ++--
 11 files changed, 43 insertions(+), 11 deletions(-)
 create mode 100644 Help/release/dev/install-files-dest-genex.rst
 copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt => 
install/FILES-DESTINATION-bad-result.txt} (100%)
 copy Tests/RunCMake/{XcodeProject/XcodeAttributeGenexError-stderr.txt => 
install/FILES-DESTINATION-bad-stderr.txt} (100%)
 create mode 100644 Tests/RunCMake/install/FILES-DESTINATION-bad.cmake


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.3.2-3244-ge165b12

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  e165b1250c78a907fd1162aa68f334a96ddceb93 (commit)
   via  cbfae8c3f2c971441d4943a630efe7b186ee0c44 (commit)
   via  02ccef2ae586ce342cb76eaec61db0e2132081a4 (commit)
  from  cad1b3eca50f296a8eacf3252c9eae8bdb606d9b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e165b1250c78a907fd1162aa68f334a96ddceb93
commit e165b1250c78a907fd1162aa68f334a96ddceb93
Merge: cad1b3e cbfae8c
Author: Brad King 
AuthorDate: Thu Sep 24 10:29:02 2015 -0400
Commit: Brad King 
CommitDate: Thu Sep 24 10:29:02 2015 -0400

Merge branch 'master' into next


---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [cmake-developers] generator expression for path slash conversion

[James Johnston]

> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Kislinskiy, Stefan
> Sent: Thursday, September 24, 2015 15:09
> To: Brad King
> Cc: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] generator expression for path slash
> conversion
> 
> Great, thank you, Brad & David.
> 
> Regarding the ExternalProjectShellPathGenex test: I wrongly assumed that
> the WIN32 variable wouldn't be set when using MSYS and the like. Would it
> make sense to keep the test when changing the WIN32 check to MSVC?

Just an FYI:  MSVC can still be set; it's an indicator of the *compiler* in
use, not the *generator*.  For example, it could be set if using cl.exe with
Ninja.

Best regards,

James Johnston

-- 

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-commits] CMake branch, next, updated. v3.3.2-3246-g527deef

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  527deefa0a4bede3d45edd867afe2a1a5eb8a7bd (commit)
   via  710bde43aa5ed1ccfbcffa01d3d86a4eecbbe849 (commit)
  from  e165b1250c78a907fd1162aa68f334a96ddceb93 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=527deefa0a4bede3d45edd867afe2a1a5eb8a7bd
commit 527deefa0a4bede3d45edd867afe2a1a5eb8a7bd
Merge: e165b12 710bde4
Author: Brad King 
AuthorDate: Thu Sep 24 15:30:16 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Sep 24 15:30:16 2015 -0400

Merge topic 'fix-try_compile-internal-argv' into next

710bde43 cmCoreTryCompile: Fix internal argument vector construction


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=710bde43aa5ed1ccfbcffa01d3d86a4eecbbe849
commit 710bde43aa5ed1ccfbcffa01d3d86a4eecbbe849
Author: Brad King 
AuthorDate: Thu Sep 24 15:21:32 2015 -0400
Commit: Brad King 
CommitDate: Thu Sep 24 15:26:32 2015 -0400

cmCoreTryCompile: Fix internal argument vector construction

In TryCompileCode we construct an internal argv[] vector that needs to
have a fake argv[0] so our internal cmake command line looks like a real
command line.  Fix construction of the fake argv[0] when try_compile is
called without the CMAKE_FLAGS argument.  Otherwise the first internal
-DVAR=val argument that we use to pass information like
CMAKE_OSX_SYSROOT is ignored.

diff --git a/Source/cmCoreTryCompile.cxx b/Source/cmCoreTryCompile.cxx
index e489ad2..3d9c4bf 100644
--- a/Source/cmCoreTryCompile.cxx
+++ b/Source/cmCoreTryCompile.cxx
@@ -29,7 +29,7 @@ int cmCoreTryCompile::TryCompileCode(std::vector 
const& argv)
   const char* sourceDirectory = argv[2].c_str();
   const char* projectName = 0;
   std::string targetName;
-  std::vector cmakeFlags;
+  std::vector cmakeFlags(1, "CMAKE_FLAGS"); // fake argv[0]
   std::vector compileDefs;
   std::string outputVariable;
   std::string copyFile;
@@ -53,10 +53,6 @@ int 
cmCoreTryCompile::TryCompileCode(std::vector const& argv)
 if(argv[i] == "CMAKE_FLAGS")
   {
   doing = DoingCMakeFlags;
-  // CMAKE_FLAGS is the first argument because we need an argv[0] that
-  // is not used, so it matches regular command line parsing which has
-  // the program name as arg 0
-  cmakeFlags.push_back(argv[i]);
   }
 else if(argv[i] == "COMPILE_DEFINITIONS")
   {

---

Summary of changes:
 Source/cmCoreTryCompile.cxx |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] "Pre-configure" step in CMake

[Bill Hoffman]

On 9/24/2015 4:26 PM, Matthäus G. Chajdas wrote:

Hi,

that sounds like it would do the trick. I wasn't aware that
execute_process will block the script until it's done executing. Need to
check this out but that definitely looks like the way to go, thanks!
ExternalProject might be a better option.  It pushes the downloads to 
build time and handles dependencies without having to re-run CMake.  If 
you run a download script at CMake time, it could take an unknown amount 
of time to configure.


-Bill


--

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

Re: [cmake-developers] [Patch] Adding Windows 10 support

[Brad King]

On 09/23/2015 06:48 PM, Gilles Khouzam wrote:
> This adds only the WINDOWS_TARGET_PLATFORM_VERSION property as it
> currently only supports the desktop scenario and is extracted
> from the rest of the Windows 10 Store support.

Thanks.  While reviewing this much simpler patch I realized that
the WindowsTargetPlatformVersion is more like PlatformToolset than
I previously thought.  This led me to another design, perhaps closer
to one of your earlier patches, in which the VS 2015+ generators
select the WindowsTargetPlatformVersion up front based either on
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION or on a computed default.
Either way we should set CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
to report the selection to CMakeDetermineCompilerId for use in
"CompilerId/VS-10.vcxproj.in".  For now I decided to leave out
support for per-target WINDOWS_TARGET_PLATFORM_VERSION properties.

While testing these changes I found a bug that I've now fixed:

 cmCoreTryCompile: Fix internal argument vector construction
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=710bde43

Please try out the attached patches based on that version.  Then
provide fixup patches based on the comments below if needed.

> If CMAKE_SYSTEM_VERSION is set to 10.0 then

After your change to add a third component to CMAKE_HOST_SYSTEM_VERSION
the value of CMAKE_SYSTEM_VERSION on a Windows 10 host may have
a third component.  Therefore we should check that the version
starts with "10.0" rather than is exactly this version.  Actually
perhaps we should use cmSystemTools::VersionCompare to do actual
integer version component checks.

> the latest Windows 10 SDK but not more recent than the current
> build of Windows.

Rather than using VerifyVersionInfo for this, shouldn't the check
simply compare the SDK version to the targeted CMAKE_SYSTEM_VERSION?
If we are cross-compiling or otherwise specifying a specific target
version of Windows then we do not want the SDK to exceed that
regardless of what the host is running.

Also, the sorting logic in GetWindows10SDKVersion appears to use
lexicographic string ordering rather than a component-wise integer
comparison.  This will not always produce the correct result.  This
is another candidate for using cmSystemTools::VersionCompare.

> There is one thing that I've changed that I want to make sure is
> the right thing. As it stands, CMAKE_SYSTEM_VERSION is only valid
> when cross-compiling, I've changed the CMakeDetermineSystem.cmake
> file to not use the HOST_SYSTEM_VERSION when CMAKE_SYSTEM_VERSION
> is set. Otherwise, we can only use this feature through
> CMAKE_SYSTEM_VERSION on cross-compiling scenarios.

That makes sense.  I've split that out into its own commit and
explained the motivation in the commit message.  See attached
patch.

> I'm not sure what the best way to test this feature, it can be
> added to any desktop project on Windows 10 and it should work
> properly. I've tried it with CMake itself and it's working fine
> and building against the Win10 SDK.

We could have the test suite detect when it is building on a
Windows 10 host and then add a test that sets
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and verifies that the
value ends up in a generated project file.  We already have
some tests that parse the generated .sln file to check for
specific content.

Also just simply by running on a Win 10 host then the entire test
suite should build with CMAKE_SYSTEM_VERSION set automatically high
enough to enable default SDK selection.  Please look at setting up
nightly testing submissions to the dashboard from such a host once
the changes are integrated.

Thanks,
-Brad
>From 267153a2ed1417fe16e679d21d34927802e31e2c Mon Sep 17 00:00:00 2001
Message-Id: <267153a2ed1417fe16e679d21d34927802e31e2c.1443126273.git.brad.k...@kitware.com>
From: Gilles Khouzam 
Date: Wed, 23 Sep 2015 14:27:07 -0700
Subject: [PATCH 1/3] Allow CMAKE_SYSTEM_VERSION to be set without
 CMAKE_SYSTEM_NAME

Teach CMakeDetermineSystem to check for a CMAKE_SYSTEM_VERSION setting
even when CMAKE_SYSTEM_NAME is not set.  This will allow builds on the
host OS to target other versions of the OS without full cross-compiling.
---
 Modules/CMakeDetermineSystem.cmake | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Modules/CMakeDetermineSystem.cmake b/Modules/CMakeDetermineSystem.cmake
index fa14641..d9f7579 100644
--- a/Modules/CMakeDetermineSystem.cmake
+++ b/Modules/CMakeDetermineSystem.cmake
@@ -123,7 +123,9 @@ elseif(CMAKE_VS_WINCE_VERSION)
   set(PRESET_CMAKE_SYSTEM_NAME TRUE)
 else()
   set(CMAKE_SYSTEM_NAME  "${CMAKE_HOST_SYSTEM_NAME}")
-  set(CMAKE_SYSTEM_VERSION   "${CMAKE_HOST_SYSTEM_VERSION}")
+  if(NOT DEFINED CMAKE_SYSTEM_VERSION)
+set(CMAKE_SYSTEM_VERSION "${CMAKE_HOST_SYSTEM_VERSION}")
+  endif()
   set(CMAKE_SYSTEM_PROCESSOR "${CMAKE_HOST_SYSTEM_PROCESSOR}")
   set(CMAKE_CROSSCOMPILING FALSE)
   set(PRESET_CMAKE_SYSTEM_NAME FALSE)
-- 
2.5.1

>From 

[CMake] Adding files to ARCHIVE packages only in CPack

[Bruno Barberi Gnecco]

	How is it possible to add some files only to the ARCHIVE generators with CMake/CPack? 
Apparently components do that, but I can't figure how to say "only add component X to 
generator Y". I did something like this:


In CPackConfig.cmake:

set(CPACK_PROJECT_CONFIG_FILE 
"${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/CMakeCPackOptions.cmake")


In CMakeCPackOptions.cmake

IF (CPACK_GENERATOR MATCHES "TGZ")
install(FILES myextrafile DESTINATION "." COMPONENT static)
ENDIF()

But I get the following error:

/usr/local/bin/cpack --config ./CPackConfig.cmake
CMake Error at CMakeModules/CMakeCPackOptions.cmake:4 (install):
  Unknown CMake command "install".

CPack Error: Cannot initialize the generator TGZ

What am I doing wrong? Any other way to run `install()` only for 
certain generators? Thanks
--

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

Re: [CMake] "Pre-configure" step in CMake

[Bill Hoffman]

On 9/24/2015 5:02 PM, Matthäus G. Chajdas wrote:

Hi,

how does the ExternalProject interact with subsequent find_library calls?

I've seen projects building dependencies through ExternalProject, but
those would the project manually by querying ExternalProject and adding
a new imported target. How would I connect an ExternalProject to one or
more find_library calls?

So, the trick is it all has to be ExternalProject including your 
project.  Then the find_library stuff will work.


EP_add(3rdpartylib)
EP_add(myproj)

# at build time of myproj all of 3rdparytlib will be done and 
discoverable by myproj find_* calls.We often have project-bootstrap 
projects that use external project to configure an environment.


1. build project-bootstrap (all external project stuff)
2. cd myproject, and treat this like a standalone CMake project that has 
just discovered all of its depends on the system.



Is there a downside from configure taking an unknown amount of time? My
expectation was that there is no timeout for the configure step.
It is meant to be an interactive step with cmake-gui.  Also, if there 
are configuration errors you would want to see them up front and not 
after a wait.


-Bill

--

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

Re: [cmake-developers] Generator expressions for install destination

[Robert Goulet]

Thanks Brad!

Sent from mobile, please excuse typos.

> On Sep 24, 2015, at 10:24 AM, Brad King  wrote:
> 
>> On 09/23/2015 05:18 PM, Robert Goulet wrote:
>> Here is the patch to support genex for install(DIRECTORY) command
>> DESTINATION option.
> 
> Thanks.  Applied with minor tweaks:
> 
> install: Allow generator expressions in DIRECTORY DESTINATION
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd189cc2
> 
> -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] Add command line options for deprecation message control

[Michael Scott]

I've created a fix for the issue of -Wno-dev and -Wno-deprecated options 
not being honoured, and extended the tests to cover this additional 
scenario.


However I'm having an issue with determining if variables are set in 
cmake.cxx. The initial fix checked for the variables using the 
"GetCacheEntryValue" method in cmState, but I found that this didn't 
work when the variable (say CMAKE_WARN_DEPRECATED) was set in a .cmake 
file, as is the case for the "RunCMake/message/warnmessage.cmake". I 
toyed around with trying to get a hold of a cmMakefile instance and 
check the state of the variable via that, by getting the first object of 
the global generator makefiles, but this didn't always seem to work. 
Would you be able to advise on what the correct way is to get the 
current value of a variable, in the cmake class? I feel like I'm missing 
something simple here, as I'm still not too familiar with the code.


Cheers,
Michael
--

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-commits] CMake branch, master, updated. v3.3.2-1273-g7c0b22a

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  7c0b22a84e59c17e588da451ced454c6bc4232c2 (commit)
  from  cbfae8c3f2c971441d4943a630efe7b186ee0c44 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7c0b22a84e59c17e588da451ced454c6bc4232c2
commit 7c0b22a84e59c17e588da451ced454c6bc4232c2
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Sep 25 00:01:06 2015 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Sep 25 00:01:06 2015 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 48573d8..b042c4a 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 3)
-set(CMake_VERSION_PATCH 20150924)
+set(CMake_VERSION_PATCH 20150925)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.3.2-3251-g0fe79c0

[Domen Vrankar]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  0fe79c067090dd880826e5334a30af955e15c5e2 (commit)
   via  98c72cdeccb98017e39438af8186811c8f998197 (commit)
   via  901dd53403db10b5c88be8c9ccd9fab3eaed1068 (commit)
   via  39347d38b42e28a53d9fa30cc1b78b6be7866878 (commit)
   via  480f526a9e9fc79d561cb5daf3b2457d797c0e6d (commit)
  from  527deefa0a4bede3d45edd867afe2a1a5eb8a7bd (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0fe79c067090dd880826e5334a30af955e15c5e2
commit 0fe79c067090dd880826e5334a30af955e15c5e2
Merge: 527deef 98c72cd
Author: Domen Vrankar 
AuthorDate: Thu Sep 24 20:00:30 2015 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Sep 24 20:00:30 2015 -0400

Merge topic 'cpack-empty-dirs-handling-fix' into next

98c72cde CPack: correctly handle directories creation
901dd534 SystemTools: time operations on directories
39347d38 SystemTools: set time file permissions
480f526a SystemTools: reverted handling of directories in copy file 
functions


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98c72cdeccb98017e39438af8186811c8f998197
commit 98c72cdeccb98017e39438af8186811c8f998197
Author: Domen Vrankar 
AuthorDate: Fri Sep 25 01:35:46 2015 +0200
Commit: Domen Vrankar 
CommitDate: Fri Sep 25 01:35:46 2015 +0200

CPack: correctly handle directories creation

diff --git a/Source/CPack/cmCPackGenerator.cxx 
b/Source/CPack/cmCPackGenerator.cxx
index 04b1976..49f9cb5 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -411,6 +411,33 @@ int 
cmCPackGenerator::InstallProjectViaInstalledDirectories(
   symlinkedFiles.push_back(std::pair(targetFile,inFileRelative));
   }
+else if(cmSystemTools::FileIsDirectory(inFile))
+  {
+  bool dirExists = cmSystemTools::FileExists(filePath);
+  mode_t perm = 0;
+  bool perms = cmSystemTools::GetPermissions(inFile, perm);
+  mode_t destPerm = 0;
+  bool destPerms = false;
+
+  if(dirExists)
+{
+destPerms = cmSystemTools::GetPermissions(filePath, destPerm);
+}
+
+  // create only if dir doesn't exist or dirs differ
+  if(!dirExists || perms != destPerms || perm != destPerm)
+{
+if(!cmSystemTools::MakeDirectory(filePath) ||
+(perms && !cmSystemTools::SetPermissions(filePath, perm)) ||
+!cmSystemTools::CopyFileTime(inFile.c_str(), filePath.c_str()))
+  {
+  cmCPackLogger(cmCPackLog::LOG_ERROR,
+"Problem creating directory: "
+<< filePath << std::endl);
+  return 0;
+  }
+}
+  }
 /* If it is not a symlink then do a plain copy */
 else if (!(
 cmSystemTools::CopyFileIfDifferent(inFile.c_str(),filePath.c_str())

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=901dd53403db10b5c88be8c9ccd9fab3eaed1068
commit 901dd53403db10b5c88be8c9ccd9fab3eaed1068
Author: Domen Vrankar 
AuthorDate: Fri Sep 25 01:25:42 2015 +0200
Commit: Domen Vrankar 
CommitDate: Fri Sep 25 01:33:10 2015 +0200

SystemTools: time operations on directories

On windows FILE_FLAG_BACKUP_SEMANTICS enables us to
read/write time both on files and directories.

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index fa84478..d3c1f16 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2045,10 +2045,11 @@ bool cmSystemTools::CopyFileTime(const char* fromFile, 
const char* toFile)
   cmSystemToolsWindowsHandle hFrom =
 CreateFileW(SystemTools::ConvertToWindowsExtendedPath(fromFile).c_str(),
 GENERIC_READ, FILE_SHARE_READ, 0,
-OPEN_EXISTING, 0, 0);
+OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0);
   cmSystemToolsWindowsHandle hTo =
 CreateFileW(SystemTools::ConvertToWindowsExtendedPath(toFile).c_str(),
-FILE_WRITE_ATTRIBUTES, 0, 0, OPEN_EXISTING, 0, 0);
+FILE_WRITE_ATTRIBUTES, 0, 0, OPEN_EXISTING,
+FILE_FLAG_BACKUP_SEMANTICS, 0);
   if(!hFrom || !hTo)
 {
 return false;
@@ -2100,7 +2101,8 @@ bool cmSystemTools::FileTimeGet(const char* fname, 
cmSystemToolsFileTime* t)
 #if defined(_WIN32) && !defined(__CYGWIN__)
 

Re: [CMake] "Pre-configure" step in CMake

[Matthäus G . Chajdas]

Hi,

that sounds like it would do the trick. I wasn't aware that
execute_process will block the script until it's done executing. Need to
check this out but that definitely looks like the way to go, thanks!

Cheers,
  Matthäus

Am 24.09.2015 um 10:14 schrieb Tamás Kenéz:
> What if you call your dependency-fetcher script with a straight
> macro/function call or `include` or `execute_process` instead of putting
> it into a custom target? I'm thinking of something like this:
> 
> set(DEP_SCRIPT_OUT ${CMAKE_CURRENT_BINARY_DIR}/dep-script-out.cmake) 
> if(NOT EXISTS "${DEP_SCRIPT_OUT}")
>   execute_process(${CMAKE_COMMAND}
> -DC_COMPILER_ID=${CMAKE_C_COMPILER_ID}
> -DC_COMPILER_VERSION=${CMAKE_C_COMPILER_VERSION}
> -DDEP_SCRIPT_OUT =${DEP_SCRIPT_OUT}
> -P dependency-fetcher.cmake)
> endif()
> include(${DEP_SCRIPT_OUT})
> 
> or, simply:
> 
> if(NOT DEPENDENCIES_FETCHED)
>   include(dependency-fetcher.cmake)
>   # fetch_dependencies() # call it in case it's implemented as a
> macro/function
>   set(DEPENDENCIES_FETCHED ON CACHE BOOL "" FORCE)
> endif()
> 
> In the latter case there's no need to write the variables into a script
> since the fetcher runs in the same scope.
> 
> Tamas
> 
> 
> On Wed, Sep 23, 2015 at 9:49 PM, Matthäus G. Chajdas  > wrote:
> 
> Hi,
> 
> I'm trying to solve the following the problem: I have a C++ application
> and a dependency fetching script. I want to simplify the initial build
> such that the following happens: On the first run of cmake, the compiler
> ID and version is passed to an external script, which fetches some
> pre-build binaries. It then writes a CMake file which contains basically
> only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir)
> commands. CMake would then read this file and subsequent find_library
> calls would pick up the values from this new CMake file. The idea is
> that "actual" build is dependent on this first dependency step, but it's
> already within the CMake framework so I can grab the compiler info and
> other build info.
> 
> The obvious problem is that while I can easily run the external script
> by using configure_file, and have a custom target that does the
> dependency fetching and CMake configure file generation. But I don't see
> an easy way to get CMake to make the "rest of the project" depend on
> that configure file. How can I make such a "two-stage" build with CMake?
> 
> Cheers,
>   Matthäus
> --
> 
> 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
> 
> 
> 
> 

-- 

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

Re: [CMake] "Pre-configure" step in CMake

[Matthäus G . Chajdas]

Hi,

how does the ExternalProject interact with subsequent find_library calls?

I've seen projects building dependencies through ExternalProject, but
those would the project manually by querying ExternalProject and adding
a new imported target. How would I connect an ExternalProject to one or
more find_library calls?

Is there a downside from configure taking an unknown amount of time? My
expectation was that there is no timeout for the configure step.

Cheers,
  Matthäus

Am 24.09.2015 um 22:30 schrieb Bill Hoffman:
> On 9/24/2015 4:26 PM, Matthäus G. Chajdas wrote:
>> Hi,
>>
>> that sounds like it would do the trick. I wasn't aware that
>> execute_process will block the script until it's done executing. Need to
>> check this out but that definitely looks like the way to go, thanks!
> ExternalProject might be a better option.  It pushes the downloads to
> build time and handles dependencies without having to re-run CMake.  If
> you run a download script at CMake time, it could take an unknown amount
> of time to configure.
> 
> -Bill
> 
> 

-- 

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