Re: [cmake-developers] Problems with icons for Windows Store 10.0

[Gilles Khouzam via cmake-developers]

Hi Roman,

Glad to hear that it works.

We discussed this when I implemented the feature, the only reason the 
functionality has been implemented is to supplement the intermediate projects 
that CMake produces that cannot easily be adapted for the requirements of a 
Windows Store application.

For a user's project, the AppXManifest is a critical piece that describes the 
application. There are some fields that need to be appropriately set (publisher 
Id, application name and version), even the icons need to be properly specified 
unless you use the exact same name for the files and don't look at having 
different tile sizes.

For prototyping this might seem like an unnecessary step, but once you start 
customizing the parts of the application, it seems counter intuitive to have 
customizations only apply under certain conditions. Perhaps a better solution 
would be to give an error message if any of the defaults are replaced but a 
manifest is not specified.

-Original Message-
From: Roman Wüger [mailto:roman.wue...@gmx.at] 
Sent: Wednesday, October 5, 2016 22:39
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: Brad King <brad.k...@kitware.com>; CMake Developer MailingList 
<cmake-developers@cmake.org>; CMake MailingList <cm...@cmake.org>
Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0

Thanks Gilles,

I added a custom appxmanifest as you mentioned and it works, but it would 
nevertheless very helpful to customize such things via variables and let CMake 
fill out the rest.

Regards
Roman

> Am 05.10.2016 um 21:19 schrieb Gilles Khouzam <gilles.khou...@microsoft.com>:
> 
> That's most likely because you're missing an AppxManifest.
> 
> In order to build the CMake detection projects, we inject some necessary 
> files into the project when they aren't specified. This includes the manifest 
> and the icons. Can you add your app manifest to the project (look at 
> Tests\VSWinStorePhone if you want an example) and the icons should not be 
> overridden then.
> 
> Thanks
> 
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Wednesday, October 5, 2016 12:09
> To: Roman Wüger <roman.wue...@gmx.at>; Gilles Khouzam 
> <gilles.khou...@microsoft.com>
> Cc: CMake Developer MailingList <cmake-developers@cmake.org>; CMake 
> MailingList <cm...@cmake.org>
> Subject: Re: [cmake-developers] Problems with icons for Windows Store 
> 10.0
> 
>> On 10/05/2016 02:56 PM, Roman Wüger wrote:
>> I tried the following to copy the required app icons to the required 
>> destination:
>> 
>> configure_file(Logo.png
>> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)
> 
> That's a CMake-private directory whose location is an implementation detail.
> Some other interface for configuring this behavior will be needed.
> 
>> The CMake process itself overrides those files at the end with the 
>> files from the CMake's Template directory, which are empty.
> 
> From the current implementation it doesn't look like there is anyway to 
> prevent that.  We'll need to have some configuration of where it gets those 
> files.
> 
>> So, how could I use my icon files and/or what is the preferred way of doing 
>> this?
> 
> Gilles?
> 
> -Brad
> 

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio

[Gilles Khouzam via cmake-developers]

I've changed it to the Debug Universal C-Runtime which should be included with 
the SDK.

This also leverages the version of the SDK to match the other extensions 
reducing the risk of failures.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Tuesday, June 21, 2016 07:32
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: Patch: Add the ability to specify SDK_REFERENCES for Visual Studio

On 06/20/2016 10:48 AM, Brad King wrote:
>  VS: Add VS_SDK_REFERENCES target property to reference external SDKs  
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccc6270d

This caused the VSWinStorePhone tests to fail, e.g.:

 https://open.cdash.org/testDetails.php?test=457508384=4422066
 (ResolveSDKReferences target) ->
  C:\Program Files 
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2049,5): error 
MSB3774: Could not find SDK "Microsoft.NET.Native.Runtime.1.1, Version=1.1".

The problem is that the hard-coded VS_SDK_REFERENCES value in the test names a 
SDK that does not exist on the test machine.  Some other approach will be 
needed to know what SDK can be referenced by the test.

Thanks,
-Brad



0001-FixVS_SDK_REFERENCES.PATCH
Description: 0001-FixVS_SDK_REFERENCES.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] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio

[Gilles Khouzam via cmake-developers]

I'll take a look to find an sdk that is included.



Sent from my Windows 10 phone



From: Brad King<mailto:brad.k...@kitware.com>
Sent: Tuesday, June 21, 2016 7:31
To: Gilles Khouzam<mailto:gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org<mailto:cmake-developers@cmake.org>
Subject: Re: Patch: Add the ability to specify SDK_REFERENCES for Visual Studio



On 06/20/2016 10:48 AM, Brad King wrote:
>  VS: Add VS_SDK_REFERENCES target property to reference external SDKs
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccc6270d

This caused the VSWinStorePhone tests to fail, e.g.:

 https://open.cdash.org/testDetails.php?test=457508384=4422066
 (ResolveSDKReferences target) ->
  C:\Program Files 
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2049,5): error 
MSB3774: Could not find SDK "Microsoft.NET.Native.Runtime.1.1, Version=1.1".

The problem is that the hard-coded VS_SDK_REFERENCES value in the
test names a SDK that does not exist on the test machine.  Some other
approach will be needed to know what SDK can be referenced by the test.

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

[cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio

[Gilles Khouzam via cmake-developers]

This patch is to add the ability with Visual Studio generators to add 
references to SDKs. This is similar to the DESKTOP, IOT and MOBILE extensions 
for Windows 10, but makes the process more generic, using the Property 
VS_SDK_REFERENCES as a semi-colon separated list.

For example, adding a reference to the AdMediatorSDK would look something like 
this:

set_property(TARGET ${EXE_NAME} PROPERTY VS_SDK_REFERENCES 
"Microsoft.AdMediatorWindows81, Version=1.0")


0001-VS_SDK_REFERENCES.patch
Description: 0001-VS_SDK_REFERENCES.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-developers] Patch: Add ability to override the default Visual Studio tool

[Gilles Khouzam via cmake-developers]

This patch is to add the ability to override the default tool assigned by the 
Visual Studio generator based on the extension, by using a new source property 
VS_TOOL_OVERRIDE. This also allows for new tools to be defined without having 
to teach CMake how to handle them.

For example, this allows to have resource support (.resw) files and specifying 
that they are processed with the PRIResource tool.


0001-VS_TOOL_OVERRIDE.PATCH
Description: 0001-VS_TOOL_OVERRIDE.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] Windows 10 Store App - deploy content

[Gilles Khouzam]

We have a pull request on our branch that might be helpful by make them 
extensions.

https://github.com/Microsoft/CMake/pull/15


From: Robert Goulet [mailto:robert.gou...@autodesk.com]
Sent: Thursday, February 25, 2016 07:48
To: cmake-developers@cmake.org; Gilles Khouzam <gilles.khou...@microsoft.com>
Subject: Windows 10 Store App - deploy content

Hi everyone,

When creating a Windows 10 Store App using CMake, how do we add DLL files that 
we do not build (provided by external packages) to the list of content files 
for deployment if they get copied to the output directory by the INSTALL step? 
We currently use install commands to copy dependencies to binaries output 
directory, and it looks like this won't work for Windows 10 Store App because 
they need to be part of the content deployment? i.e. 
set_source_files_properties(${FILES} PROPERTIES VS_DEPLOYMENT_CONTENT 1)

Any idea how I can solve that?

Thanks!

-Robert Goulet
-- 

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] C# support ready for review

[Gilles Khouzam]

Hi Michael,

I've had more time to try this, what is the reasoning to hardcode the default 
LangVersion to 3 in Modules\CMakeCSharpInformation.cmake? Can we remove it? I'm 
trying this on some projects of mine.

From: Stuermer, Michael SP/HZA-ZSEP [mailto:michael.stuer...@schaeffler.com]
Sent: Thursday, February 18, 2016 03:44
To: Gilles Khouzam <gilles.khou...@microsoft.com>; CMake Developers 
<cmake-developers@cmake.org>
Subject: RE: C# support ready for review

Hi Gilles,

you are right about the specific user path. I already fixed this in my github 
"csharp" branch. Sorry for the inconvenience.

As for the discrepancies: I just found out that my TortoiseGitMerge tool was 
not configured correctly: changes in comments where ignored (which is not what 
I wanted). I'll go over the patch again and remove the changes that are 
irrelevant to the C# features.

Thanks for the hint on using MSBuild detection. I currently use the msbuild 
version that is provided automatically by visual studio, so I do not need any 
real detection. I didn't dig too deep into MSBuild versions, .NET framework 
versions, what can be configured etc. The configuration possibilities and what 
would make sense especially for other developers as well is something that 
should be discussed.

My main aim was to be able to work with C# and .NET in a similar way as Visual 
Studio provides it. I only started C# development during the last year, so many 
things concerning configuration etc. could probably be improved.

I'll post a new version of the patch later (or tomorrow) with the mentioned 
changes.

best regards,
Michael


From: Gilles Khouzam [mailto:gilles.khou...@microsoft.com]
Sent: Thursday, February 18, 2016 8:17 AM
To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
Subject: RE: C# support ready for review

Hi Michael,

Great work, this looks really good.

I have a few comments on the changes.


1.   You should use the registry to find the install path for MSBuild, it 
should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the 
version that you're looking for. This also bring the question of do you want to 
be able to specify the version of MSBuild that is used or base it off the 
generator?

2.   In CMakeTestCSharpCompiler, you seem to still have a reference to your 
specific user path (COPY_FILE 
"C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp"))

