Re: [CMake] CMake doesn't detect Microsoft Build Tools 2015 on Windows 10

[Gilles Khouzam via CMake]

Please open a bug, I can take a look at it.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Eduard Wirch
Sent: Monday, October 10, 2016 02:41
To: cmake@cmake.org
Subject: [CMake] CMake doesn't detect Microsoft Build Tools 2015 on Windows 10

Hi

I've installed build tools from here: 
http://landinghub.visualstudio.com/visual-cpp-build-tools
But CMake will automatically detect (and choose) Visual Studio 8 (installed 
here as well) instead.

Looking into the source:

const std::string vsregBase =
  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\";
std::vector vsVerions;
vsVerions.push_back("VisualStudio\\");
vsVerions.push_back("VCExpress\\");
vsVerions.push_back("WDExpress\\");
struct VSRegistryEntryName
{
  const char* MSVersion;
  const char* GeneratorName;
};
VSRegistryEntryName version[] = {
  /* clang-format needs this comment to break after the opening brace */
  { "7.1", "Visual Studio 7 .NET 2003" },
  { "8.0", "Visual Studio 8 2005" },
  { "9.0", "Visual Studio 9 2008" },
  { "10.0", "Visual Studio 10 2010" },
  { "11.0", "Visual Studio 11 2012" },
  { "12.0", "Visual Studio 12 2013" },
  { "14.0", "Visual Studio 14 2015" },
  { "15.0", "Visual Studio 15" },
  { 0, 0 }
};
for (int i = 0; version[i].MSVersion != 0; i++) {
  for (size_t b = 0; b < vsVerions.size(); b++) {
std::string reg = vsregBase + vsVerions[b] + version[i].MSVersion;
reg += ";InstallDir]";
cmSystemTools::ExpandRegistryValues(reg, cmSystemTools::KeyWOW64_32);
if (!(reg == "/registry")) {
  installedCompiler = version[i].GeneratorName;
  break;
}
  }
}

CMake will look for 
'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\InstallDir'. This key is 
not present indeed. When specified explicitly:
cmake . -G "Visual Studio 14 2015"
CMake will correctly detect the compiler and build without problems.

These keys might be helpful when looking for Build Tools:


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\VC]
"ProductDir"="C:\\Program Files (x86)\\Microsoft Visual 
Studio 14.0\\VC\\"


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\SSDT]
"InstallDir"="C:\\Program Files (x86)\\Microsoft Visual 
Studio 14.0\\"
"VersionNumber"="14.0.50616.0"

Am I missing something or is this a bug which should be reported to issue 
tracker?

Cheers,
Eduard
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] 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] [cmake-developers] Problems with icons for Windows Store 10.0

[Gilles Khouzam via CMake]

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-develop...@cmake.org>; CMake MailingList <cmake@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-develop...@cmake.org>; CMake 
> MailingList <cmake@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

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

[Gilles Khouzam via CMake]

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-develop...@cmake.org>; CMake MailingList 
<cmake@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

Re: [CMake] Visual Studios platform choice

[Gilles Khouzam via CMake]

When Visual Studio creates a project, by default it will create it for multiple 
architectures. When running through CMake, only 1 platform is generated. 
Therefore Visual Studio shows the platform options but only the available 
platforms are shown. We wrote a prototype to support creating multiple 
platforms for Windows Store apps in CMake a while back that’s available on 
https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform but hasn’t been 
updated in some time. There are issues with it as some things don’t port well 
when switching architectures.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Dvir Yitzchaki
Sent: Thursday, September 8, 2016 01:21
To: 'Jack Stalnaker' ; cmake@cmake.org
Subject: Re: [CMake] Visual Studios platform choice

We’re generating both 32 bit and 64 bit solutions and the drop down only shows 
one architecture on each solution.
Checked on VS 2013 and 2015.

Regards,

Dvir Yitzchaki
Debugger Software Engineer, SDT
[cid:image001.png@01D209C3.2089CC20][cid:image002.png@01D209C3.2089CC20]
 [https://g.twimg.com/twitter-bird-16x16.png]   
[http://img2.wikia.nocookie.net/__cb20100109182754/half-life/en/images/e/ec/YouTube_favicon.png]
   
[http://developer.linkedin.com/sites/default/files/LinkedIn_Logo16px.png] 


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Jack Stalnaker
Sent: Wednesday, September 07, 2016 7:31 PM
To: cmake@cmake.org
Subject: [CMake] Visual Studios platform choice

Hi,

I understand from reading this newgroup (e.g. 
https://cmake.org/pipermail/cmake/2013-March/053775.html) that the only way to 
support multiple platforms in Visual Studio is to run CMake multiple times, 
once for each platform.

I'm porting some linux based code to the Windows world, and the Windows dev 
showed me that in Visual Studio, platform choice is a pulldown menu at the top 
of the screen. This pulldown appears even if we run CMake without specifying a 
64 bit platform. This is a bit confusing, because we've only generated a 
solution and project file for 32 bit. So what happens when someone selects 64 
bit on the pulldown menu? What's being built?

Thanks
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Windows path too long

[Gilles Khouzam via CMake]

It’s a little more complicated than just saying Windows 10 and turning on a 
regkey. There are other changes that need to be enabled in order to get the 
whole scenario working. The main one being that MSBuild needs to be updated and 
manifested to be able to use paths longer than 260 characters. Even if the 
files were created properly, they couldn’t be read or written without the tool 
that was using them being updated.

Many pieces of the system have assumptions on the 260 character limit and they 
all need to be moved forward for this to work properly. This will be a staged 
migration.

Thanks

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of mike lojkovic
Sent: Thursday, September 8, 2016 06:58
To: Cmake@cmake.org
Subject: Re: [CMake] Windows path too long


Can you change to windows 10? If you are on 10, you can turn the restriction 
off. Otherwise, I believe there's complicated ways to shorten the path.

http://m.slashdot.org/story/311861

On Sep 7, 2016 8:07 AM, "David Cole via CMake" 
> wrote:
I suppose the obvious "use shorter paths and names" is not possible or hard to 
enforce?


David


> On Sep 7, 2016, at 2:55 AM, Robert Bielik 
> > wrote:
>
> I have a problem with a VS 2015 project, where the build state path becomes 
> too long:
>
> SeverityCodeDescriptionProjectFileLineSuppression 
> State
> ErrorMSB3491Could not write lines to file 
> "processor_withAVeryVeryLongName.dir\Release\processo.92BD73FC.tlog\processor_withAVeryVeryLongName.lastbuildstate".
>  The specified path, file name, or both are too long. The fully qualified 
> file name must be less than 260 characters, and the directory name must be 
> less than 248 characters.processor_withAVeryVeryLongNameC:\Program 
> Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets312
>
> The line in Microsoft.CppBuild.targets is:
>
>  Lines="$(ProjectStateLine);$(ProjectEvaluationFingerprint)"/>
>
> I've set CMAKE_OBJECT_PATH_MAX to 240, but I don't think it will affect 
> this...
>
> Ideas ?
>
> This is with CMake 3.5.2.
>
> Regards
> /Robert
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

--

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Bash on ubuntu on windows as target

[Gilles Khouzam via CMake]

I’ve looked more in depth at the issue, and while this doesn’t work yet, we’re 
looking to enable this in a future Windows Insider Flight for better 
windows/linux interop.

From: Gilles Khouzam
Sent: Monday, August 15, 2016 13:24
To: 'Tiago Macarios' <tiagomacar...@gmail.com>; csiga.b...@aol.com
Cc: CMake ML <cmake@cmake.org>
Subject: RE: [CMake] Bash on ubuntu on windows as target

That’s an interesting idea,

I’m not sure why cmd is failing to invoke bash properly, but I will try and 
figure it out.

Also, for addressing invoking bash.exe without copying it to SysWow64, you can 
reference it by C:\Windows\Sysnative\bash.exe from a 32-bit process. It still 
doesn’t make the target succeed, but at least it removes the need to copy the 
file around.

Thanks
~Gilles


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Tiago Macarios
Sent: Thursday, August 11, 2016 10:12
To: csiga.b...@aol.com<mailto:csiga.b...@aol.com>
Cc: CMake ML <cmake@cmake.org<mailto:cmake@cmake.org>>
Subject: Re: [CMake] Bash on ubuntu on windows as target

Well what I was trying to do was to actually have a target inside the windows 
build that would trigger the linux build so to build both at the same time. 
imagine you have a VS project one of the "projects" would be the linux build. 
So as long as the build folder is different I could have both building in sync 
everytime. Get the idea?

If I just do a full build inside bash everything works great =)

On Wed, Aug 10, 2016 at 11:23 PM, <"Máté Ferenc Nagy-Egri via CMake 
<cmake@cmake"@public.kitware.com<mailto:%22Máté%20Ferenc%20Nagy-Egri%20via%20CMake%20%3ccmake@cmake...@public.kitware.com>>
 wrote:
+1 for the initiative. Wouldn’t it make more sense however to make it a 
CMAKE_SYSTEM_NAME? If I remember correctly that’s how MinGW works, and this 
should be something very similar.


Feladó: Tiago Macarios<mailto:tiagomacar...@gmail.com>
Elküldve: 2016. augusztus 11., csütörtök 1:51
Címzett: CMake ML<mailto:cmake@cmake.org>
Tárgy: [CMake] Bash on ubuntu on windows as target

Hi All,

Windows 10 anniversary edition comes with support to execute Linux binaries. I 
have been trying to use it with one of our projects, but I have been getting a 
weird error. Maybe someone can help me?

The target is pretty simple:

set(BASH "C:\\Windows\\System32\\bash.exe")
set(ARGS "--help")
add_custom_target(linux ${BASH} ${ARGS})

If I then build that project in visual studio (with some extra verbosity) I get:

Target "CustomBuild" in file "C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from project 
"C:\_Working\delegate\build\linux.vcxproj" (target 
"_BuildGenerateSourcesAction" depends on it):
Using "CustomBuild" task from assembly "C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.CppTasks.Common.dll".
Task "CustomBuild"
  Write Tracking Logs:
   x64\Debug\linux\linux.tlog\custombuild.write.1.tlog
  Read Tracking Logs:
   x64\Debug\linux\linux.tlog\custombuild.read.1.tlog
  No output for 
C:\_WORKING\DELEGATE\BUILD\CMAKEFILES\3FA5525E877A7559336C7D412E1B43B0\LINUX.RULE|C:\_WORKING\DELEGATE\CMAKELISTS.TXT
 was found in the tracking log; source compilation required.
  C:\_Working\delegate\CMakeLists.txt will be compiled as it was not found in 
the tracking log.
  
C:\_Working\delegate\build\CMakeFiles\3fa5525e877a7559336c7d412e1b43b0\linux.rule
 will be compiled as it was not found in the tracking log.
  setlocal
  "C:\Program Files (x86)\CMake\bin\cmake.exe" -HC:/_Working/delegate 
-BC:/_Working/delegate/build --check-stamp-file 
C:\_Working\delegate\build\CMakeFiles\generate.stamp
  if %errorlevel% neq 0 goto :cmEnd
  :cmEnd
  endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
  :cmErrorLevel
  exit /b %1
  :cmDone
  if %errorlevel% neq 0 goto :VCEnd
  setlocal
  C:\Windows\System32\bash.exe --help
  if %errorlevel% neq 0 goto :cmEnd
  :cmEnd
  endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
  :cmErrorLevel
  exit /b %1
  :cmDone
  if %errorlevel% neq 0 goto :VCEnd
  Building Custom Rule C:/_Working/delegate/CMakeLists.txt
  CMake does not need to re-run because 
C:\_Working\delegate\build\CMakeFiles\generate.stamp is up-to-date.
C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error 
MSB6006: "cmd.exe" exited with code -1073740791.
Done executing task "CustomBuild" -- FAILED.
Done building target "CustomBuild" in project "linux.vcxproj" -- FAILED.


The command line seems correct. If I just copy it to the windows prompt it 
works fine:

C:\Users\tmc>  C:\Windows\System32\bash.exe --help
GNU bash, version 4.3.11(1)-release-(x86_64-pc-linux-gnu)
Usage:  /bin/bash [GNU long option] [option] ...
/bin/bash [GNU long opti

Re: [CMake] Bash on ubuntu on windows as target

[Gilles Khouzam via CMake]

That’s an interesting idea,

I’m not sure why cmd is failing to invoke bash properly, but I will try and 
figure it out.

Also, for addressing invoking bash.exe without copying it to SysWow64, you can 
reference it by C:\Windows\Sysnative\bash.exe from a 32-bit process. It still 
doesn’t make the target succeed, but at least it removes the need to copy the 
file around.

Thanks
~Gilles


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Tiago Macarios
Sent: Thursday, August 11, 2016 10:12
To: csiga.b...@aol.com
Cc: CMake ML 
Subject: Re: [CMake] Bash on ubuntu on windows as target

Well what I was trying to do was to actually have a target inside the windows 
build that would trigger the linux build so to build both at the same time. 
imagine you have a VS project one of the "projects" would be the linux build. 
So as long as the build folder is different I could have both building in sync 
everytime. Get the idea?

If I just do a full build inside bash everything works great =)

On Wed, Aug 10, 2016 at 11:23 PM, <"Máté Ferenc Nagy-Egri via CMake 
>
 wrote:
+1 for the initiative. Wouldn’t it make more sense however to make it a 
CMAKE_SYSTEM_NAME? If I remember correctly that’s how MinGW works, and this 
should be something very similar.


Feladó: Tiago Macarios
Elküldve: 2016. augusztus 11., csütörtök 1:51
Címzett: CMake ML
Tárgy: [CMake] Bash on ubuntu on windows as target

Hi All,

Windows 10 anniversary edition comes with support to execute Linux binaries. I 
have been trying to use it with one of our projects, but I have been getting a 
weird error. Maybe someone can help me?

The target is pretty simple:

set(BASH "C:\\Windows\\System32\\bash.exe")
set(ARGS "--help")
add_custom_target(linux ${BASH} ${ARGS})

If I then build that project in visual studio (with some extra verbosity) I get:

Target "CustomBuild" in file "C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from project 
"C:\_Working\delegate\build\linux.vcxproj" (target 
"_BuildGenerateSourcesAction" depends on it):
Using "CustomBuild" task from assembly "C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.CppTasks.Common.dll".
Task "CustomBuild"
  Write Tracking Logs:
   x64\Debug\linux\linux.tlog\custombuild.write.1.tlog
  Read Tracking Logs:
   x64\Debug\linux\linux.tlog\custombuild.read.1.tlog
  No output for 
C:\_WORKING\DELEGATE\BUILD\CMAKEFILES\3FA5525E877A7559336C7D412E1B43B0\LINUX.RULE|C:\_WORKING\DELEGATE\CMAKELISTS.TXT
 was found in the tracking log; source compilation required.
  C:\_Working\delegate\CMakeLists.txt will be compiled as it was not found in 
the tracking log.
  
C:\_Working\delegate\build\CMakeFiles\3fa5525e877a7559336c7d412e1b43b0\linux.rule
 will be compiled as it was not found in the tracking log.
  setlocal
  "C:\Program Files (x86)\CMake\bin\cmake.exe" -HC:/_Working/delegate 
-BC:/_Working/delegate/build --check-stamp-file 
C:\_Working\delegate\build\CMakeFiles\generate.stamp
  if %errorlevel% neq 0 goto :cmEnd
  :cmEnd
  endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
  :cmErrorLevel
  exit /b %1
  :cmDone
  if %errorlevel% neq 0 goto :VCEnd
  setlocal
  C:\Windows\System32\bash.exe --help
  if %errorlevel% neq 0 goto :cmEnd
  :cmEnd
  endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
  :cmErrorLevel
  exit /b %1
  :cmDone
  if %errorlevel% neq 0 goto :VCEnd
  Building Custom Rule C:/_Working/delegate/CMakeLists.txt
  CMake does not need to re-run because 
C:\_Working\delegate\build\CMakeFiles\generate.stamp is up-to-date.
C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error 
MSB6006: "cmd.exe" exited with code -1073740791.
Done executing task "CustomBuild" -- FAILED.
Done building target "CustomBuild" in project "linux.vcxproj" -- FAILED.


The command line seems correct. If I just copy it to the windows prompt it 
works fine:

C:\Users\tmc>  C:\Windows\System32\bash.exe --help
GNU bash, version 4.3.11(1)-release-(x86_64-pc-linux-gnu)
Usage:  /bin/bash [GNU long option] [option] ...
/bin/bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
Type `/bin/bash -c "help set"' for more information about shell options.
Type `/bin/bash -c help' for more information about shell builtin commands.
Use the `bashbug' command to report bugs.


I also tried to use it 

Re: [CMake] [Visual Studio] Universal Windows Platform projects

[Gilles Khouzam via CMake]

Hi Adam, Nagy-Egri

I’ve written most of the code to support Windows Universal Apps and would be 
happy to help you get this working. We have some very prominent customers who 
are using this functionality to publish their apps and games to the Windows 
Store. The support is not a pilot project and we try to address the issues that 
people are facing when something is not fully supported.

The first example to look at would be in Tests\VSWinStorePhone, this is the 
validation project that builds a Windows project that can be targeted to the 
Windows Store. It has examples of content files, shaders, manifest, resources, 
tool overrides.

If you have questions, I’m here to help.

Thanks

Gilles Khouzam
Engineering Lead
Microsoft Windows
gilles.khou...@microsoft.com<mailto:gilles.khou...@microsoft.com>


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nagy-Egri Máté Ferenc 
via CMake
Sent: Tuesday, August 2, 2016 01:17
To: cmake@cmake.org
Subject: Re: [CMake] [Visual Studio] Universal Windows Platform projects

I would also very much like to see a tutorial on this. There are just too darn 
many options to set for me to believe CMake could ever get the job done. 
Release notes for Publishing to the store, age rating for my app, can it 
correctly set source types to be DX resources, DX shaders, etc… there are too 
many things I have not even heard about relating to CMake.

I have a feeling that the WindowsStore CMAKE_SYSTEM_NAME started out as a pilot 
project but then did not wish to keep up with the evolution of the Microsoft 
ecosystem. It’s a shame really, because I really did want to prove to collegues 
of mine, that the MVVM model employed by the canonical design pattern of 
Windows Store apps has a 1-to-1 mapping in the Qt ecosystem.

XAML >> QML
events-delegates >> signal-slot

The best choice of a build generator would be CMake. However, not having met 
all the neccessary components, VS project files with the Qt Add-In currently 
seem to be a better choice.

The foundations are very-very similar and I wanted to build a simple 
application that relies on Qt for the Linux build and pure WinRT for the 
Windows build. Also, I would also be very much interested in additions to CMake 
where CTest could take care of Pester tests for PowerShell scripts and as such 
is able to test PS scripts I wrote which load C++/CX Assemblies. (For those who 
do not know of C++/CX, it is managed C++, a language extension that can act as 
a mediator between native C++ and all the .NET family of languages. One may 
wrap FFTW with managed C++ and load the compiled library (referred to as 
Assemblies) from C#, F# or PowerShell even and consume it. The ABI of the .NET 
languages are stable and interoperable.)


If someone has a working prototype of CMake compiling a simple UWP Store app 
that could actually be published… do not hesitate to share!



Feladó: Adam Rankin<mailto:aran...@robarts.ca>
Elküldve: 2016. július 6., szerda 16:42
Címzett: cmake@cmake.org<mailto:cmake@cmake.org>
Tárgy: [CMake] [Visual Studio] Universal Windows Platform projects

Hello all,

I’ve been trying to identify the correct variables to set to create a UWP 
project using VS2015, and the projects generated are missing a few critical 
tags.

I’m using CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0. This 
correctly identifies and sets the target platform tag, but does not set the 
following ‘Globals’ Properties in the PropertyGroup of the .vcxproj file

true
Windows Store
10.0.10240.0
10.0

Has anyone successfully created a UWP project using CMake?

Regards,
Adam

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Patch: 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] Is there any ongoing work to support toolset Clang 3.7 with Microsoft CodeGen (v140_clang_3_7)

[Gilles Khouzam]

Yes, support has been added to the nightly builds. Mariusz has added support 
for this.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of 
foru...@smartmobili.com
Sent: Friday, April 1, 2016 03:16
To: CMake ML 
Subject: [CMake] Is there any ongoing work to support toolset Clang 3.7 with 
Microsoft CodeGen (v140_clang_3_7)

Hi,

Microsoft has released a new toolset using clang for the code analysis and with 
VS2015 code generator.

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fblogs.msdn.microsoft.com%2fvcblog%2f2015%2f12%2f04%2fclang-with-microsoft-codegen-in-vs-2015-update-1%2f=01%7c01%7cgilles.khouzam%40microsoft.com%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=pG0Tv%2fvB9Qjmmq9aEb82DM%2bSBDwJlzy4A2jLVaZ%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fblogs.msdn.microsoft.com%2fvcblog%2f2016%2f01%2f20%2fclang-with-microsoft-codegen-january-2016-released%2f=01%7c01%7cgilles.khouzam%40microsoft.com%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=9QSxh%2byHPkdB%2f8Ol6wDSWum3FOdoQ435OxhSy3OKgrQ%3d

IS there any ongoing work to support the v140_clang_3_7 for VS2015 ?
Something like:

> cmake -G "Visual Studio 14 2015" -T v140_clang_3_7

For the moment if I want to test I have to use the VS2015 generator and then 
manually change the Platform Toolset and warnings level


Thanks

-- 

Powered by 
https://na01.safelinks.protection.outlook.com/?url=www.kitware.com=01%7c01%7cgilles.khouzam%40microsoft.com%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=G%2fForWqFnK6XXeeF3vjeXa79YHIUSYws0CePiG5ItFQ%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%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=xrhX%2bbBpZxVQVAdv8iFCPFavIPfIPQcrANkav5wO%2bnY%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%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=2ob5oRjXSxdeHTP2SuA6ZAny0E30TH39gNr0gWNVLT0%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%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=cz13%2bFeBXYuzEwIo7EssNynhGTT3YopW1p9txFe684g%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%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=6ebJasb%2fjhGk3YD7u86BkS%2fV%2frjj9V1bljHHLHWYfdM%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%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=99k6IYFVxiJdsEViMOj9ML5BTaPkMBnFqsdLJTEKbcs%3d

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fpublic.kitware.com%2fmailman%2flistinfo%2fcmake=01%7c01%7cgilles.khouzam%40microsoft.com%7c7703c2a8b7cb4a2db79b08d35a17a4c0%7c72f988bf86f141af91ab2d7cd011db47%7c1=uzH5ImTCdJ7DHdLQ3bGF82wF%2bBXf2RwHSBH6w6osnUY%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

Re: [CMake] can't generate WindowsPhone 8.1 projects

[Gilles Khouzam]

If you only have VS2015, then this behavior is normal. When you install the 
Windows Phone 8.1 SDK, it will have the VS 2013 toolset for those projects, but 
not the full compiler toolset.

So is this currently working? Are you having trouble on one particular machine?

Thanks
~Gilles

From: Aaron Simmons [mailto:asimm...@sensoryinc.com]
Sent: Tuesday, March 15, 2016 16:50
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: cmake@cmake.org
Subject: Re: [CMake] can't generate WindowsPhone 8.1 projects

I'm using CMake 3.5.0 on Windows 10.  To simplify things, I started from a 
fresh Windows 10 image and installed Visual Studio 2015.

When I try your suggestion to use the 2013 generator, I get
cmake .. -G "Visual Studio 12 2013 ARM" -DCMAKE_SYSTEM_NAME=WindowsPhone 
-DCMAKE_SYSTEM_VERSION=8.1
CMake Error at CMakeLists.txt:2 (project):
  A Windows Phone component with CMake requires both the Windows Desktop SDK
  as well as the Windows Phone '8.1' SDK.  Please make sure that you have
  both installed

When I try it with the 2015 generator, I get
cmake .. -G "Visual Studio 14 2015 ARM" -DCMAKE_SYSTEM_NAME=WindowsPhone 
-DCMAKE_SYSTEM_VERSION=8.1
-- The C compiler identification is MSVC 18.0.31010.0
-- The CXX compiler identification is MSVC 18.0.31010.0
-- Check for working C compiler using: Visual Studio 14 2015 ARM
-- Check for working C compiler using: Visual Studio 14 2015 ARM -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 14 2015 ARM
-- Check for working CXX compiler using: Visual Studio 14 2015 ARM -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMAKE_C_COMPILER C:/Program Files (x86)/Microsoft Visual Studio 
12.0/VC/bin/x86_arm/cl.exe
CMAKE_CXX_COMPILER C:/Program Files (x86)/Microsoft Visual Studio 
12.0/VC/bin/x86_arm/cl.exe
-- Configuring done
-- Generating done


How odd-- it can't generate with 2013, but when it generates with 2015 it uses 
the 2013 compiler.



Aaron Simmons
Application Software Engineer at Sensory, Inc

On Mon, Mar 14, 2016 at 2:40 PM, Gilles Khouzam 
<gilles.khou...@microsoft.com<mailto:gilles.khou...@microsoft.com>> wrote:
Hi Aaron

What happens if you sent the compiler to Visual Studio 12 2013 ARM?

I’ll try this on my side and see if I can repro.

Which version of CMake are you running?

Thanks
~Gilles

From: CMake [mailto:cmake-boun...@cmake.org<mailto:cmake-boun...@cmake.org>] On 
Behalf Of Aaron Simmons via CMake
Sent: Monday, March 14, 2016 10:34
To: cmake@cmake.org<mailto:cmake@cmake.org>
Subject: Re: [CMake] can't generate WindowsPhone 8.1 projects

I looked at the CMAKE_C_COMPILER for WindowsStore/10.0, and its printing
   C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_arm/cl.exe
which is correct!

So I think the problem is that for WindowsPhone CMake is looking up the Visual 
Studio version incorrectly.


Aaron Simmons
Application Software Engineer at Sensory, Inc

On Mon, Mar 14, 2016 at 11:30 AM, Aaron Simmons 
<asimm...@sensoryinc.com<mailto:asimm...@sensoryinc.com>> wrote:
In the successful case, I printed out CMAKE_C_COMPILER and found that its 
pointing to
   C:/Program Files (x86)/Microsoft Visual Studio 
11.0/VC/WPSDK/WP80/bin/x86_arm/cl.exe
even though I'm using the generator for "Visual Studio 14 2015 ARM".

I think its not working because there isn't a WindowsPhone/8.1 compiler in that 
old Visual Studio.  (I'm unsure as to why WindowsStore/10.0 works.)

I have Visual Studio 11, 12, and 14 on my system.  How can I tell CMake to use 
the right one?


Aaron Simmons
Application Software Engineer at Sensory, Inc

On Mon, Mar 14, 2016 at 11:11 AM, Aaron Simmons 
<asimm...@sensoryinc.com<mailto:asimm...@sensoryinc.com>> wrote:
With this CMakeLists.txt:
   cmake_minimum_required(VERSION 3.5.0)
   project(TestLib)
and this command:
   cmake .. -G "Visual Studio 14 2015 ARM" -DCMAKE_SYSTEM_NAME=WindowsPhone 
-DCMAKE_SYSTEM_VERSION=8.1
I get this output:
   -- The C compiler identification is unknown
   -- The CXX compiler identification is unknown
   CMake Error at CMakeLists.txt:2 (project):
 No CMAKE_C_COMPILER could be found.

   CMake Error at CMakeLists.txt:2 (project):
 No CMAKE_CXX_COMPILER could be found.

Oddly, using WindowsPhone/8.0 or WindowsStore/10.0 works.  I'm not sure how to 
debug this problem.  Any pointers?



Thanks,
aaron



-- 

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

Re: [CMake] can't generate WindowsPhone 8.1 projects

[Gilles Khouzam]

Hi Aaron

What happens if you sent the compiler to Visual Studio 12 2013 ARM?

I’ll try this on my side and see if I can repro.

Which version of CMake are you running?

Thanks
~Gilles

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Aaron Simmons via 
CMake
Sent: Monday, March 14, 2016 10:34
To: cmake@cmake.org
Subject: Re: [CMake] can't generate WindowsPhone 8.1 projects

I looked at the CMAKE_C_COMPILER for WindowsStore/10.0, and its printing
   C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_arm/cl.exe
which is correct!

So I think the problem is that for WindowsPhone CMake is looking up the Visual 
Studio version incorrectly.


Aaron Simmons
Application Software Engineer at Sensory, Inc

On Mon, Mar 14, 2016 at 11:30 AM, Aaron Simmons 
> wrote:
In the successful case, I printed out CMAKE_C_COMPILER and found that its 
pointing to
   C:/Program Files (x86)/Microsoft Visual Studio 
11.0/VC/WPSDK/WP80/bin/x86_arm/cl.exe
even though I'm using the generator for "Visual Studio 14 2015 ARM".

I think its not working because there isn't a WindowsPhone/8.1 compiler in that 
old Visual Studio.  (I'm unsure as to why WindowsStore/10.0 works.)

I have Visual Studio 11, 12, and 14 on my system.  How can I tell CMake to use 
the right one?


Aaron Simmons
Application Software Engineer at Sensory, Inc

On Mon, Mar 14, 2016 at 11:11 AM, Aaron Simmons 
> wrote:
With this CMakeLists.txt:
   cmake_minimum_required(VERSION 3.5.0)
   project(TestLib)
and this command:
   cmake .. -G "Visual Studio 14 2015 ARM" -DCMAKE_SYSTEM_NAME=WindowsPhone 
-DCMAKE_SYSTEM_VERSION=8.1
I get this output:
   -- The C compiler identification is unknown
   -- The CXX compiler identification is unknown
   CMake Error at CMakeLists.txt:2 (project):
 No CMAKE_C_COMPILER could be found.

   CMake Error at CMakeLists.txt:2 (project):
 No CMAKE_CXX_COMPILER could be found.

Oddly, using WindowsPhone/8.0 or WindowsStore/10.0 works.  I'm not sure how to 
debug this problem.  Any pointers?



Thanks,
aaron


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] 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

Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

[Gilles Khouzam]

Hi Yi-Hong,

I think that this is an issue that was recently fix in CMake which is not in 
our fork. I’ll look at pulling in this change in our branch.

From: Yi-Hong Lyu [mailto:b95705...@ntu.edu.tw]
Sent: Wednesday, February 3, 2016 11:46
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: Nicholas Braden <nicholas11bra...@gmail.com>; cmake@cmake.org
Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hello Gilles,

Here it is:

PS > cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 -DLLVM_PATH="E:\\llvm" 
-DCMAKE_SYSTEM_VERSION=8.1  
-DCMAKE_C_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" 
-DCMAKE_CXX_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" ..\src\
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
-- Check for working CXX compiler using: Visual Studio 14 2015
-- Check for working CXX compiler using: Visual Studio 14 2015 -- broken
CMake Error at E:/CMake/clang_3_7/Modules/CMakeTestCXXCompiler.cmake:54 
(message):
  The C++ compiler "E:\e2tools\ext-tools\llvm\clang-cl.exe" is not able to
  compile a simple test program.

  It fails with the following output:

   Change Dir: E:/libcxx/b-libcxx-Cascade-msbuild2/CMakeFiles/CMakeTmp

  Run Build Command:"C:/Program Files (x86)/MSBuild/14.0/bin/MSBuild.exe"
  "cmTC_00a23.vcxproj" "/p:Configuration=Debug" "/p:VisualStudioVersion=14.0"

  Microsoft (R) Build Engine version 14.0.24720.0

  C:\Program Files
  (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5):
  error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset =
  'v140_clang_3_7') cannot be found.  To build using the v140_clang_3_7 build
  tools, please install v140_clang_3_7 build tools.  Alternatively, you may
  upgrade to the current Visual Studio tools by selecting the Project menu or
  right-click the solution, and then selecting "Retarget solution".
  [E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5): 
error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset = 
'v140_clang_3_7') cannot be found. To build using the v140_clang_3_7 build 
tools, please install v140_clang_3_7 build tools.  Alternatively, you may 
upgrade to the current Visual Studio tools by selecting the Project menu or 
right-click the solution, and then selecting "Retarget solution". 
[E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

  0 warning
  1 error

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:17 (project)

-- Configuring incomplete, errors occurred!

PS. Part of the messages in Chinese are removed, please tell me if you need it 
as well

Thanks for your help,
Yi-Hong

2016-02-04 3:25 GMT+08:00 Gilles Khouzam 
<gilles.khou...@microsoft.com<mailto:gilles.khou...@microsoft.com>>:
Hi Yi-Hong,

Can you try to add the following: -DCMAKE_SYSTEM_VERSION=8.1 to your parameters?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

[Gilles Khouzam]

Hi Yi-Hong,

I’ve updated our branch to include the fix to not require the Windows 10 SDK. 
But I think that I misunderstood what you had meant by Clang-CL.

The support I added was for Clang with the Microsoft CodeGen engine which is 
included in Visual Studio 2015 Update 1, what’s where the v140_clang_3_7 is 
specified.

You can try the LLVM-vs2013 toolset and that might work (looking at 
http://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf). Can you create a 
sample project in VS and look at the toolset selection and select the one you 
want and specify that as the toolset for CMake?

From: Gilles Khouzam
Sent: Wednesday, February 3, 2016 14:17
To: 'Yi-Hong Lyu' <b95705...@ntu.edu.tw>
Cc: Nicholas Braden <nicholas11bra...@gmail.com>; cmake@cmake.org
Subject: RE: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hi Yi-Hong,

I think that this is an issue that was recently fix in CMake which is not in 
our fork. I’ll look at pulling in this change in our branch.

From: Yi-Hong Lyu [mailto:b95705...@ntu.edu.tw]
Sent: Wednesday, February 3, 2016 11:46
To: Gilles Khouzam 
<gilles.khou...@microsoft.com<mailto:gilles.khou...@microsoft.com>>
Cc: Nicholas Braden 
<nicholas11bra...@gmail.com<mailto:nicholas11bra...@gmail.com>>; 
cmake@cmake.org<mailto:cmake@cmake.org>
Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hello Gilles,

Here it is:

PS > cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 -DLLVM_PATH="E:\\llvm" 
-DCMAKE_SYSTEM_VERSION=8.1  
-DCMAKE_C_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" 
-DCMAKE_CXX_COMPILER="E:\\e2tools\\ext-tools\\llvm\\clang-cl.exe" ..\src\
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
-- Check for working CXX compiler using: Visual Studio 14 2015
-- Check for working CXX compiler using: Visual Studio 14 2015 -- broken
CMake Error at E:/CMake/clang_3_7/Modules/CMakeTestCXXCompiler.cmake:54 
(message):
  The C++ compiler "E:\e2tools\ext-tools\llvm\clang-cl.exe" is not able to
  compile a simple test program.

  It fails with the following output:

   Change Dir: E:/libcxx/b-libcxx-Cascade-msbuild2/CMakeFiles/CMakeTmp

  Run Build Command:"C:/Program Files (x86)/MSBuild/14.0/bin/MSBuild.exe"
  "cmTC_00a23.vcxproj" "/p:Configuration=Debug" "/p:VisualStudioVersion=14.0"

  Microsoft (R) Build Engine version 14.0.24720.0

  C:\Program Files
  (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5):
  error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset =
  'v140_clang_3_7') cannot be found.  To build using the v140_clang_3_7 build
  tools, please install v140_clang_3_7 build tools.  Alternatively, you may
  upgrade to the current Visual Studio tools by selecting the Project menu or
  right-click the solution, and then selecting "Retarget solution".
  [E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57,5): 
error MSB8020: The build tools for v140_clang_3_7 (Platform Toolset = 
'v140_clang_3_7') cannot be found. To build using the v140_clang_3_7 build 
tools, please install v140_clang_3_7 build tools.  Alternatively, you may 
upgrade to the current Visual Studio tools by selecting the Project menu or 
right-click the solution, and then selecting "Retarget solution". 
[E:\libcxx\b-libcxx-Cascade-msbuild2\CMakeFiles\CMakeTmp\cmTC_00a23.vcxproj]

  0 warning
  1 error

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:17 (project)

-- Configuring incomplete, errors occurred!

PS. Part of the messages in Chinese are removed, please tell me if you need it 
as well

Thanks for your help,
Yi-Hong

2016-02-04 3:25 GMT+08:00 Gilles Khouzam 
<gilles.khou...@microsoft.com<mailto:gilles.khou...@microsoft.com>>:
Hi Yi-Hong,

Can you try to add the following: -DCMAKE_SYSTEM_VERSION=8.1 to your parameters?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

[Gilles Khouzam]

Hi Yi-Hong,

Can you try to add the following: -DCMAKE_SYSTEM_VERSION=8.1 to your parameters?

From: Yi-Hong Lyu [mailto:b95705...@ntu.edu.tw]
Sent: Wednesday, February 3, 2016 11:11
To: Gilles Khouzam <gilles.khou...@microsoft.com>
Cc: Nicholas Braden <nicholas11bra...@gmail.com>; cmake@cmake.org
Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hello Gilles,

Thanks for you mail. It is really useful to me but I encounter an error. My use 
case is to use clang-cl with my own target instead of x86/x64 target. Therefore 
I don't want to include any headers of VS x86/x64 and use any library of VS 
x86/x64:

PS > cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 
-DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl ..\src\

CMake Error at CMakeLists.txt:17 (project):
  Could not find an appropriate version of the Windows 10 SDK installed on this 
machine

-- Configuring incomplete, errors occurred!
See also "E:/libcxx/b-libcxx-Cascade-msbuild2/CMakeFiles/CMakeOutput.log".

I don't want to use Windows 10 SDK during compilation. Is the feature you 
implemented suitable for my special use case?

Thanks for your help,
Yi-Hong

2016-02-01 22:47 GMT+08:00 Gilles Khouzam 
<gilles.khou...@microsoft.com<mailto:gilles.khou...@microsoft.com>>:

Hi Yi-Long



Clang-Cl requires a few changes in order to work properly,



I've prototyped the support for Clang-Cl on our CMake fork with the plan to 
integrate the support once we've got good confirmation and work through some of 
the design issues.



You can find the code on 
https://github.com/microsoft/cmake/tree/feature/clang_3_7



You can also find an installer here: https://github.com/Microsoft/CMake/releases



The easiest way to set Clang as the compiler is to use the -T parameter such as

cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 ...



But I've also added a new variable VS_PLATFORM_TOOLSET_OVERRIDE that you can 
use to change the toolset for a specific target (there are scenarios where you 
need CL and Clang targeting different projects in your solution).



Thanks


~Gilles

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

[Gilles Khouzam]

Hi Yi-Long


Clang-Cl requires a few changes in order to work properly,


I've prototyped the support for Clang-Cl on our CMake fork with the plan to 
integrate the support once we've got good confirmation and work through some of 
the design issues.


You can find the code on 
https://github.com/microsoft/cmake/tree/feature/clang_3_7


You can also find an installer here: https://github.com/Microsoft/CMake/releases


The easiest way to set Clang as the compiler is to use the -T parameter such as

cmake -G "Visual Studio 14 2015" -T v140_clang_3_7 ...


But I've also added a new variable VS_PLATFORM_TOOLSET_OVERRIDE that you can 
use to change the toolset for a specific target (there are scenarios where you 
need CL and Clang targeting different projects in your solution).


Thanks


~Gilles


From: CMake  on behalf of Yi-Hong Lyu 

Sent: Sunday, January 31, 2016 10:47:58 AM
To: Nicholas Braden
Cc: cmake@cmake.org
Subject: Re: [CMake] Is there any way to use clang-cl with MSBuild on Windows?

Hello Bill,

If I generate the ALL_BUILD.vcxproj for MSVC 19.0.23506.0 as usual, I can use 
command "msbuild ALL_BUILD.vcxproj /p:cltoolexe=clang-cl" to build the project 
using clang-cl. However it might include wrong directory like C:\\Program Files 
(x86)\Windows Kits\10\Include\10.0.10240.0\ucrt during building when I build 
library libcxx. Is there any way to overwrite variables such as ExcludePath, 
IncludePath, UniversalCRT_IncludePath and VC_IncludePath?

Hello Nicholas,

Which value should I put for -T parameter?

BTW, is CMAKE_TOOLCHAIN_FILE able to used in this situation?

Thanks

2016-01-30 8:33 GMT+08:00 Nicholas Braden 
>:
Have you tried setting the toolset? The -T parameter can set the
toolset. This sets the platform toolset property that you would
normally set in Visual Studio. if Visual Studio lets you select the
llvm platform toolset, so will CMake.

On Fri, Jan 29, 2016 at 12:04 PM, Yi-Hong Lyu 
> wrote:
> Hello everyone,
>
> I am a newbie of CMake. I would like to use clang-cl with MSBuild on
> Windows. However it always use MSVC 19.0.23506.0 as the identified compiler
> even I defined CMAKE_C_COMPILER / CMAKE_CXX_COMPILER /
> CMAKE_C_COMPILER_FORCED / CMAKE_CXX_COMPILER_FORCED:
>
> $ cmake -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl
> -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER_FORCED=ON ..\src\
> -- Building for: Visual Studio 14 2015
> -- The CXX compiler identification is MSVC 19.0.23506.0
> -- The C compiler identification is MSVC 19.0.23506.0
> -- Configuring for standalone build.
> -- Found PythonInterp: C:/Python34/python.exe (found version "3.4.4")
> -- Sphinx disabled.
> .
> .
> .
>
> PS. The environment PATH is already set to clang-cl.
>
> I am wondering whether there is any option that I can force MSBuild use
> clang-cl instead.
>
> Thanks,
> Yi-Hong
>
> --
>
> 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
> 

[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] Generating Windows 10 universal project?

[Gilles Khouzam]

Hi Parag,

Please use our fork for Windows 10 universal support. I’m working on getting 
the patch ready to be integrated in the official code.

https://github.com/Microsoft/CMake. The branch is feature/Win10

Thanks.

~Gilles

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Parag Chandra
Sent: Thursday, August 13, 2015 18:16
To: David Cole via CMake cmake@cmake.org
Subject: [CMake] Generating Windows 10 universal project?

Hi,

I’m trying to generate a static library project that targets the Windows 10 
Universal App platform. I found the following post on SO:

http://stackoverflow.com/questions/31857315/how-can-i-use-cmake-to-generate-windows-10-universal-project

However, specifying -DCMAKE_SYSTEM_VERSION=10.0 (or none at all), yields the 
following error:

CMake Error at CMakeLists.txt:5 (project):
  Visual Studio 14 2015 supports Windows Store '8.0' and '8.1', but not
  '10.0'.  Check CMAKE_SYSTEM_VERSION.

Is this supported yet?

Thanks,


Parag Chandra
Senior Software Engineer, Mobile Team
Mobile: +1.919.824.1410

[https://www.ionicsecurity.com/IonicSigHz.png]https://ionic.com

Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] on cmake supporting one arch per project (from CMake IR)

[Gilles Khouzam]

Yes, this change was done specifically to support VS and does not address some 
of the hard issues that arise from multiplatform support. This is why we're 
keeping it in our fork and are not pushing too hard to get it integrated into 
the official product.

It does make it easier for people that want to produce multiple architectures 
but don't necessarily have different settings for each.

The latest change has been updated to CMake 3.3.0 with Windows 10 support:

https://github.com/microsoft/cmake/tree/feature/Win10MultiPlatform



-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of James Johnston
Sent: Thursday, August 6, 2015 09:59
To: cmake@cmake.org
Subject: Re: [CMake] on cmake supporting one arch per project (from CMake IR)

 -Original Message-
 From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Greg Marr
 Sent: Wednesday, August 05, 2015 18:42
 To: Raymond Wan; Scott Aron Bloom
 Cc: cmake@cmake.org
 Subject: Re: [CMake] on cmake supporting one arch per project (from 
 CMake IR)
  
 
 Gilles Khouzam from Microsoft has created an experimental fork, 
 current as of 3.2.1, that adds this support.
 https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform
 
 Adding experimental MultiPlatform support to CMake for Windows and VS
 2012 and above.
 
 By setting the CMAKE_VS_EFFECTIVE_PLATFORMS variable, the user is able 
 to specify that multiple platforms should be produced for the same
project.
 
 The supported platforms are Win32, ARM and x64 (not applicable to 
 Windows Phone) and should be specified as a delimited string
 Win32;ARM;x64 for example.

I read this and also glanced through the patch (look for commit ID
065bdceb0fbe5253b229faa843fce6b1c271f047 in his repo).  It feels a little goofy 
and too VS-centric to me.

How should existing end-user code like this be handled?

if(MSVC90 AND NOT CMAKE_CL_64)
# set 32-bit VC2008 flags
set(CMAKE_CXX_FLAGS stuff)
# snip
elseif(MSVC90 AND CMAKE_CL_64)
# set some 64-bit VC2008 flags
set(CMAKE_CXX_FLAGS stuff)
# snip
endif()

Well, it seems like you would need platform-specific CXX_FLAGS variables, in 
addition to the configuration-specific CXX_FLAGS variables already offered.
So you'd need a lot new CMake variables for the compiler, linker, etc.
Ideally you'd want to figure out how to do this without completely breaking 
every piece of user code that previously ever touched those variables.
While you're at it, you'd want platform-specific variables containing 
platform-specific paths to each compiler.  (e.g. path to 32-bit cl.exe, path to 
64-bit cl.exe.)  Of course, that opens the door to mixing VC++ and
non-VC++ compilers in the same CMake project...

Also, the meaning of variables like MSVC90 or even CMAKE_CL_64 change:
previously CMAKE_CL_64 meant building for 64-bit whereas maybe now it means 
you may or may not be building for 64-bit ???  What is CMAKE_CL_64 supposed 
to do if CMAKE_VS_EFFECTIVE_PLATFORMS is set to Win32;x64?

Also, you're still limited to VS generator in his patch, as evidenced by VS 
in CMAKE_VS_EFFECTIVE_PLATFORMS.  I guess that's all fine  well as far as 
Microsoft's concerned.  What if I want to build multi-platforms with the Ninja 
generator?  GNU Make generator?  Multi-platforms on Linux? Mac?
(Personally I dislike the VS generator / MSBuild on Windows for big builds 
because the parallelization in MSBuild and cl.exe isn't coordinated, leading to 
significant over/under-subscription problems that can be avoided with any other 
generator on Windows.)

I'm not making this up, if CMake supported multi-platform building, I would be 
needing/wanting to specify multiple platforms for the project I'm working on 
right now: (1) VC++ 32-bit, (2) VC++ 64-bit, (3) GCC cross-compiler, (4)
C++ Builder.  Some targets would be built for multiple platforms; others
would be built for only one of those four platforms.  I have annoying 
requirements that multi-platform could help with like: the cross-compiler 
requires a custom build step/tool that is built using Visual Studio.

Very flexible multi-platform can/should be easy for the makefile generators 
to handle.  And the VS generator can handle #1 and #2 fine enough but what if I 
want it to generate a CMake project containing the GCC/BCC32 targets, for 
example?  How the heck does that work?  And what if I want multiple VC++ 
versions in my platform list - say, VC2008 and VS2013?  (After all, I could 
point to differing versions of cl.exe with my platform-specific COMPILER 
variables).  Again that's something that multi-platform makefile generators 
can/should handle easily but what if the VS generator is asked to generate 
for VC2008 and VC2013 platforms?  Right now the VS generators have it easy - 
they only have one cl.exe version to contend with (and it's guaranteed to be a 
cl.exe to begin with).  I guess you could have the Ninja/makefile generators 
happily generate true multi-platform stuff while have

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] Multi-platform visual studio projects

[Gilles Khouzam]

For those interested, we have a fork with the ability to support MultiPlatform 
projects in Visual Studio for Windows Phone and Windows Store apps. It is not a 
big change to remove that restriction and have it for desktop apps, please tell 
me if there is interest.

For those interested the fork is on http://CMakeMS.codeplex.com and the branch 
is MSMultiPlatform.

As David mentions though, this does have limitations.

~Gilles

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Scott Aron Bloom
Sent: Sunday, March 8, 2015 15:17
To: David Cole; Scott Aron Bloom
Cc: cmake@cmake.org
Subject: Re: [CMake] Multi-platform visual studio projects

Agreed on all points..  Unfortunately...  ;)

I remember going through this with qmake,  which initially could not create a 
debug and release vc project file...


--Scott

 Original message 
From: David Cole dlrd...@aol.commailto:dlrd...@aol.com
Date:03/08/2015 13:57 (GMT-08:00)
To: Scott Aron Bloom 
scott.bl...@onshorecs.commailto:scott.bl...@onshorecs.com
Cc: Ryan Pavlik ryan.pav...@gmail.commailto:ryan.pav...@gmail.com, John 
Drescher dresche...@gmail.commailto:dresche...@gmail.com, 
cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] Multi-platform visual studio projects

There is no technical reason... But it seems to me there is a strong bias 
toward single-architecture build trees in the minds of non-VS/non-XCode 
developers.

There is rampant code like this in the world:

if(CMAKE_SIZEOF_VOID_P EQUAL 8)
  # do 64-bit stuff at CMake time
else()
  # do 32-bit stuff
endif()

Code like this assumes the architecture is determined at configure time rather 
than at build time. Very similar to using CMAKE_BUILD_TYPE in CMake code geared 
toward a single-config build. A lot of (some would say too much) effort over 
the years was required to get multi-configuration builds working well for VS. 
Unfortunately, a similar approach was not followed for the architecture types, 
and we've ended up with a proliferation of generators, and now the concept of 
toolsets, but still the restriction that a generated solution and set of 
project files is only of a single architecture.

Hope this helps to explain the situation a bit.

I know it's not what you wanted to hear, but, from my perspective, that's the 
way things are.

If you'd like to work on improving the situation.. I'm sure your efforts 
would be welcomed by many. ;-)


Cheers,
David C.




On Sunday, March 8, 2015, Scott Aron Bloom 
scott.bl...@onshorecs.commailto:scott.bl...@onshorecs.com wrote:
That's what I have found as well.

Based on that.   Why can't call create a 64 and 32 bit solution?

It would seem to me,  that there is no technical reason.


--Scott

 Original message 
From: Ryan Pavlik ryan.pav...@gmail.com
Date:03/08/2015 06:35 (GMT-08:00)
To: Scott Aron Bloom scott.bl...@onshorecs.com, John Drescher 
dresche...@gmail.com
Cc: cmake@cmake.org
Subject: Re: [CMake] Multi-platform visual studio projects


You are correct: if you're using the visual studio generators it doesn't matter 
(in general) what your process environment variables are. Note that if you're 
using find package, some of those scripts use environment variables to help 
find libraries, but they are not the standard variables set by the visual 
studio command prompt scripts.

The command prompt would matter if, for instance, you were using the nmake 
makefiles generator.

Ryan

On Wed, Mar 4, 2015, 11:03 AM Scott Aron Bloom scott.bl...@onshorecs.com 
wrote:
Another question on this..

It appears, that cmake creates the proper solution, for 64 bits even if the 
shell is setup for 32 bits, and vice versa.

Is this correct?  Meaning when its checking the C compiler and CXX compiler ABI 
info and what not, its not looking for bit width, it uses the generator Visual 
Studio...Win64 vs Visual Studio for bit width

If Im not using a command line based build, does it matter how my command line 
is setup for running cmake?

Scott

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Scott Aron Bloom
Sent: Friday, February 27, 2015 8:26 AM
To: John Drescher
Cc: cmake@cmake.org
Subject: Re: [CMake] Multi-platform visual studio projects

Thanks!

-Original Message-
From: John Drescher [mailto:dresche...@gmail.com]
Sent: Friday, February 27, 2015 8:26 AM
To: Scott Aron Bloom
Cc: cmake@cmake.org
Subject: Re: [CMake] Multi-platform visual studio projects

 However,  once the solution is created, does the path of the shell matter 
 at all?

No.

John
--

Powered by www.kitware.comhttp://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: 

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] [cmake-developers] [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

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] [cmake-developers] [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-develop...@cmake.org; CMake 
MailingListmailto:cmake@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

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] Get Visual Studio target Arch

[Gilles Khouzam]

Hi Alexey

I’ve updated our installers to get installed in CMakeMS instead of CMake, this 
allows you to run both side by side.

If you want to rename the executable to be CMakeMS.exe, you can, I just felt 
that for people relying on scripts, this could be a hard change to take.

~Gilles


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Get Visual Studio target Arch

[Gilles Khouzam]

Hi David, Alexey

I'm glad to hear your enthusiasm about our involvement with CMake. We're still 
trying to understand the issues that people are facing and how we can help 
improve those. The multi-platform support is something somewhat experimental 
that will have issues, but getting feedback will help address the issues that 
you might run into. 

Alexey, the issue with CMAKE_SYSTEM_PROCESSOR seems to come from the 
CMakeDetermineSystem.cmake (lines 110 and below) file which only sets it for 
WINCE based on the MSVC_C_ARCHITECTURE_ID and uses the HOST processor 
otherwise. That's probably why you're seeing AMD64 all the time. My initial 
thought is that using MSVC_C_ARCHITECTURE_ID should give you at least the right 
processor for the compile.

BTW, I've only enabled the multiplatform support for cross-compiling for 
Windows Phone and Windows Store apps (to reduce the potential regressions) but 
if you would like to have it for native Windows apps, I should be able to 
easily enable it.

Looking forward to being able to help more.

Gilles Khouzam
Senior Development Lead
Microsoft OSG

-Original Message-
From: David Cole [mailto:dlrd...@aol.com] 
Sent: Tuesday, September 16, 2014 03:37
To: alexey.petruc...@gmail.com; Gilles Khouzam
Cc: cmake@cmake.org
Subject: Re: [CMake] Get Visual Studio target Arch

 I still cant really make some arch specific ifdefs in my cmake scripts 
 using this approach.


That's the point of a multi-configuration, multi-architecture Visual Studio 
solution: you defer choosing the configuration *and* the architecture until 
build time.

No CMake time decisions are possible based on the configuration or the 
architecture with this approach because neither is known until compile time.

It is inappropriate to choose the configuration or architecture in CMake code 
with this approach, and you should re-think about it and see if you can make 
compile time decisions instead, possibly with #ifdef sections in your C/C++ 
code...

Rather than re-organize your libraries, you could easily just use 
win32/libs/$(Platform) as your value when using the VS generators, and this 
should work.


By the way, Gilles, I echo the sentiment: nice work! I wish MS had gotten 
involved in CMake even earlier... but welcome!


HTH,
David C.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Get Visual Studio target Arch

[Gilles Khouzam]

Hi Greg,

You might want to check out our current fork of CMake on 
http://cmakems.codeplex.com. I've just added support for multiplatform support 
for Windows Phone and Windows Store app in a similar way that it is done for 
iOS.

You can try the build on http://cmakems.codeplex.com/releases/view/132284 or 
use the MSMultiPlatform branch. This will generate one solution that can target 
Win32/ARM/x64 placing each architecture in a folder based on the platform name 
(using the $(Platform) variable in VS. 

To enable this, add the following define: 
CMAKE_VS_EFFECTIVE_PLATFORMS=Win32;ARM;x64 and code for all three platforms 
will be generated. We'd love to understand the type of issues you might run 
into with this and how we can make it better.

Thanks
~Gilles

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Gregor Jasny
Sent: Monday, September 8, 2014 12:06
To: cmake@cmake.org; Alexey Petruchik
Subject: Re: [CMake] Get Visual Studio target Arch

On 06/09/14 16:02, Alexey Petruchik wrote:
 I want to use different library folders for x64/x86/arm architectures.
 Cmake has different generators for each arch: Visual Studio 12 2013, 
 Visual Studio 12 2013 ARM, Visual Studio 12 2013 Win64. Is there 
 any cmake var to get visual studio target arch? CMAKE_SYSTEM_PROCESSOR 
 is always AMD64 for me no matter what generator I'm using.

All the already available stuff in cmake is not sufficient. Especially if you 
start to cross compile.

I use the pre-defined C/C++ preprocessor symbols for that:

include(CheckSymbolExists)

if(WIN32)
  check_symbol_exists(_M_AMD64  RTC_ARCH_X64)
  if(NOT RTC_ARCH_X64)
check_symbol_exists(_M_IX86  RTC_ARCH_X86)
  endif(NOT RTC_ARCH_X64)
  # add check for arm here
  # see http://msdn.microsoft.com/en-us/library/b0084kay.aspx
else(WIN32)
  check_symbol_exists(__i386__  RTC_ARCH_X86)
  check_symbol_exists(__x86_64__  RTC_ARCH_X64)
  check_symbol_exists(__arm__  RTC_ARCH_ARM)
endif(WIN32)

Now you could write:

if(RTC_ARCH_X64)
  set(MY_LIB_DIR x64)
elseif(RTC_ARCH_X86)
  set(MY_LIB_DIR x86)
elseif(RTC_ARCH_ARM)
  set(MY_LIB_DIR x86)
else()
  message(FATAL_ERROR Unknown architecture)
endif()

I hope this helps.

Thanks,
Gregor
-- 

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [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] 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-develop...@cmake.org; cmake@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-develop...@cmake.org; 
cmake@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-develop...@cmake.org; cmake@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:

Re: [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-develop...@cmake.org; cmake@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-develop...@cmake.org; cmake cmake@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: