[cmake-developers] Patch: install universal iOS libraries

2015-09-24 Thread 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-developers] Help with diagnosing dashboard failure

2015-09-24 Thread 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

2015-09-24 Thread 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

2015-09-24 Thread 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

2015-09-24 Thread 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

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

2015-09-24 Thread 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-developers] generator expression for path slash conversion

2015-09-24 Thread 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

2015-09-24 Thread 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

2015-09-24 Thread 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

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

2015-09-24 Thread 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

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

2015-09-24 Thread 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

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

2015-09-24 Thread 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

2015-09-24 Thread 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