You seem to have some slight discrepancies between your code and the release as 
there are changes that seem to be either unnecessary or going backwards. I 
noticed a tegra comment that seemed out of place as well as a comment change 
going from 14 to 12 where 14 was accurate.

I'll try to play with this next week and get projects running on it.

~Gilles

From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Stuermer, Michael SP/HZA-ZSEP
Sent: Wednesday, February 10, 2016 06:03
To: CMake Developers 
<cmake-developers@cmake.org<mailto:cmake-developers@cmake.org>>
Subject: [cmake-developers] C# support ready for review

Native C# support is ready for review. I split the patch in two parts:

part 1:

Some preparational stuff that does not really change or enable anything. 
Documentation and Test files as well as the required CMake module is added. The 
changes to existing code are small, only few methods in existing classes are 
added/changed. Changes to existing code should be easy to review in this part

part 2:

This contains the main work. Almost everything takes place within 
cmVisualStudio10TargetGenerator.


In addition to C# support three more target properties were introduced:

*   VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in 
.vcxproj files)
*   VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in 
.csproj files)
*   VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working 
directory in .vcxproj files)

I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything 
works on my machine so far.

Please review/test/comment and give feedback what is necessary to get native C# 
support in upstream cmake.

best regards,
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

Re: [cmake-developers] C# support ready for review

[Gilles Khouzam]

Hi Michael,

Great work, this looks really good.

I have a few comments on the changes.


1.   You should use the registry to find the install path for MSBuild, it 
should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the 
version that you're looking for. This also bring the question of do you want to 
be able to specify the version of MSBuild that is used or base it off the 
generator?

2.   In CMakeTestCSharpCompiler, you seem to still have a reference to your 
specific user path (COPY_FILE 
"C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp"))

You seem to have some slight discrepancies between your code and the release as 
there are changes that seem to be either unnecessary or going backwards. I 
noticed a tegra comment that seemed out of place as well as a comment change 
going from 14 to 12 where 14 was accurate.

I'll try to play with this next week and get projects running on it.

~Gilles

From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Stuermer, Michael SP/HZA-ZSEP
Sent: Wednesday, February 10, 2016 06:03
To: CMake Developers 
Subject: [cmake-developers] C# support ready for review

Native C# support is ready for review. I split the patch in two parts:

part 1:

Some preparational stuff that does not really change or enable anything. 
Documentation and Test files as well as the required CMake module is added. The 
changes to existing code are small, only few methods in existing classes are 
added/changed. Changes to existing code should be easy to review in this part

part 2:

This contains the main work. Almost everything takes place within 
cmVisualStudio10TargetGenerator.


In addition to C# support three more target properties were introduced:

*   VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in 
.vcxproj files)
*   VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in 
.csproj files)
*   VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working 
directory in .vcxproj files)

I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything 
works on my machine so far.

Please review/test/comment and give feedback what is necessary to get native C# 
support in upstream cmake.

best regards,
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

Re: [cmake-developers] CMake Windows 10 Store App

[Gilles Khouzam]

Hi Roman,

The solution produced by CMake will be able to produce the appxupload bundle 
through Visual Studio. If you select your app project, in the build->Store menu 
you can create the app bundles.

Are you looking to automate that?

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Roman Wüger
Sent: Thursday, February 11, 2016 06:48
To: CMake Developer MailingList 
Subject: [cmake-developers] CMake Windows 10 Store App

Hello,

I use CMAKE_SYSTEM_NAME:STRING=WindowsStore and CMAKE_SYSTEM_VERSION=10.0 to 
build an universal app. However, does CMake also support *.appxupload and such 
bundles? And if so, how?

Thanks in advance
Best regards
Roman
-- 

Powered by 
https://na01.safelinks.protection.outlook.com/?url=www.kitware.com=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=FXx2mNGG3j9z%2bIk5kJQlm78idyf8obOU7EPpJkSsIhE%3d

Please keep messages on-topic and check the CMake FAQ at: 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.cmake.org%2fWiki%2fCMake_FAQ=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=FQaCHxP1kLgqbwI19FaYOh%2bHRt5gvYK8kFPPQh2shGg%3d

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

CMake Support: 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2fsupport.html=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=We1QJxq9SOTpxQ7lw0toN7hshEn3LEHjtZe9L%2bJL3jk%3d
CMake Consulting: 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2fconsulting.html=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=wzZUA0UiSCU0t8qxlJ2E35urkr3j7SqE5Z8C6%2bvQvN4%3d
CMake Training Courses: 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcmake.org%2fcmake%2fhelp%2ftraining.html=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=mlFgqO6k%2bcuKIHYUJ4ntzEYZNkNu2T1vN0W5PbEPPBQ%3d

Visit other Kitware open-source projects at 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.kitware.com%2fopensource%2fopensource.html=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=Wrj57Y7RjmaLn7UnNkQp0aMqMOyDdXry%2bRl5VcC1GHk%3d

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fpublic.kitware.com%2fmailman%2flistinfo%2fcmake-developers=01%7c01%7cgilles.khouzam%40microsoft.com%7c3416bedca35349e6977308d332f26dce%7c72f988bf86f141af91ab2d7cd011db47%7c1=q8Z56SvLk7vRlXZBm%2f%2fwHfpUQLY72nSMBWjahttOqjU%3d
-- 

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] Question related to Visual Studio 14 2015 [MyTarget]

[Gilles Khouzam]

I'm trying to understand what is necessary to make this work. I'll circle back 
when I find out more information.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Monday, February 8, 2016 10:32
To: Yi-Hong Lyu <b95705...@ntu.edu.tw>
Cc: cmake-developers@cmake.org; Gilles Khouzam <gilles.khou...@microsoft.com>
Subject: Re: [cmake-developers] Question related to Visual Studio 14 2015 
[MyTarget]

On 02/05/2016 02:41 PM, Yi-Hong Lyu wrote:
> 1. What I need to do is to add an option MyTarget for arch of "Visual 
> Studio 14 2015 [arch]", just like "Visual Studio 14 2015 [Win64]"
> or "Visual Studio 14 2015 [ARM]"?

Naming the architecture as part of the generator name is a legacy behavior.
See the "-A " option.

> 2. How can I support cl.exe and clang-cl.exe by Visual Studio 14 2015 
> [MyTarget]"?
> Should I add options cl.exe/clang-cl.exe for toolset-name of "-T 
> "?

The -T option is indeed the CMake side of it.  I'm not familiar with what else 
has to be done on the host to make VS understand the toolset name though.

> 3. Is there any way to make sure that all x86/x64 headers/libraries are not 
> included/linked?
> I'd like only include/link headers/libraries of MyTarget.

CMake doesn't add any system include directories or link directories.  For 
command line builds those need to be part of the environment.  For VS IDE 
builds they are made available by the IDE when running the toolchain based on 
the options discussed above.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake can't generate Windows 10 store app with VS2015 Update 1

[Gilles Khouzam]

Hi Roman,

I can help with this. You should be good with VS 2015 and the Windows 10 SDK.

After you installed the SDK, did you get the same error message or a different 
one?

From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Roman Wüger
Sent: Friday, February 5, 2016 07:41
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMake can't generate Windows 10 store app with 
VS2015 Update 1

Ok, I've installed all options from the SDK 
(https://dev.windows.com/en-us/downloads/windows-10-sdk)
but it doesn't solve the issue.

Is there something other to install?
What things does CMake require?

Best Regards
Roman

Am 05.02.2016 um 14:54 schrieb Roman Wüger 
>:
Hello,

I’ve Installed Windows 10 Professional with VS2015 Update 1 and CMake 3.4.3.
When I run configure:

cmake -G "Visual Studio 14 Win64" -DCMAKE_SYSTEM_NAME:STRING=WindowsStore 
-DCMAKE_SYSTEM_VERSION:STRING=10.0 ..\source

Then I became the following error message:

CMake Error at CMakeLists.txt:3 (PROJECT):
  A Windows Store component with CMake requires both the Windows Desktop SDK
  as well as the Windows Store '10.0' SDK.  Please make sure that you have
  both installed


-- Configuring incomplete, errors occurred!

Did I need something additional to get it working?

Thanks in advance

Best Regards
Roman
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [Patch] Adding Windows 10 Universal app support

[Gilles Khouzam]

This patch adds Windows Universal (store) app support. Just like Windows 8.0 
and Windows 8.1, this will
allow to produce a Windows 10 Store application (there are no more Phone apps 
as they are the same now).

>From the commit message:
This change adds support for Windows 10 Universal (Store) Applications.

A Windows 10 Universal Application can be targeted by setting:
CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0
There are no WindowsPhone apps, universal apps target both phone and store.
Specifying the CMAKE_SYSTEM_VERSION to be 10.0 will use the latest Windows
10 SDK installed. If you want to specify a specific SDK, you can make
CMAKE_SYSTEM_VERSION be more specific (10.0.10240.0 for RTM for example).


New Properties Added:
VS_WINDOWS_TARGET_PLATFORM_MIN_VERSION: Target Property.
Specifies the minimum version of the OS that the project can target.

VS_DESKTOP_EXTENSIONS_VERSION, VS_MOBILE_EXTENSIONS_VERSIONS,
VS_IOT_EXTENSIONS_VERSION: Target property. When specifying these properties
a reference to the version of the SDK specified will be added to the
target allowing to target the extended functionality in a universal project.
To match the version of the SDK being used, use
CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION

VS_IOT_STARTUP_TASK: Target property. Specifies that the target should be
built as an IOT continuous background task.


0001-Windows-10-Universal-Store-Apps.patch
Description: 0001-Windows-10-Universal-Store-Apps.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] [Patch] Adding Windows 10 support

[Gilles Khouzam]

Hi Brad,

I've changed the code of the 3rd patch to remove the 
WINDOWS_TARGET_PLATFORM_VERSION and CMAKE_WINDOWS_TARGET_PLATFORM_VERSION and 
simply use the SystemVersion to determine the version of the Windows 10 SDK to 
use.

Now, by default on Windows 10 host devices with Visual Studio 2015, the latest 
SDK will be used. I've also changed the sorting of the SDKs and comparison 
checks to use cmSystemTools::VersionCompare.


-Original Message-
From: Gilles Khouzam 
Sent: Monday, September 28, 2015 14:35
To: Brad King <brad.k...@kitware.com>
Cc: cmake-developers@cmake.org
Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support

The more I think about it, the more this makes sense and should work out well.

Let me take your current changes and adapt them for this and test them out.

-Original Message-
From: Gilles Khouzam
Sent: Friday, September 25, 2015 14:55
To: 'Brad King' <brad.k...@kitware.com>
Cc: cmake-developers@cmake.org
Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support

You're right, by targeting another version (8.1 or 6.3), the tag would not be 
written. 

Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a 
little bit more and see how I would apply to newer SDKs as they come out, as I 
would like to minimize the required changes to CMake to support things when 
they come out (I'm gathering some information on that).


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Friday, September 25, 2015 11:53
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/25/2015 01:00 PM, Gilles Khouzam wrote:
> This was done deliberately to only force a value for 
> CMAKE_WINDOWS_TARGET_PLATFORM_VERSION

With the approach in my patch that variable is never set by the generator.  It 
chooses a WindowsTargetPlatformVersion value and reports it in 
CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.
The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined 
selection.

> when the CMAKE_SYSTEM_VERSION is specified as 10.0.
> Otherwise any Windows 10 machine will use the Windows 10 SDK and not 
> the Windows 8.1 SDK

Why is it wrong to target the host's version by default?
This is commonly done on other platforms.  If one is building only for the 
current host this makes sense.  If one is building for deployment then extra 
care is needed anyway.

> and I'm not sure that there is a way then target the Windows 8.1 SDK.

If one wants to build on a Windows 10 host but target an older version of 
Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example.  This is 
thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME.

Actually, why do we need a separate setting like 
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all?
Why not just take the highest available SDK that does not exceed 
CMAKE_SYSTEM_VERSION?  CMAKE_SYSTEM_VERSION is meant exactly to specify the 
target OS version.  You posted something about this here:

 https://cmake.org/Bug/view.php?id=15670#c39247

but I do not quite understand it.

Thanks,
-Brad



0003-VS-Add-support-for-selecting-the-Windows-10-SDK.PATCH
Description: 0003-VS-Add-support-for-selecting-the-Windows-10-SDK.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] [Patch] Adding Windows 10 support

[Gilles Khouzam]

The more I think about it, the more this makes sense and should work out well.

Let me take your current changes and adapt them for this and test them out.

-Original Message-
From: Gilles Khouzam 
Sent: Friday, September 25, 2015 14:55
To: 'Brad King' <brad.k...@kitware.com>
Cc: cmake-developers@cmake.org
Subject: RE: [cmake-developers] [Patch] Adding Windows 10 support

You're right, by targeting another version (8.1 or 6.3), the tag would not be 
written. 

Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a 
little bit more and see how I would apply to newer SDKs as they come out, as I 
would like to minimize the required changes to CMake to support things when 
they come out (I'm gathering some information on that).


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Friday, September 25, 2015 11:53
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/25/2015 01:00 PM, Gilles Khouzam wrote:
> This was done deliberately to only force a value for 
> CMAKE_WINDOWS_TARGET_PLATFORM_VERSION

With the approach in my patch that variable is never set by the generator.  It 
chooses a WindowsTargetPlatformVersion value and reports it in 
CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.
The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined 
selection.

> when the CMAKE_SYSTEM_VERSION is specified as 10.0.
> Otherwise any Windows 10 machine will use the Windows 10 SDK and not 
> the Windows 8.1 SDK

Why is it wrong to target the host's version by default?
This is commonly done on other platforms.  If one is building only for the 
current host this makes sense.  If one is building for deployment then extra 
care is needed anyway.

> and I'm not sure that there is a way then target the Windows 8.1 SDK.

If one wants to build on a Windows 10 host but target an older version of 
Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example.  This is 
thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME.

Actually, why do we need a separate setting like 
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all?
Why not just take the highest available SDK that does not exceed 
CMAKE_SYSTEM_VERSION?  CMAKE_SYSTEM_VERSION is meant exactly to specify the 
target OS version.  You posted something about this here:

 https://cmake.org/Bug/view.php?id=15670#c39247

but I do not quite understand it.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Gilles Khouzam]

Thanks for the refactor Brad,

The patches make sense.

>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.

This was done deliberately to only force a value for 
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION when the CMAKE_SYSTEM_VERSION is 
specified as 10.0. Otherwise any Windows 10 machine will use the Windows 10 SDK 
and not the Windows 8.1 SDK and I'm not sure that there is a way then target 
the Windows 8.1 SDK.


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Thursday, September 24, 2015 13:35
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

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
-- 

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 offe

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

[Gilles Khouzam]

You're right, by targeting another version (8.1 or 6.3), the tag would not be 
written. 

Leveraging CMAKE_SYSTEM_VERSION is an interesting idea. Let me mull it over a 
little bit more and see how I would apply to newer SDKs as they come out, as I 
would like to minimize the required changes to CMake to support things when 
they come out (I'm gathering some information on that).


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Friday, September 25, 2015 11:53
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/25/2015 01:00 PM, Gilles Khouzam wrote:
> This was done deliberately to only force a value for 
> CMAKE_WINDOWS_TARGET_PLATFORM_VERSION

With the approach in my patch that variable is never set by the generator.  It 
chooses a WindowsTargetPlatformVersion value and reports it in 
CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.
The CMAKE_WINDOWS_TARGET_PLATFORM_VERSION variable is only for the user-defined 
selection.

> when the CMAKE_SYSTEM_VERSION is specified as 10.0.
> Otherwise any Windows 10 machine will use the Windows 10 SDK and not 
> the Windows 8.1 SDK

Why is it wrong to target the host's version by default?
This is commonly done on other platforms.  If one is building only for the 
current host this makes sense.  If one is building for deployment then extra 
care is needed anyway.

> and I'm not sure that there is a way then target the Windows 8.1 SDK.

If one wants to build on a Windows 10 host but target an older version of 
Windows, one can simply do -DCMAKE_SYSTEM_VERSION=6.3 for example.  This is 
thanks to your patch that allows it to be set separately from CMAKE_SYSTEM_NAME.

Actually, why do we need a separate setting like 
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION to select this at all?
Why not just take the highest available SDK that does not exceed 
CMAKE_SYSTEM_VERSION?  CMAKE_SYSTEM_VERSION is meant exactly to specify the 
target OS version.  You posted something about this here:

 https://cmake.org/Bug/view.php?id=15670#c39247

but I do not quite understand it.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Gilles Khouzam]

>CMAKE_SYSTEM_NAME is already always defined to a value detected from the host 
>system when not defined by a toolchain file or by the user in the cache.  On a 
>Windows host the value will be "Windows".

>I don't fully understand the case in question.  When not building for Windows 
>Store, does WindowsTargetPlatformVersion need a value if the user does not 
>request one?  What happens if it does not get a value?  Is it >needed for 
>Windows 10 Desktop?

Ok, if the CMAKE_SYSTEM_NAME is defined as Windows by default, then this should 
be good. Yes, the property is also used in desktop if someone wants to use the 
Windows 10 SDK instead of the Windows 8.1 SDK. If the property is not present 
then the default is to use the Windows 8.1 SDK. I'm suggesting that if the 
SYSTEM_NAME is Windows but the Version is set to 10.0 then we can use the same 
logic as for Store apps.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, September 23, 2015 05:38
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/23/2015 01:29 AM, Gilles Khouzam wrote:
> Now, for the default behavior, if
> CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is set through a toolchain file 
> or the project, then that will be the default which will initialize 
> the WINDOWS_TARGET_PLATFORM_VERSION for each target through the 
> SetPropertyDefault initialization call. On the other hand, if 
> CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is not set, nothing should 
> happen since this is not a required property other than for Windows 10 
> Universal (store) apps, the default behavior in that case should be to 
> not have the property.

Okay.

> There is one open issue though. How should we have the value for 
> CMAKE_WINDOWS_TARGET_PLATFORM_VERSION be the latest installed SDK when 
> this is not a Windows Store project? For Windows Store projects this 
> would get set if the property is not defined through the 
> InitializeSystem procedure. How would we handle this for the non 
> Windows Store case? Do this based on the version and no 
> CMAKE_SYSTEM_NAME defined? Or should we force there to be a 
> CMAKE_SYSTEM_NAME to be defined as Windows for example?

CMAKE_SYSTEM_NAME is already always defined to a value detected from the host 
system when not defined by a toolchain file or by the user in the cache.  On a 
Windows host the value will be "Windows".

I don't fully understand the case in question.  When not building for Windows 
Store, does WindowsTargetPlatformVersion need a value if the user does not 
request one?  What happens if it does not get a value?  Is it needed for 
Windows 10 Desktop?

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Gilles Khouzam]

Ok, I've got this working as discussed.

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. This property enables a Windows 10 Desktop project to 
use a specific version of the Windows 10.

If CMAKE_SYSTEM_VERSION is set to 10.0 then the latest Windows 10 SDK but not 
more recent than the current build of Windows. If you want to specify a 
specific version to use, then there is the global property 
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION that will be passed down to each target. 
To specify a value for a specific target there is the target property 
WINDOWS_TARGET_PLATFORM_VERSION.

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.

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.

Yes, you have the right versions for all the CMAKE_HOST_SYSTEM_VERSION for the 
different OS versions.


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, September 23, 2015 07:17
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/23/2015 10:03 AM, Gilles Khouzam wrote:
> If the property is not present then the default is to use the Windows 8.1 SDK.

Thanks for explaining that VS behavior.

> I'm suggesting that if the SYSTEM_NAME is Windows but the Version is 
> set to 10.0 then we can use the same logic as for Store apps.

Yes, if CMAKE_SYSTEM_NAME is "Windows" and CMAKE_SYSTEM_VERSION indicates 
Windows > 8.1 then we should use the latest SDK that is available but not newer 
than the version of Windows targeted.

BTW, what are the values of CMAKE_HOST_SYSTEM_VERSION on Windows 7, 8, 8.1, and 
10 when CMake is built with the new manifest file?
IIUC they should be:

 Windows 7   => 6.1
 Windows 8   => 6.2
 Windows 8.1 => 6.3
 Windows 10  => 10.0

plus a third component for the Windows build number.

Thanks,
-Brad



WindowsTargetPlatform.patch
Description: WindowsTargetPlatform.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] [Patch] Adding Windows 10 support

[Gilles Khouzam]

Thanks for the feedback Brad,

I have rebased the changes and I think that I have the proper default 
functionality properly implemented. I've extracted the 
WINDOWS_TARGET_PLATFORM_VERSION changes into a separate patch.

WINDOWS_TARGET_PLATFORM_VERSION is a target property, for that will specify the 
WindowsTargetPlatformVersion tag in VS.
WINDOWS_TARGET_PLATFORM_MIN_VERSION is a target property that will specify the 
WindowsTargetPlatformMinVersion tag in VS.

Now, for the default behavior, if CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is set 
through a toolchain file or the project, then that will be the default which 
will initialize the WINDOWS_TARGET_PLATFORM_VERSION for each target through the 
SetPropertyDefault initialization call. On the other hand, if 
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION is not set, nothing should happen since 
this is not a required property other than for Windows 10 Universal (store) 
apps, the default behavior in that case should be to not have the property.

There is one open issue though. How should we have the value for 
CMAKE_WINDOWS_TARGET_PLATFORM_VERSION be the latest installed SDK when this is 
not a Windows Store project? For Windows Store projects this would get set if 
the property is not defined through the InitializeSystem procedure. How would 
we handle this for the non Windows Store case? Do this based on the version and 
no CMAKE_SYSTEM_NAME defined? Or should we force there to be a 
CMAKE_SYSTEM_NAME to be defined as Windows for example?


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Monday, September 21, 2015 08:09
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/10/2015 09:31 PM, Gilles Khouzam wrote:
> Here is the patch for Windows 10 Support which would be issue 15686.
[snip]
> This change requires the change for issue 0015674 for determining the 
> version of the OS.

That change is now done as posted here:

 [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14327/focus=14478

Please rebase the rest of your Win 10 patch on that and revise according to the 
comments below.

> New Properties Added:
> VS_TARGET_PLATFORM_VERSION: Target property. Specifies that the SDK 
> being used to compile the project. For Windows 10 RTM, that will be 
> 10.0.10240.0.
> For Store apps, this property is required by Visual Studio. If the 
> property is not specified, the system will be queried for the 
> available Windows 10 SDKs installed and the most recent but less than 
> or equal version than the host system version will be set as a default 
> (in
> CMAKE_VS_TARGET_PLATFORM_VERSION) and used.

Please split this part out into its own (preceding) patch, much like was done 
for the windows version detection.  Also, currently the patch does not 
implement [CMAKE_]VS_TARGET_PLATFORM_VERSION as previously discussed:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14201/focus=14246

For example:

> +  if (this->SystemVersion == "10.0")
> +{
> +// Find the default version of the Windows 10 SDK and set
> +// a default CMAKE_VS_TARGET_PLATFORM_VERSION
> +std::string sdkVersion = GetWindows10SDKVersion();
> +if(sdkVersion.empty())
> +  {
> +  e << "Could not find an appropriate version of the Windows 10 SDK"
> +<< "installed on this machine";
> +  mf->IssueMessage(cmake::FATAL_ERROR, e.str());
> +  return false;
> +  }
> +mf->AddDefinition("CMAKE_VS_TARGET_PLATFORM_VERSION",
> +  sdkVersion.c_str());
> +}

Logic like this should be used to select a default SDK when neither the 
property nor the variable is set.  I think we've had some confusion between the 
user-settable target property/variable and the generator- reported selection 
result used by the compiler id.  The latter is used here in your patch:

> +set(id_WindowsTargetPlatformVersion 
> + "${CMAKE_VS_TARGET_PLATFORM_VERSION} + WindowsTargetPlatformVersion>")

Currently the CMAKE_VS_ convention is used by the VS generators to report 
information about what the've decided.  I think this makes sense so a variable 
called CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION
could serve this purpose (reporting to project code what VS decided to use).

What we need separately is an interface for users and/or project code to select 
a specific WindowsTargetPlatformVersion.  The target property currently called 
VS_TARGET_PLATFORM_VERSION will work well for project code to set the value for 
specific targets.  We still need another setting for users or toolchain files 
to set to make it a project-wide default.  Perhaps we should have a separate 
v

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

[Gilles Khouzam]

Great. Thanks

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Friday, September 18, 2015 11:24
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [PATCH] [CMake 0015674]: Windows: Correctly determine Windows 
version

On 09/10/2015 07:24 PM, Gilles Khouzam wrote:
> This patch adds a simple version manifest 
> Source\cmake.version.manifest to the CMake executables.

After working out the support for manifests across all generators as discussed 
elsewhere in this thread, I've added your manifest file to CMake's own build:

 Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Gilles Khouzam]

Brad,

>From my understanding GetVersionEx was causing a nightmare of app 
>compatibility issues where developers would make the wrong comparison or 
>assumption based on the version and applications would break on new releases. 
>I don't know that deprecating the API and making it require a manifest was a 
>better solution, but it does require more intentional work on the developer 
>before just using the API. For the usage that CMake is using it is benign and 
>doesn't look like it would cause compatibility issues.

Here's the updated patch for Windows 10 support.

1. Added support for Windows Universal applications as 
CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0
2. Added support for manifest files, when specifying a manifest as a source 
file, it will be added to the  tag of the  
section in the vcxproj file (VisualStudio 10 generator only). Multiple 
manifests could be added.
3. Added a manifest to the CMake executables to enable proper version API 
support on Windows 8 and above. The file is Source\cmake.version.manifest.
4. Added a detection mechanism to figure out which Windows 10 SDK is installed 
and can be used on the machine. This follows the detection logic that VS 2015 
uses. The SDK selected will be the latest SDK that is less or equal to the 
build of the HOST. This change requires the manifest.
5. Added Windows 10 Universal tests in VSWinStorePhone
6. Added a 2 new target properties: VS_TARGET_PLATFORM_VERSION and 
VS_TARGET_PLATFORM_MIN_VERSION, these set the  
and  tags in the vcxproj file. If 
VS_TARGET_PLATFORM_VERSION is not set for a target and is required, a default 
is set a CMAKE_VS_TARGET_PLATFORM_VERSION based on the lastest usable Windows 
10 SDK.
 7. Added a new target property VS_TOOL_OVERRIDE to enable adding new file 
types to VS without requiring to teach CMake how to handle them. This property, 
set on a source file will override the default tool assigned in Visual Studio. 
This enables support for RESW files for example without teaching CMake how to 
handle them.
8. Added support for Windows 10 extensions with 3 new properties: 
VS_DESKTOP_EXTENSIONS_VERSION, VS_MOBILE_EXTENSIONS_VERSION and 
VS_IOT_EXTENSIONS_VERSION. These specify the version of the different 
extensions and whether they are used. When an extension is used, an SDK 
reference is added for that extension.
9. Added a new property: VS_IOT_STARTUP_TASK to specify if the target has a 
startup task for and IOT project.

I realize that there are a lot of changes in here, but the combination of them 
are all required for proper Windows 10 support. I can split it up in multiple 
patches if that makes it easier.

#2 and #3 could be a different patch that Windows 10 support depends on.


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Thursday, September 10, 2015 06:39
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/09/2015 05:48 PM, Gilles Khouzam wrote:
> Even though GetVersionEx is deprecated, it is the right way to get the 
> system version, loading ntdll and getting RtlGetVersion is not a good 
> practice as those are private APIs that could change.

The change was contributed recently:

 Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8.1 (#15674)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4736d53

for this issue:

 http://www.cmake.org/Bug/view.php?id=15674

I've re-opened the issue.  I would really like to know why MS deprecated 
GetVersionEx.  The Version Helper APIs are only good for checking >= level, not 
getting the actual version.  Why not add the helpers and leave GetVersionEx 
available too?  Why do we need to add a manifest just to get the OS version?  
What is a library author supposed to do when s/he cannot control the 
application that will link the library?

FYI, the GetVersionEx documentation page:

 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx

has a community-mentioned recommendation to use RtlGetVersion.

Thanks,
-Brad



Windows10.patch
Description: Windows10.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] [Patch] Adding Windows 10 support

[Gilles Khouzam]

Here is the patch for Windows 10 Support which would be issue 15686.

This is dependent on the patch for issue 15674 which is the version detection 
change.

>From the commit message:
This change adds support for Windows 10 Universal Applications.

A Windows 10 Universal Application can be targeted by setting:
CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0
There are no WindowsPhone apps, universal apps target both phone and store.

New Properties Added:
VS_TARGET_PLATFORM_VERSION: Target property. Specifies that the SDK being
used to compile the project. For Windows 10 RTM, that will be 10.0.10240.0.
For Store apps, this property is required by Visual Studio. If the property
is not specified, the system will be queried for the available Windows 10
SDKs installed and the most recent but less than or equal version than the
host system version will be set as a default (in
CMAKE_VS_TARGET_PLATFORM_VERSION) and used.

VS_TARGET_PLATFORM_MIN_VERSION: Target Property. Specifies the minimum
version of the OS that the project can target.

VS_DESKTOP_EXTENSIONS_VERSION, VS_MOBILE_EXTENSIONS_VERSIONS,
VS_IOT_EXTENSIONS_VERSION: Target property. When specifying these properties
a reference to the version of the SDK specified will be added to the project
allowing to target the extended functionality in a universal project.

VS_IOT_STARTUP_TASK: Target property. Specifies that the target should be
built as an IOT continuous background task.

VS_TOOL_OVERRIDE: Source property. For common files, allows to modify the
tool that gets applied to the source file. For example, when adding a
.RESW file to the project, since CMake doesn't know how to handle them, it
will assign a None Tool to the file. This allows to override the default
and specify a new tool to handle.

This change requires the change for issue 0015674 for determining the
version of the OS.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Thursday, September 10, 2015 12:08
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/10/2015 03:04 PM, Brad King wrote:
> On 09/10/2015 02:37 PM, Gilles Khouzam wrote:
>> I can split it up in multiple patches if that makes it easier.
> 
> Yes, please.  That makes review and future reading of history easier 
> because we see a commit message associated with each corresponding set 
> of changes.
> 
> Please order the patches so that no existing functionality breaks at 
> any step and everything compiles.

Also please produce the patches with "git format-patch" so that commit messages 
and authorship info comes with each one.

Thanks,
-Brad



Issue15686.patch
Description: Issue15686.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-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

[Gilles Khouzam]

This patch fixes the issue where on Windows 8 and above, by default the system 
version returned is always Windows 8.

More info on this can be found on 
http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibility-on-windows-7.aspx

In order for GetVersionEx to work properly, a manifest must be embedded in the 
exe telling it to ignore the new behavior and give the proper version.

This patch adds support to specify manifests and teaches CMake how to embed 
them using Visual Studio.
This patch adds a simple version manifest Source\cmake.version.manifest to the 
CMake executables.
This removes the use of RtlGetVersion and properly uses GetVersionEx which will 
now return the proper operating system version for all operating systems until 
Windows 10.
This patch also fixes a potential buffer overrun and improper call of 
GetVersionEx in SystemTools.cxx where GetVersionExW is called with a 
OSVERSIONINFOEXA struct causing a failure since the size is improper for the 
API. Fixing this, GetVersionEx should never fail anymore.
Update the OSVersionAndName for new versions of Windows released after Windows 
7.

This change will require a double compile of CMake (I'm not sure if this is 
what the dashboards are doing) to have the functionality enabled, since the 
first step will build a new CMake that will know how to embed a manifest. The 
second compile with the version of CMake that knows how to embed a manifest, 
will then embed the manifest in CMake enabling this feature.

Thanks

~Gilles


Issue15674.patch
Description: Issue15674.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] [Patch] Adding Windows 10 support

[Gilles Khouzam]

Thanks Brad.

As I've been writing this code, I was looking for the build number and came 
across the code in cmGlobalGenerator that sets the CMAKE_HOST_SYSTEM_VERSION. 
Even though GetVersionEx is deprecated, it is the right way to get the system 
version, loading ntdll and getting RtlGetVersion is not a good practice as 
those are private APIs that could change. On newer systems (Windows 8 and 
above) by default the version returned doesn't go beyond Windows 8 Build 9200, 
but you can apply a manifest to the executable that will let the API give you 
the correct information and this is a more correct way of handling this.

I don't know if there's another reason for the code to be as it is, but I think 
it would be a better practice to opt into the proper GetVersionEx behavior by 
adding a manifest than by calling GetProcAddress on an internal API.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, September 9, 2015 08:00
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/03/2015 03:19 PM, Gilles Khouzam wrote:
> Perhaps the default selection (at least for Store apps since that's 
> the one that requires the flag) should be the newest SDK less than the 
> version of the host System.

Yes, I think that makes sense.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Gilles Khouzam]

Sorry, you are right, try_compile calls do use the generator and don't have a 
problem. 

I was trying to do something similar to what you are describing here:
> We could simply define a
> 
>  CMAKE_VS_TARGET_PLATFORM_VERSION
> 
> variable that is used to initialize VS_TARGET_PLATFORM_VERSION target 
> properties (see SetPropertyDefault calls in the source).
> Then the generator can look just at the target property.  If not set it 
> should choose a default based on the current host version of Windows as 
> discussed above.  Then we just need to teach cmCoreTryCompile to propagate 
> this
> setting.
> 
> The above-linked issue also mentions that TargetFrameworkVersion may need 
> similar infrastructure.

Perhaps the default selection (at least for Store apps since that's the one 
that requires the flag) should be the newest SDK less than the version of the 
host System. If CMAKE_VS_TARGET_PLATFORM_VERSION is specified then we would 
simply use it.


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, September 2, 2015 08:25
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 09/01/2015 05:19 PM, Gilles Khouzam wrote:
> For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to achieve is 
> almost an internal property that is used for the try_compile phase. 
> Since the generator is not used in that scenario, the project is using 
> the template from Modules/CompilerId/VS-10.vcxproj.in. In that case, 
> we need to set the tag for the WindowsTargetPlatformVersion. During 
> the generation, I query for the latest SDK version in the 
> GlobalGenerator and set the VS_DEFAULT_TARGET_PLATFORM_VERSION
> property that is then used in CMakeDetermineCompilerId.cmake to set 
> the variable that the template uses in the Windows 10 case.

The generator *is* used for try_compile calls.  The template in 
Modules/CompilerId/VS-10.vcxproj.in is used *only* for the compiler 
identification step which occurs before we have enough information to do a full 
try_compile.  The compiler id step does need special handling to set this 
value, but it should be based on however the value is determined for the 
generator normally.

As discussed in http://www.cmake.org/Bug/view.php?id=15670
the SDK for the latest Windows version may not be the proper default choice.  
Perhaps it should be the SDK for the host machine's version of Windows to make 
sure we don't use APIs that cannot run on the current machine.  IIRC this is 
the default on OS X with CMAKE_OSX_SYSROOT.

Unlike CMAKE_OSX_SYSROOT, which is used by all generators on OS X, the 
WindowsTargetPlatformVersion value is something only for the VS IDE generators. 
 In any command-line build we expect the INCLUDE/LIB environment variables to 
already be set to the proper location.  Therefore we need to define a way to 
set the WindowsTargetPlatformVersion only for VS IDE generators since they 
generate the environment in which to run the toolchain.

CMAKE_GENERATOR_TOOLSET and CMAKE_GENERATOR_PLATFORM are existing options with 
generator-specific behavior.  For VS they set  and , 
respectively.
There is quite a bit of C++-side infrastructure to propagate these values to 
all the right places (and honor cmake -T and -A options on the command line).  
I'd rather not have something quite so heavyweight for 
WindowsTargetPlatformVersion because it is a pretty narrow case that should not 
need a dedicated command-line option and won't be meaningful to other 
generators.

We could simply define a

 CMAKE_VS_TARGET_PLATFORM_VERSION

variable that is used to initialize VS_TARGET_PLATFORM_VERSION target 
properties (see SetPropertyDefault calls in the source).
Then the generator can look just at the target property.  If not set it should 
choose a default based on the current host version of Windows as discussed 
above.  Then we just need to teach cmCoreTryCompile to propagate this setting.

The above-linked issue also mentions that TargetFrameworkVersion may need 
similar infrastructure.

-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-developers] [Patch] Build Windows Phone/Store 8.1 on VS 2015

[Gilles Khouzam]

Fixing issue:

https://public.kitware.com/Bug/view.php?id=15662
[CMake 0015662]: Add support for Windows/Windows Phone SDKs with Visual Studio 
2015

The issue raised it caused by the fact that we were validating that we have a 
desktop SDK based on the version of the app what we are producing instead of 
the generator being used. By making the method virtual, we can query that we 
have the desktop SDK installed for the generator selected.




Build8.1OnVS2015.patch
Description: Build8.1OnVS2015.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] [Patch] Adding Windows 10 support

[Gilles Khouzam]

Hi Brad,

Thanks for the feedback.

I've extracted the change to build Windows 8.1 on VS 2015 and submitted it as a 
separate change. Windows 10 support will need to be built on top of the other 
change since they share some of the same code.

For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to achieve is almost an 
internal property that is used for the try_compile phase. Since the generator 
is not used in that scenario, the project is using the template from 
Modules/CompilerId/VS-10.vcxproj.in. In that case, we need to set the tag for 
the WindowsTargetPlatformVersion. During the generation, I query for the latest 
SDK version in the GlobalGenerator and set the 
VS_DEFAULT_TARGET_PLATFORM_VERSION property that is then used in 
CMakeDetermineCompilerId.cmake to set the variable that the template uses in 
the Windows 10 case.

I'm not sure if there's a different/better way to handle this case.


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Monday, August 31, 2015 13:06
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [Patch] Adding Windows 10 support

On 08/30/2015 06:41 PM, Gilles Khouzam wrote:
> http://www.cmake.org/Bug/view.php?id=15670
> Add support for setting "Windows target platform version" in VS2015

Most of your changes look good but I think this issue needs more discussion.  
There is already some discussion in the issue tracker entry linked above.

Your patch checks a VS_DEFAULT_TARGET_PLATFORM_VERSION variable but does not 
document it or explain who/what is supposed to set it.  There is a comment 
about using the latest SDK but right now it looks like the value of that 
variable is used directly.

Having a VS_TARGET_PLATFORM_VERSION target property is convenient for 
customization but should not be the main way to set this value.
The WindowsTargetPlatformVersion value is something that should be set in 
try_compile projects too for consistency.  If we were only cross-compiling then 
having a toolchain file setting would make sense.  However, this should work 
when not cross-compiling too.

On OS X we have CMAKE_OSX_SYSROOT to specify the SDK.  The value is propagated 
by Source/cmCoreTryCompile.cxx into try_compile projects.
It is selected originally by Modules/Platform/Darwin-Initialize.cmake
if not specified by the user.  I think similar infrastructure should be built 
for selecting the Windows SDK.

> As part of this change, I'm also fixing a bug when using VS2015 to 
> target Windows Phone or Windows Store 8.1 without having VS2013
[snip]
> simply to make the desktop detection code be virtual.

Please split the relevant hunks for that part out so they can be committed with 
their own message/explanation.

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

[cmake-developers] PATCH: Add Certificate Thumbprint to VS for Windows Phone and Windows Store projects

[Gilles Khouzam]

I would like to submit a new patch to write the PackageCertificateThumbprint 
tag in VS projects for Windows Phone and Windows Store projects.

When creating a Windows Store project, a certificate is added to the package. 
There is a PackageCertificateThumbprint tag that VS will write when absent that 
contains the thumbprint of the associated certificate. This change tries to 
extract the thumbprint from the specified certificate and add the tag to the 
project when it can be extracted. This enables easier automated builds that do 
not run through the VS GUI.

The change is pretty straightforward, we try to load the specified certificate 
when present and extract the thumbprint using the Windows Crypto APIs and adds 
the tag at the same time as the PackageCertificate . This adds a new dependency 
to crypt32.lib which is available on all versions of Windows starting with 
Windows XP.




CertThumb.patch
Description: CertThumb.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] C# support?

[Gilles Khouzam]

Michael, this is great. Thank you for doing this. I will gladly help with the 
other versions of Visual Studio and can provide some help if you need. Feel 
free to reach out.
 

~Gilles Khouzam

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Stuermer, Michael SP/HZA-ZSEP
Sent: Tuesday, June 30, 2015 00:22
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] C# support?

Hi and thanks for all your answers,

Let me give you some information how things are implemented so far and where my 
constraints in implementing C# support are:

At the moment I have only Visual Studio 2013 available, which makes it hard for 
me to test any other generators. NMake is not a priority for me, but the 
concept of the Visual Studio generators in CMake is so nice implemented, that 
it should not be much of a problem to get this running. I will have a look on 
this once Visual Studio generators are working. I will be able to test some 
linux/mono functionality in VirtualBox, but I will most probably not have much 
time. We are working on Windows based software here and I will not be allowed 
to spent a vast amount of time working on non-project related topics.

In short: it would be great if some people could step forward once everything 
is running from my side to help get makefile and linux support (and test other 
Visual Studio versions).

About enable_language():

Working. From my knowledge it's mainly about have the appropriate cmake-scripts 
in Module directory. That's done, my test project builds well with it. Ok, 
the CMakeTest... script simply sets WORKS to true ... that could be improved 
...

About .csproj files:

It's almost done, the files are generated already and working well. There still 
needs to be some cleaning and generalization to use parameters instead of hard 
coded information.

About intrusiveness:

Almost everything relevant goes in the target generator class 
VisualStudio10TargetGenerator. The necessary .cmake files for the language are 
added and some minor changes to other generator sources are needed (for setting 
target type GUID in .sln etc.). All changes so far are made to be as minimal as 
possible to the original cmake sources and I believe it blends in quite well. 
Credit goes to the guys who implemented the VisualStudio generator concept with 
the flagmaps. You need some time to understand it, but once you've got it it's 
really great.

About C#/.NET:

I'm new to .NET and C# as well, but it seems not to provide too many surprises. 
Nevertheless some challenges remain to come up with a good solution for C# 
integration. It's mainly about reference handling. I have a working example at 
the moment, but it could be improved further.

About the language:

Would it be ok to name the language in CMake CS instead of CSharp? I did 
everything as CS so far...

About contributing:

Once done, do you want patchfiles here on the list or a pull request from my 
fork on github?

---

If someone is interested in the development so far, you can check out my CMake 
fork here (have a look at the csharp branch):

https://github.com/micst/CMake.git

The test project with mixed C++/C# targets, cross-referencing from

C++ -- managed C++ -- C#

can be found here:

https://github.com/micst/CMakeCSharpTest.git


best regards,
Michael


 -Original Message-
 From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On 
 Behalf Of David Cole via cmake-developers
 Sent: Monday, June 29, 2015 7:31 PM
 To: Brad King
 Cc: cmake-developers@cmake.org
 Subject: Re: [cmake-developers] C# support?
 
 The C# compiler, csc.exe, takes all its arguments at once in one call 
 to build a library or executable. Listing all the sources, and its 
 references (other libraries it depends on) all at once. You can do it 
 as command line arguments, or as contents of a response file, or a 
 combination or arguments plus response file.
 
 Conceptually, it's just like Java.
 
 They do have separate project files for it with VS, though. The 
 generators will need code to generate *.csproj files, rather than 
 custom commands in a vcxproj file, to make it seem like it's really 
 well-integrated with VS. Not sure if *.csproj files have evolved much 
 over the last few releases of VS -- I'd expect the major challenge 
 with this to be making sure CMake generates proper *.csproj files for 
 however many versions of VS it would take to make it acceptable.
 
 
 D
 
 
 
 On Mon, Jun 29, 2015 at 1:05 PM, Brad King brad.k...@kitware.com
 wrote:
  On 06/26/2015 10:47 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
  Does it have a realistic chance to be accepted for upstream
 
  Yes, so long as it comes with proper tests and is not too intrusive
 on
  the overall design/implementation of CMake.
 
  In order to enable use of C# sources we should get
 
   enable_language(CSharp)
 
  to work.  This is likely straightforward

Re: [cmake-developers] [PATCH] Adding XAML support to Windows Platform

[Gilles Khouzam]

Looks like we were missing a Visual Studio update on our dashboard machine.

The tests are now passing. 

~Gilles

-Original Message-
From: Gilles Khouzam 
Sent: Thursday, April 2, 2015 09:50
To: 'Brad King'
Cc: cmake-developers@cmake.org
Subject: RE: [cmake-developers] [PATCH] Adding XAML support to Windows Platform

Thanks. Taking a look.


~Gilles

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Thursday, April 2, 2015 06:16
To: Gilles Khouzam
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] Adding XAML support to Windows Platform

On 04/01/2015 03:09 PM, Brad King wrote:
 Thanks.  Applied and merged to 'next' for testing:
 
  VS: Add support for XAML source files 
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfbc299c
 
 I made some minor formatting tweaks, so if you have updates please 
 send patches based on that commit or later.

The test passed for me why I applied the change and also passed on all the 
nightly dashboards that ran it *except* for the ones you run.  Please take a 
look locally.

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

[cmake-developers] [PATCH] Adding XAML support to Windows Platform

[Gilles Khouzam]

I'd like to submit a patch to add support for XAML files to on Windows. This is 
very similar to the RESX support already on the MSVC generator with the .h and 
.cpp implementation files being automatically associated with the .xaml file. 
This would allow WindowsPhone and WindowsStore applications to use the XAML 
programming model as well as DirectX. I've added a new test VSXaml with 
produces a WindowsStore 8.1 app (since the rest of the WindowsStore/Phone is 
already covered in VSWinStorePhone test). By default each Xaml file is treated 
as a Page, but the type can be specified by setting a new property on the 
source file (VS_XAML_TYPE).

I've validated that all tests run successfully with this change.





CMake.Xaml.patch
Description: CMake.Xaml.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] Windows Store generated solution also containing win32 console app?

[Gilles Khouzam]

Hi Robert,

I'm a little confused at how your scenario would work for the ARM architecture? 
If you're building a non-WinRT console app for the solution that needs to run, 
this is fine on x86, but how is that handled on ARM? It would not be built 
(since you can't really run it anyway) and it would not be able to run on the 
build machine since it would be the wrong architecture. If this is to be 
supported long term, it might make more sense to have a new target that is 
based on the build environment and not the target environment.


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Tuesday, February 3, 2015 12:09
To: Gilles Khouzam; Robert Goulet
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Windows Store generated solution also 
containing win32 console app?

On 01/29/2015 06:11 PM, Gilles Khouzam wrote:
 For applications you might not need the VS_WINRT_COMPONENT, but for 
 libraries setting it vs not does have some differences.

Thanks, Gilles.  Robert, I think this means my suggestion of trying to re-use 
VS_WINRT_COMPONENT for this was a bad idea.  Let's return to your original 
suggestion of a separate option.  The proper name for the option may depend on 
the discussion below.  Of course it needs to be an error to enable both the new 
option and VS_WINRT_COMPONENT in the same target.

On 01/27/2015 02:58 PM, Robert Goulet wrote:
 the generator is essentially the same for both Win32 and WinRT

Is this true for only Store, or might all this work for Phone too?

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Fix for Windows Store warning APPX1901: The DefaultLanguage property is either missing from the project file or does not have a value.

[Gilles Khouzam]

Thanks Robert.

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Brad King
Sent: Thursday, January 29, 2015 11:57 AM
To: Robert Goulet
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Fix for Windows Store warning APPX1901: The 
DefaultLanguage property is either missing from the project file or does not 
have a value.

On 01/29/2015 01:45 PM, Robert Goulet wrote:
 Here's a patch to fix a warning
 
 This patch also fix an indentation error in the vcxproj.

Applied, thanks:

 VS: Add missing newlines to .vcxproj generation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c5574a1

 VS: Set default language in generated Windows Phone and Store projects
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=500794b0

-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] Windows Store generated solution also containing win32 console app?

[Gilles Khouzam]

Hi Robert,

For applications you might not need the VS_WINRT_COMPONENT, but for libraries 
setting it vs not does have some differences. The main one being that you 
produce a WinMD file when set. If you look at the new project dialog when 
creating a Windows Store component, you have 2 types DLL  Windows Runtime 
Component, this is what the VS_WINRT_COMPONENT flag defines. By default we want 
to keep the same functionality that we had before and only turn DLLs into WinRT 
components when you explicitely set it.

I've got it on my agenda to update the VSWinStorePhone project to be a little 
more complicated and incorporate multiple simple components which should test 
this functionality a little more.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Thursday, January 29, 2015 2:11 PM
To: Robert Goulet
Cc: cmake-developers@cmake.org; Gilles Khouzam
Subject: Re: [cmake-developers] Windows Store generated solution also 
containing win32 console app?

On 01/29/2015 04:52 PM, Robert Goulet wrote:
 That sounds silly, but how do I merge patches with git?

Read up on interactive rebase: git rebase -i.

 Not setting VS_WINRT_COMPONENT on an executable at all, when system 
 name is 'WindowsStore', will produce an executable with everything 
 properly set as a Windows Store app. I don't use VS_WINRT_COMPONENT 
 (except for my new special case to turn it off explicitly) and 
 everything seems to work properly. Essentially, if you set system name 
 to 'WindowsStore', then all projects are assumed to have the Windows 
 Store Support turned ON in Visual Studio.

Hmm...I'm reconsidering the explicit OFF approach.

Gilles, Tests/VSWinStorePhone/CMakeLists.txt does:

 set_property(TARGET ${EXE_NAME} PROPERTY VS_WINRT_COMPONENT TRUE)

What does this cover?  What does it mean to have this on Store?

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Patch pull request: support for shader entry point and shader model for Visual Studio FXCompiler custom tool build

[Gilles Khouzam]

Hi Cedric

Thanks for the patch,

I had started adding a full set of shader property support on our fork: 

https://cmakems.codeplex.com/SourceControl/changeset/c5f9c207ee3490dda1e4c2a0eb647492b934fc11
 

I haven't asked to get this pulled in because with the number of options, it is 
probably better to add this support as a flag set instead of having a set of 
specific if statements. I haven't had a chance to complete this work though.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Monday, December 1, 2014 07:06
To: Cedric Perthuis
Cc: cmake-developers@cmake.org; Gilles Khouzam
Subject: Re: [cmake-developers] Patch pull request: support for shader entry 
point and shader model for Visual Studio FXCompiler custom tool build

On 11/29/2014 12:51 AM, Cedric Perthuis wrote:
 So, here's a patch to address this. 
[snip]
 +if (const char* se = sf-GetProperty(VS_SHADER_ENTRY_POINT))
[snip]
 +if (const char* sm = sf-GetProperty(VS_SHADER_MODEL))

Thanks.  Here are some comments on the patch:

* Please update the documentation too.  See

   Help/manual/cmake-properties.7.rst
   Help/prop_sf/VS_SHADER_TYPE.rst

  for how VS_SHADER_TYPE is documented.

* Please update the test.  See

   Tests/VSWinStorePhone/CMakeLists.txt

  for current testing of VS_SHADER_TYPE.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Failing CMake WinStorePhone tests

[Gilles Khouzam]

Hi David,

Can you give me some information on your current setup? What build of VS do you 
have installed, which options? I think that the detection logic for the tests 
is missing some cases. I'm guessing that this is similar to what I recently 
fixed in CMake for the express editions, the same detection logic might need to 
be moved over to the test script.

-Original Message-
From: David Cole [mailto:dlrd...@aol.com] 
Sent: Friday, November 14, 2014 10:42
To: Gilles Khouzam
Cc: Brad King; cmake-developers@cmake.org
Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests

I was hoping you'd say that! :-)

On Fri, Nov 14, 2014 at 12:23 PM, Gilles Khouzam gilles.khou...@microsoft.com 
wrote:
 Hi David,

 Let me take a look at what's going on.

 -Original Message-
 From: Brad King [mailto:brad.k...@kitware.com]
 Sent: Friday, November 14, 2014 08:38
 To: David Cole
 Cc: cmake-developers@cmake.org; Gilles Khouzam
 Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests

 On 11/14/2014 11:27 AM, David Cole via cmake-developers wrote:
 Should I expect these tests to pass using Ninja, or is that beyond 
 the scope of the WinStorePhone support...?

 The VS generator is needed for the feature, but the tests that are failing 
 hard-code use of specific Visual Studio generators regardless of the main 
 generator being tested.

 I'll defer to Gilles as for what the problem might be.

 -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] Failing CMake WinStorePhone tests

[Gilles Khouzam]

Hi David,

Let me take a look at what's going on.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Friday, November 14, 2014 08:38
To: David Cole
Cc: cmake-developers@cmake.org; Gilles Khouzam
Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests

On 11/14/2014 11:27 AM, David Cole via cmake-developers wrote:
 Should I expect these tests to pass using Ninja, or is that beyond the 
 scope of the WinStorePhone support...?

The VS generator is needed for the feature, but the tests that are failing 
hard-code use of specific Visual Studio generators regardless of the main 
generator being tested.

I'll defer to Gilles as for what the problem might be.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

[Gilles Khouzam]

Hi Eric,

Can you send me a little more details or an example that exhibits the problem? 
I'd be happy to take a look. 

-Original Message-
From: Eric Wing [mailto:ewmail...@gmail.com] 
Sent: Tuesday, November 4, 2014 15:21
To: Gilles Khouzam
Cc: Brad King; Robert Maynard; CMake Developers; CMake MailingList
Subject: Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready 
for testing!

On 10/31/14, Gilles Khouzam gilles.khou...@microsoft.com wrote:
 We actually have a couple if extra changes that are not fully ready to 
 be pushed upstream yet.

 ~Gilles
 Sent from my Windows Phone


Since I have your attention, using CMakeMS, I hit what looks like a bug in the 
generation for the Windows Phone simulator. I have not tested 3.1.0-rc1, but 
since it is the from the same code base, I'm assuming it is affected too.

I get a linking failure for only the WinPhone simulator (Win32) binary. This is 
the error the linker is spitting out:

vccorlib.lib(compiler.obj) : error LNK2038: mismatch detected for
'vccorlib_lib_should_be_specified_before_msvcrt_lib_to_linker': value '1' 
doesn't match '0' in MSVCRT.lib(appinit.obj)
vccorlib.lib(compiler.obj) : error LNK2005: ___crtWinrtInitType already defined 
in MSVCRT.lib(appinit.obj) D:\snip\Release\FlappyBlurrr.exe : fatal error 
LNK1169: one or more multiply defined symbols found

This only happens for me with the Win32 simulator binary. I do not have this 
problem with the ARM device binary, nor do I have this problem with the Windows 
Store x64 binary. (I do not bother with Win32 Windows Store.)


Somebody helped me and told me to add these switches directly to my Visual 
Studio project:

- for Debug builds, add: /nodefaultlib:vccorlibd /nodefaultlib:msvcrtd 
vccorlibd.lib msvcrtd.lib

- for Release builds, add: /nodefaultlib:vccorlib /nodefaultlib:msvcrt 
vccorlib.lib msvcrt.lib

This seemed to make my linking problems go away.

I'm thinking that CMake should automatically be setting these for me for the 
Windows Phone simulator.

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!

[Gilles Khouzam]

We actually have a couple if extra changes that are not fully ready to be 
pushed upstream yet.

~Gilles
Sent from my Windows Phone

From: Brad Kingmailto:brad.k...@kitware.com
Sent: ‎10/‎31/‎2014 8:26
To: Eric Wingmailto:ewmail...@gmail.com
Cc: Robert Maynardmailto:robert.mayn...@kitware.com; CMake 
Developersmailto:cmake-developers@cmake.org; CMake 
MailingListmailto:cm...@cmake.org; Gilles 
Khouzammailto:gilles.khou...@microsoft.com
Subject: Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready 
for testing!

On 10/30/2014 07:19 PM, Eric Wing wrote:
 Just curious, are the new WinRT changes the same exact changes from CMakeMS?

Yes.  After prototyping the changes in CMakeMS they worked with us
to contribute the functionality upstream.

-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] Windows shader compile options

[Gilles Khouzam]

Hi Christopher,

We added the support for shaders but have only added the basic support to 
include shaders. Let me check what can be done to add the other properties.


Gilles Khouzam
Senior Development Lead
Microsoft OSG

From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Christopher Maughan
Sent: Wednesday, September 24, 2014 05:29
To: cmake-developers@cmake.org
Subject: [cmake-developers] Windows shader compile options

I've been playing with the Windows shader options.  I can see that it's now 
possible to set the following:

set_property(SOURCE ${PIXELSHADER_FILES} PROPERTY VS_SHADER_TYPE Pixel)
set_property(SOURCE ${VERTEXSHADER_FILES} PROPERTY VS_SHADER_TYPE Vertex)

Which is cool, but I can't see if there's a way to specify the other options to 
the shader compiler, such as output header file, shader model, etc.  Is there a 
way to do that, or is it a TODO?
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Patch: Certificate files are not included in Windows Store projects

[Gilles Khouzam]

We do write the proper tag in the VCXProj file for the certificate file, but 
the file is not included in the project itself causing some failures. When I 
moved the certificates into their own category in the GeneratorTarget, the new 
category was never added to the VS10TargetGenerator when the sources get 
written.



Gilles Khouzam
Senior Development Lead
Microsoft OSG



0001-Patch-Add-Certificates-Windows.patch
Description: 0001-Patch-Add-Certificates-Windows.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] [CMake] Fwd: [PATCH] Add support for Metro apps

[Gilles Khouzam]

This is great Paul. I would love nothing more than to combine resources. I'll 
take a look at your branches to understand what you've done. I'd love to see 
all these efforts merged together and be available for the community. 


~Gilles

-Original Message-
From: Paul Annetts [mailto:p...@lightunobscured.com] 
Sent: Tuesday, April 1, 2014 01:13
To: Gilles Khouzam; 'David Cole'; minmin.g...@gmail.com; 
cmake-developers@cmake.org; cm...@cmake.org
Subject: RE: [CMake] Fwd: [PATCH] Add support for Metro apps

Hi Gilles,

I have done some work to extend CMAKE so that it generates projects that 
support the different platforms of Windows Phone (x86/ARM) inside a single SLN  
in exactly this way, and I sent a patch to the dev-list last year. It is 
currently being used on a large scale cross-platform project I am working on.

To David's point it is another full generator (Visual Studio 2012 Windows 
Phone 8) and doesn't rely on toolchain - so at least it is clear what it is 
doing. 

It's been on the back-burner for a bit on my side, as initial support only 
worked for static libraries and I got busy with other things. Since I last 
reported I have managed to extend this to Windows Runtime Component DLLs but I 
have yet to sanitise this for review. This is mainly around getting VS to take 
care of linking automatically, as CMAKE can't track all the combinations of 
binaries in all platform architectures.

I haven't supported Windows Phone C++/DirectX EXE projects.

Minmin: I think the general principles above are extendable to Windows Store 
Apps: i.e. support for X64 should be trivial. Also be aware that there EXE 
project types that are not available to Windows Phone that Windows Store 
supports (e.g. C++/XAML). 

The code is at: https://github.com/paulannetts/CMake
Branches: vs11-multi-platform, windows-phone-8, wp8-runtime-component

Hopefully we can pool resources and come up with a good combined solution!

Paul Annetts.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Gilles Khouzam
Sent: 31 March 2014 19:25
To: David Cole; minmin.g...@gmail.com; cmake-developers@cmake.org; 
cm...@cmake.org
Subject: Re: [CMake] Fwd: [PATCH] Add support for Metro apps

Hi,

I'm new to CMake but am looking to help with this effort. 

I'm wondering if it would make more sense (and if it's possible) to have the 
WinRT flavors as separate platforms within the same solution as you would get 
if you create a new WinRT project in Visual Studio, instead of having 3 
different configurations. 

I'm looking at also adding WinRT support for Windows Phone and I think that 
trying to minimize the generators might make more sense.

~Gilles

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of David Cole
Sent: Monday, March 31, 2014 07:13
To: minmin.g...@gmail.com; cmake-developers@cmake.org; cm...@cmake.org
Subject: Re: [CMake] Fwd: [PATCH] Add support for Metro apps

Thanks for working on this. It will be cool to be able to build Metro apps 
using CMake.

One thing I think is crucial here is to include somewhere an example or test 
project that actually builds a Metro app, and shows how you have to construct 
the CMakeLists for it, and any special considerations needed when running CMake 
to generate the project. Without that, I have no clue where to start on 
evaluating whether these patches are sufficient or not.

Ideally, the example/test will be:
- here, use something like this CMakeLists.txt (and then show one)
- run CMake with the XXX generator
- build as usual

Could you add a test/example somewhere that shows how to use this?


And now, the following is no criticism of your patch, or your attempts to get 
this functionality into CMake,  *but*:

- there are too many ways to cross compile for CMake already, and it would be 
nice if this way was like one of the other ways rather than something entirely 
different.

Right now, CMake already supports:
- true cross-compiling using a makefile based generator and a toolchain file
- building universal binaries on OSX, but not with a toolchain file
- building iOS apps on OSX, but with special variables and properties that need 
setting
- building 32-bit and 64-bit windows apps from the same source tree, but with 
VS generators, using 2 different build trees each with a different generator, 
or with non-VS generators, using 2 different build trees, and different 
environments to define the tools

And now there's this. Which I guess is closest to the VS different generator 
approach.

It would be super awesome if somebody could come up with a coherent way to 
unify all this. (Steve and Eric: hopefully you are considering making the 
Android stuff you're about to work on blend in closely with one of these 
existing models rather than introducing yet another cross-compiling model)

My 2 cents -- again: thanks for your contribution and keep up the good work. 
Overall, CMake is still squarely the best way

Re: [cmake-developers] [CMake] Fwd: [PATCH] Add support for Metro apps

[Gilles Khouzam]

Hi,

I'm new to CMake but am looking to help with this effort. 

I'm wondering if it would make more sense (and if it's possible) to have the 
WinRT flavors as separate platforms within the same solution as you would get 
if you create a new WinRT project in Visual Studio, instead of having 3 
different configurations. 

I'm looking at also adding WinRT support for Windows Phone and I think that 
trying to minimize the generators might make more sense.

~Gilles

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of David Cole
Sent: Monday, March 31, 2014 07:13
To: minmin.g...@gmail.com; cmake-developers@cmake.org; cm...@cmake.org
Subject: Re: [CMake] Fwd: [PATCH] Add support for Metro apps

Thanks for working on this. It will be cool to be able to build Metro apps 
using CMake.

One thing I think is crucial here is to include somewhere an example or test 
project that actually builds a Metro app, and shows how you have to construct 
the CMakeLists for it, and any special considerations needed when running CMake 
to generate the project. Without that, I have no clue where to start on 
evaluating whether these patches are sufficient or not.

Ideally, the example/test will be:
- here, use something like this CMakeLists.txt (and then show one)
- run CMake with the XXX generator
- build as usual

Could you add a test/example somewhere that shows how to use this?


And now, the following is no criticism of your patch, or your attempts to get 
this functionality into CMake,  *but*:

- there are too many ways to cross compile for CMake already, and it would be 
nice if this way was like one of the other ways rather than something entirely 
different.

Right now, CMake already supports:
- true cross-compiling using a makefile based generator and a toolchain file
- building universal binaries on OSX, but not with a toolchain file
- building iOS apps on OSX, but with special variables and properties that need 
setting
- building 32-bit and 64-bit windows apps from the same source tree, but with 
VS generators, using 2 different build trees each with a different generator, 
or with non-VS generators, using 2 different build trees, and different 
environments to define the tools

And now there's this. Which I guess is closest to the VS different generator 
approach.

It would be super awesome if somebody could come up with a coherent way to 
unify all this. (Steve and Eric: hopefully you are considering making the 
Android stuff you're about to work on blend in closely with one of these 
existing models rather than introducing yet another cross-compiling model)

My 2 cents -- again: thanks for your contribution and keep up the good work. 
Overall, CMake is still squarely the best way to build cross-platform C++ based 
projects. And supporting as many platforms as feasible is one of the 
contributing factors that makes it so.


David C.


-Original Message-
From: Minmin Gong minmin.g...@gmail.com
To: cmake-developers cmake-developers@cmake.org; cmake cm...@cmake.org
Sent: Mon, Mar 31, 2014 2:35 am
Subject: [CMake] Fwd:  [PATCH] Add support for Metro apps




Hi cmake developers and users,
This is a extend discussion of this ticket: 
http://www.cmake.org/Bug/view.php?id=13511.



In our project, we need to build an Win8+ Metro app. Currently the CMake do 
support VS_WINRT_EXTENSIONS. However, if you want to build an exe instead of 
dll or lib, even with x86 or x64, it always fails because lacking of some tags 
in vcxproj and sln.



So I made this patch for WinRT/Metro apps, based on the master branch of CMake. 
In this patch, 


1. WinRT-ARM, WinRT-x86, WinRT-x64 generators are added for generating 
WinRT special projects. CMAKE_VS_WINRT_VERSION is defined inside.


2. Add AppContainerApplication, ApplicationType, 
MinimumVisualStudioVersion and ApplicationTypeRevision tags to vcxproj 
in WinRT project.
3. Recognize AppxManifest file type.
4. A dedicated boolean source file property VS_WINRT_CONTENT is 
added. Generator expressions is also supported here.
5. Add Deploy.0 in .sln for deploy WinRT apps by default, as WinCE 
apps do.
6. Add PackageCertificateKeyFile tag to vcxproj for package 
certification.


Thanks for advices from Martell Malone, Daniel Pfeifer, Brad King, 
Patrick R. Gansterer, and other developers and users of CMake. More 
comments are welcomed.




--
Minmin Gong

--

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: