Re: [cmake-developers] Patches for Visual Studio multi-CPU architecture project generation and a Windows-Phone-8 generator

[Patrick Gansterer]

Do Windows Store and Desktop apps have different toolsets? If yes it should be 
enough IMO.

On 21.10.2013, at 14:26, Paul Annetts wrote:

 To differentiate between Windows Store and Windows desktop apps. 
 
 Paul.
 From: Patrick Gansterer
 Sent: ‎21/‎10/‎2013 09:12
 To: Paul Annetts
 Cc: 'Brad King'; cmake-developers@cmake.org
 Subject: Re: [cmake-developers] Patches for Visual Studio multi-CPU 
 architecture project generation and a Windows-Phone-8 generator
 
 
 On 21.10.2013, at 10:08, Paul Annetts wrote:
  Patrick's comments about using CMAKE_GENERATOR_TOOLSET have made me think 
  we should have a combined Visual Studio 11 2012 Windows-Store generator 
  using CMAKE_GENERATOR_TOOLSET to switch between Windows Store and Windows 
  Phone. 
  (The Windows Store and Phone C/C++ APIs are very similar, but don't share 
  an ABI).
 
 Why do you need the special Windows-Store generator then?
 
 -- Patrick

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Ninja + Windows CE

[Patrick Gansterer]

Hi,

Am 09.02.2013 um 10:39 schrieb Peter Kümmel:

 On 30.01.2013 15:17, Brad King wrote:
 On 01/26/2013 12:33 PM, Patrick Gansterer wrote:
 to compile WindowsCE C++ project with Ninja I need the attached patch
 applied.
 
 One problem with this patch is that it moves the initialization of C
 and CXX languages until after the RC initialization which tries to
 match the location of the C/CXX compilers.  Have a look at these:
 
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e3a1f727
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6547f369
 
 Peter, can you explain why this is needed for Ninja but not the
 other generators?  Why does the logic belong in that method?
 
 Thanks,
 -Brad
 
 
 It wasn't clear to me why it works with other generators so I
 patched only the ninja code. Maybe there is a better solution,
 but I couldn't figure it out.

But the current Ninja generator does not work. Any variables not set in 
Modules/CMakeCCompiler.cmake.in get no value. E.g. SET_MSVC_CXX_ARCHITECTURE_ID 
stays empty, because it's set it Modules/CMakeCXXCompiler.cmake.in. Since the 
all other generators work it seams to my like a Ninja problem, where 
EnableLanguage() of the base class isn't called correctly. 

-- Patrick 
--

Powered by www.kitware.com

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

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

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

[cmake-developers] Ninja + Windows CE

[Patrick Gansterer]

Hi,

to compile WindowsCE C++ project with Ninja I need the attached patch 
applied.


-- PatrickFrom 7d5e1c3b41b58e29d7dde7742582b3fa35a35e8e Mon Sep 17 00:00:00 2001
From: Patrick Gansterer par...@paroga.com
Date: Sat, 26 Jan 2013 12:28:25 +0100
Subject: [PATCH] Ninja: Fix problems with EnableLanguage()

We need to call EnableLanguage() of the base class with all
languages at once, because general CMake files which require
defines not done by the first language won't appear.
---
 Source/cmGlobalNinjaGenerator.cxx | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/Source/cmGlobalNinjaGenerator.cxx 
b/Source/cmGlobalNinjaGenerator.cxx
index 60f5a47..de13d13 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -502,12 +502,7 @@ void cmGlobalNinjaGenerator
 std::vectorstd::string language;
 language.push_back(*l);
 
-if(*l == NONE)
-  {
-  this-cmGlobalGenerator::EnableLanguage(language, mf, optional);
-  continue;
-  }
-else if(*l == Fortran)
+if(*l == Fortran)
   {
   std::string message = The \;
   message += this-GetName();
@@ -551,7 +546,16 @@ void cmGlobalNinjaGenerator
   }
 }
   }
-this-cmGlobalGenerator::EnableLanguage(language, mf, optional);
+}
+
+  this-cmGlobalGenerator::EnableLanguage(languages, mf, optional);
+  for(std::vectorstd::string::const_iterator l = languages.begin();
+  l != languages.end(); ++l)
+{
+if(*l == NONE)
+  {
+  continue;
+  }
 this-ResolveLanguageCompiler(*l, mf, optional);
 }
 }
-- 
1.8.0.msysgit.0

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] WindowsCE

[Patrick Gansterer]

On Thu, 29 Nov 2012 14:10:12 -0500, Brad King wrote:

On 11/29/2012 10:39 AM, Patrick Gansterer wrote:

I've created a patch and attached it.


Applied:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b558ecb5


Thanks. I've added a few lines abour the usage of the new features at 
http://www.cmake.org/Wiki/CMake_Cross_Compiling#Cross_compilation_for_Windows_CE.


I also tried additional Windows CE SDKs and found a few problems, which 
have been fixed in 
https://gitorious.org/~paroga/cmake/parogas-cmake/commits/ce.


-- Patrick

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] WindowsCE

[Patrick Gansterer]

On Wed, 28 Nov 2012 09:08:12 -0500, Brad King wrote:

On 11/28/2012 09:03 AM, Patrick Gansterer wrote:

It looks like you're adding new

cmake -E windowsce_environment8
cmake -E windowsce_environment9

commands that print out the environment settings.  That looks okay
to me, but is there no vsvars32.bat equivalent?


No, that's the reason for this. Any better name for this commands?


I have no strong preference, but perhaps

 cmake -E env_vs8_wince
 cmake -E env_vs9_wince

to set a precedent for env_ commands that generate environments.


I've created a patch and attached it.

-- PatrickFrom 67fabc0fa0a6fa62ec74eacd494793ade3ac3e45 Mon Sep 17 00:00:00 2001
From: Patrick Gansterer par...@paroga.com
Date: Thu, 29 Nov 2012 16:36:20 +0100
Subject: [PATCH] Add command to generate environment for a Windows CE SDK

---
 Source/cmVisualStudioWCEPlatformParser.cxx | 48 ++
 Source/cmVisualStudioWCEPlatformParser.h   | 13 
 Source/cmake.cxx   | 34 +
 Source/cmake.h |  2 ++
 4 files changed, 91 insertions(+), 6 deletions(-)

diff --git a/Source/cmVisualStudioWCEPlatformParser.cxx b/Source/cmVisualStudioWCEPlatformParser.cxx
index 0afcf67..b302246 100644
--- a/Source/cmVisualStudioWCEPlatformParser.cxx
+++ b/Source/cmVisualStudioWCEPlatformParser.cxx
@@ -15,18 +15,23 @@
 
 int cmVisualStudioWCEPlatformParser::ParseVersion(const char* version)
 {
-  std::string vskey = cmGlobalVisualStudioGenerator::GetRegistryBase(version);
-  vskey += \\Setup\\VS;ProductDir;
+  const std::string registryBase =
+cmGlobalVisualStudioGenerator::GetRegistryBase(version);
+  const std::string vckey = registryBase + \\Setup\\VC;ProductDir;
+  const std::string vskey = registryBase + \\Setup\\VS;ProductDir;
 
-  std::string vsInstallPath;
-  if(!cmSystemTools::ReadRegistryValue(vskey.c_str(), vsInstallPath))
+  if(!cmSystemTools::ReadRegistryValue(vckey.c_str(), this-VcInstallDir) ||
+ !cmSystemTools::ReadRegistryValue(vskey.c_str(), this-VsInstallDir))
 {
 return 0;
 }
-  cmSystemTools::ConvertToUnixSlashes(vsInstallPath);
+  cmSystemTools::ConvertToUnixSlashes(this-VcInstallDir);
+  cmSystemTools::ConvertToUnixSlashes(this-VsInstallDir);
+  this-VcInstallDir.append(/);
+  this-VsInstallDir.append(/);
 
   const std::string configFilename =
-vsInstallPath + /VC/vcpackages/WCE.VCPlatform.config;
+this-VcInstallDir + vcpackages/WCE.VCPlatform.config;
 
   return this-ParseFile(configFilename.c_str());
 }
@@ -93,6 +98,24 @@ void cmVisualStudioWCEPlatformParser::StartElement(const char* name,
   this-Macros[macroName] = macroValue;
   }
 }
+  else if(strcmp(name, Directories) == 0)
+{
+for(const char** attr = attributes; *attr; attr += 2)
+  {
+  if(strcmp(attr[0], Include) == 0)
+{
+this-Include = attr[1];
+}
+  else if(strcmp(attr[0], Library) == 0)
+{
+this-Library = attr[1];
+}
+  else if(strcmp(attr[0], Path) == 0)
+{
+this-Path = attr[1];
+}
+  }
+}
 }
 
 void cmVisualStudioWCEPlatformParser::EndElement(const char* name)
@@ -137,3 +160,16 @@ void cmVisualStudioWCEPlatformParser::CharacterDataHandler(const char* data,
 {
   this-CharacterData.append(data, length);
 }
+
+std::string cmVisualStudioWCEPlatformParser::FixPaths(
+const std::string paths) const
+{
+  std::string ret = paths;
+  cmSystemTools::ReplaceString(ret, $(PATH), %PATH%);
+  cmSystemTools::ReplaceString(ret, $(VCInstallDir), VcInstallDir.c_str());
+  cmSystemTools::ReplaceString(ret, $(VSInstallDir), VsInstallDir.c_str());
+  cmSystemTools::ReplaceString(ret, \\, /);
+  cmSystemTools::ReplaceString(ret, //, /);
+  cmSystemTools::ReplaceString(ret, /, \\);
+  return ret;
+}
diff --git a/Source/cmVisualStudioWCEPlatformParser.h b/Source/cmVisualStudioWCEPlatformParser.h
index 28061fd..466e1dd 100644
--- a/Source/cmVisualStudioWCEPlatformParser.h
+++ b/Source/cmVisualStudioWCEPlatformParser.h
@@ -31,6 +31,12 @@ public:
   bool Found() const {return this-FoundRequiredName;}
   const char* GetArchitectureFamily() const;
   std::string GetOSVersion() const;
+  std::string GetIncludeDirectories() const {
+return this-FixPaths(this-Include); }
+  std::string GetLibraryDirectories() const {
+return this-FixPaths(this-Library); }
+  std::string GetPathDirectories() const {
+return this-FixPaths(this-Path); }
   const std::vectorstd::string GetAvailablePlatforms() const {
 return this-AvailablePlatforms; }
 
@@ -40,8 +46,13 @@ protected:
   void CharacterDataHandler(const char* data, int length);
 
 private:
+  std::string FixPaths(const std::string paths) const;
+
   std::string CharacterData;
 
+  std::string Include;
+  std::string Library;
+  std::string Path;
   std::string PlatformName;
   std::string OSMajorVersion;
   std::string OSMinorVersion;
@@ -50,6 +61,8 @@ private:
 
   const char* RequiredName

[cmake-developers] WindowsCE

[Patrick Gansterer]

Hi,

since CMake 2.8.10 it's possible to build for WindowsCE via the NMake 
Makefile. But this needs some special preperation of the environment 
variables. My last changed added parsing support for 
WCE.VCPlatform.config, where this information is stored. Qt has a 
special tool (http://qt.gitorious.org/qt/qt/trees/4.8/tools/checksdk) 
for extracting this information. I'd like to add a similar functionality 
to make the environment setup easier.
I attached a first version of a possible solution. Maybe someone can 
give me some early feedack before I add documentation and so on (it 
needs rebase too), because I'm not sure if that is a good place for this 
kind of stuff.


-- Patrick
diff --git a/Source/cmVisualStudioWCEPlatformParser.cxx b/Source/cmVisualStudioWCEPlatformParser.cxx
index 270ee0c..637ed01 100644
--- a/Source/cmVisualStudioWCEPlatformParser.cxx
+++ b/Source/cmVisualStudioWCEPlatformParser.cxx
@@ -15,18 +15,21 @@
 
 int cmVisualStudioWCEPlatformParser::ParseVersion(const char* version)
 {
-  std::string vskey = cmGlobalVisualStudioGenerator::GetRegistryBase(version);
-  vskey += \\Setup\\VS;ProductDir;
+  const std::string registryBase =
+cmGlobalVisualStudioGenerator::GetRegistryBase(version);
+  const std::string vckey = registryBase + \\Setup\\VC;ProductDir;
+  const std::string vskey = registryBase + \\Setup\\VS;ProductDir;
 
-  std::string vsInstallPath;
-  if(!cmSystemTools::ReadRegistryValue(vskey.c_str(), vsInstallPath))
+  if(!cmSystemTools::ReadRegistryValue(vckey.c_str(), this-VcInstallDir) ||
+ !cmSystemTools::ReadRegistryValue(vskey.c_str(), this-VsInstallDir))
 {
 return 0;
 }
-  cmSystemTools::ConvertToUnixSlashes(vsInstallPath);
+  cmSystemTools::ConvertToUnixSlashes(this-VcInstallDir);
+  cmSystemTools::ConvertToUnixSlashes(this-VsInstallDir);
 
   const std::string configFilename =
-vsInstallPath + /VC/vcpackages/WCE.VCPlatform.config;
+this-VcInstallDir + /vcpackages/WCE.VCPlatform.config;
 
   return this-ParseFile(configFilename.c_str());
 }
@@ -93,6 +96,24 @@ void cmVisualStudioWCEPlatformParser::StartElement(const char* name,
   this-Macros[name] = value;
   }
 }
+  else if(strcmp(name, Directories) == 0)
+{
+for(const char** attr = attributes; *attr; attr += 2)
+  {
+  if(strcmp(attr[0], Include) == 0)
+{
+this-Include = attr[1];
+}
+  else if(strcmp(attr[0], Library) == 0)
+{
+this-Library = attr[1];
+}
+  else if(strcmp(attr[0], Path) == 0)
+{
+this-Path = attr[1];
+}
+  }
+}
 }
 
 void cmVisualStudioWCEPlatformParser::EndElement(const char* name)
@@ -137,3 +158,14 @@ void cmVisualStudioWCEPlatformParser::CharacterDataHandler(const char* data,
 {
   this-CharacterData.append(data, length);
 }
+
+std::string cmVisualStudioWCEPlatformParser::FixPaths(
+const std::string paths) const
+{
+  std::string ret = paths;
+  cmSystemTools::ReplaceString(ret, $(PATH), %PATH%);
+  cmSystemTools::ReplaceString(ret, $(VCInstallDir), VcInstallDir.c_str());
+  cmSystemTools::ReplaceString(ret, $(VSInstallDir), VsInstallDir.c_str());
+  cmSystemTools::ReplaceString(ret, \\, /);
+  return ret;
+}
diff --git a/Source/cmVisualStudioWCEPlatformParser.h b/Source/cmVisualStudioWCEPlatformParser.h
index 60de01e..64e7205 100644
--- a/Source/cmVisualStudioWCEPlatformParser.h
+++ b/Source/cmVisualStudioWCEPlatformParser.h
@@ -31,6 +31,12 @@ public:
   bool Found() const {return this-FoundRequiredName;}
   const char* GetArchitectureFamily() const;
   std::string GetOSVersion() const;
+  std::string GetIncludeDirectories() const {
+return this-FixPaths(this-Include); }
+  std::string GetLibraryDirectories() const {
+return this-FixPaths(this-Library); }
+  std::string GetPathDirectories() const {
+return this-FixPaths(this-Path); }
   const std::vectorstd::string GetAvailablePlatforms() const {
 return this-AvailablePlatforms; }
 
@@ -40,8 +46,13 @@ protected:
   void CharacterDataHandler(const char* data, int length);
 
 private:
+  std::string FixPaths(const std::string paths) const;
+
   std::string CharacterData;
 
+  std::string Include;
+  std::string Library;
+  std::string Path;
   std::string PlatformName;
   std::string OSMajorVersion;
   std::string OSMinorVersion;
@@ -50,6 +61,8 @@ private:
 
   bool FoundRequiredName;
   const char* RequiredName;
+  std::string VcInstallDir;
+  std::string VsInstallDir;
 };
 
 #endif
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index 1424a11..77ccc69 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -82,6 +82,7 @@
 
 #if defined(CMAKE_HAVE_VS_GENERATORS)
 #include cmCallVisualStudioMacro.h
+#include cmVisualStudioWCEPlatformParser.h
 #endif
 
 #if !defined(CMAKE_BOOT_MINGW)
@@ -1689,6 +1690,14 @@ int cmake::ExecuteCMakeCommand(std::vectorstd::string args)
   {
   return cmake::VisualStudioLink(args, 2);
   }
+else if (args[1] == windowsce_environment8  

[cmake-developers] Support Win flex-bison

[Patrick Gansterer]

Hi,

Win flex-bison (http://sourceforge.net/projects/winflexbison/) is a 
port of flex and bison for Windows, since GnuWin32 binaries 
(http://gnuwin32.sourceforge.net/packages.html) are very old in the 
meantime.
The branch at 
https://gitorious.org/~paroga/cmake/parogas-cmake/commits/winflexbison 
adds support for them to CMake.


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Support Win flex-bison

[Patrick Gansterer]

Hi,

On Mon, 26 Nov 2012 16:05:33 -0500, Brad King wrote:

On 11/26/2012 02:53 PM, Patrick Gansterer wrote:

Win flex-bison (http://sourceforge.net/projects/winflexbison/) is a
port of flex and bison for Windows, since GnuWin32 binaries
(http://gnuwin32.sourceforge.net/packages.html) are very old in the
meantime.
The branch at

https://gitorious.org/~paroga/cmake/parogas-cmake/commits/winflexbison
adds support for them to CMake.


In the FindFLEX change I do not see how

 ${FLEX_EXE_NAME}

is set before being parsed anymore.


Uh, thanks. Pushed to wrong commit, sorry. I updated the branch now.

-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

On Mon, 19 Nov 2012 14:57:15 -0500, Brad King wrote:

On 11/19/2012 02:53 PM, Patrick Gansterer wrote:

On Mon, 19 Nov 2012 14:50:57 -0500, Brad King wrote:

On 11/19/2012 02:41 PM, David Cole wrote:

Same thing in the 11 version. Missing t generaor - generator


Both fixed, thanks.


Same typo in VS8 and VS9 :-(


Also fixed now.


I've pushed all commits required for building WinCE projects too. :-)
Since it's based on master, it won't merge without conflicts (generator 
typo).


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Windows CE in VS IDE (was: Specifying VS target platform)

[Patrick Gansterer]

On Tue, 20 Nov 2012 12:02:08 -0500, Brad King wrote:

On 11/20/2012 07:53 AM, Patrick Gansterer wrote:
I've pushed all commits required for building WinCE projects too. 
:-)
Since it's based on master, it won't merge without conflicts 
(generator

typo).


Thanks.  We've merged the generator factory changes to 'master'.
Please rebase the rest of your topic on 8faf4e93 or later.
There are some conflicts with other topics we just merged
in cmGlobalVisualStudio(7|71|8)Generator.(h|cxx).


I've push the rebased commits.

-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

On Mon, 19 Nov 2012 09:01:37 -0500, Brad King wrote:

On 11/17/2012 05:14 PM, Patrick Gansterer wrote:

On Tue, 18 Sep 2012 07:59:58 -0400, Brad King wrote:

On 09/18/2012 02:23 AM, Patrick Gansterer wrote:

Maybe we can only change to current exact match of the generator
name to a startsWith and let the global generator class decide 
if

the generator name is valid?


Yes, something like that in cmake::CreateGlobalGenerator will work.
It will be nice to get rid of the platform-varied generator 
classes.


I found some time to work on this again. I only refectored the cmake 
in

a first step. If the commits at
https://gitorious.org/~paroga/cmake/parogas-cmake/commits/factory or 
a
similar solution gets merged, I'll refector the Visual Studio 
Generators

and then add support for the WinCE platform.


Wonderful, thanks for working on this!

The approach in your topic looks good.  There are a few style 
concerns

though:

- Please add documentation to cmGlobalGeneratorFactory, or at least
  in the commit message that adds it, explaining its purpose.


Didn't wanted to put to much work into documentation in a first step, 
but since it seams fine to you, I'll extend the incode documentation and 
all commit messages.



- Please limit C++ source code to 79 columns or fewer.  The output of

   git log origin/master.. --pickaxe-regex -S'.{80}' -- Source

  should be empty when HEAD is your topic.


OK, interessing, seams that I missed a few places when checking the 
line lenghts. :-/


- If some of the ancient compilers we support can't handle the 
template

  specializations I'll have to revert it and come back to you for an
  alternative.


Cool. If I get some infos about the templat problems, I'll fix them.


After this the next commit should drop the architecture-specific
generator classes in favor of the new approach.  That will 
demonstrate

that this refactoring is worthwhile even with no new features such as
WinCE support.


That's exactly my plan. :-)

-- Patrick

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

On Mon, 19 Nov 2012 09:01:37 -0500, Brad King wrote:

On 11/17/2012 05:14 PM, Patrick Gansterer wrote:

On Tue, 18 Sep 2012 07:59:58 -0400, Brad King wrote:

On 09/18/2012 02:23 AM, Patrick Gansterer wrote:

Maybe we can only change to current exact match of the generator
name to a startsWith and let the global generator class decide 
if

the generator name is valid?


Yes, something like that in cmake::CreateGlobalGenerator will work.
It will be nice to get rid of the platform-varied generator 
classes.


I found some time to work on this again. I only refectored the cmake 
in

a first step. If the commits at
https://gitorious.org/~paroga/cmake/parogas-cmake/commits/factory or 
a
similar solution gets merged, I'll refector the Visual Studio 
Generators

and then add support for the WinCE platform.


Wonderful, thanks for working on this!


I've pushed a new version to the same location.

-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

On Mon, 19 Nov 2012 11:03:01 -0500, Brad King wrote:

On 11/19/2012 10:18 AM, Patrick Gansterer wrote:

Wonderful, thanks for working on this!


I've pushed a new version to the same location.


Looks good.  I've merged to our 'next' branch for testing:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ce3496e9


Thanks!


Please visit our dashboard:

 http://open.cdash.org/index.php?project=CMake

tomorrow to check for errors related to these changes.


I'll do. :-)

I also added an additional commit at factory branch for the 
GetDocumentation method (which depends on the merged commits).


Attached is an unrelated (but required) patch to clean up VS generators 
before merging. Maybe you can merge this too?


-- PatrickFrom 4b833e9767545c53dd6fece5988388f4047043ec Mon Sep 17 00:00:00 2001
From: Patrick Gansterer par...@paroga.com
Date: Mon, 19 Nov 2012 17:21:47 +0100
Subject: [PATCH] VS: Remove AddPlatformDefinitions from platform-specific
 generators

Move the logic for handling platform specific defines from the
subclasses into the cmGlobalVisualStudioGenerator baseclass.
---
 Source/cmGlobalVisualStudio10IA64Generator.cxx  |9 +
 Source/cmGlobalVisualStudio10IA64Generator.h|2 --
 Source/cmGlobalVisualStudio10Win64Generator.cxx |9 +
 Source/cmGlobalVisualStudio10Win64Generator.h   |2 --
 Source/cmGlobalVisualStudio11Win64Generator.cxx |9 +
 Source/cmGlobalVisualStudio11Win64Generator.h   |2 --
 Source/cmGlobalVisualStudio8Win64Generator.cxx  |9 +
 Source/cmGlobalVisualStudio8Win64Generator.h|6 --
 Source/cmGlobalVisualStudio9IA64Generator.cxx   |9 +
 Source/cmGlobalVisualStudio9IA64Generator.h |6 --
 Source/cmGlobalVisualStudio9Win64Generator.cxx  |9 +
 Source/cmGlobalVisualStudio9Win64Generator.h|6 --
 Source/cmGlobalVisualStudioGenerator.cxx|6 ++
 Source/cmGlobalVisualStudioGenerator.h  |1 +
 14 files changed, 13 insertions(+), 72 deletions(-)

diff --git a/Source/cmGlobalVisualStudio10IA64Generator.cxx 
b/Source/cmGlobalVisualStudio10IA64Generator.cxx
index 40bc307..fabe717 100644
--- a/Source/cmGlobalVisualStudio10IA64Generator.cxx
+++ b/Source/cmGlobalVisualStudio10IA64Generator.cxx
@@ -17,6 +17,7 @@
 cmGlobalVisualStudio10IA64Generator::cmGlobalVisualStudio10IA64Generator()
 {
   this-ArchitectureId = x64;
+  this-AdditionalPlatformDefinition = CMAKE_FORCE_IA64;
 }
 
 //
@@ -30,14 +31,6 @@ void cmGlobalVisualStudio10IA64Generator
 
 //
 void cmGlobalVisualStudio10IA64Generator
-::AddPlatformDefinitions(cmMakefile* mf)
-{
-  this-cmGlobalVisualStudio10Generator::AddPlatformDefinitions(mf);
-  mf-AddDefinition(CMAKE_FORCE_IA64, TRUE);
-}
-
-//
-void cmGlobalVisualStudio10IA64Generator
 ::EnableLanguage(std::vectorstd::string const languages,
  cmMakefile* mf, bool optional)
 {
diff --git a/Source/cmGlobalVisualStudio10IA64Generator.h 
b/Source/cmGlobalVisualStudio10IA64Generator.h
index 2543677..ae12cc3 100644
--- a/Source/cmGlobalVisualStudio10IA64Generator.h
+++ b/Source/cmGlobalVisualStudio10IA64Generator.h
@@ -33,8 +33,6 @@ public:
   /** Get the documentation entry for this generator.  */
   static void GetDocumentation(cmDocumentationEntry entry);
 
-  virtual void AddPlatformDefinitions(cmMakefile* mf);
-
   virtual void EnableLanguage(std::vectorstd::stringconst languages,
   cmMakefile *, bool optional);
 };
diff --git a/Source/cmGlobalVisualStudio10Win64Generator.cxx 
b/Source/cmGlobalVisualStudio10Win64Generator.cxx
index d9db731..0352a46 100644
--- a/Source/cmGlobalVisualStudio10Win64Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Win64Generator.cxx
@@ -17,6 +17,7 @@
 cmGlobalVisualStudio10Win64Generator::cmGlobalVisualStudio10Win64Generator()
 {
   this-ArchitectureId = x64;
+  this-AdditionalPlatformDefinition = CMAKE_FORCE_WIN64;
 }
 
 //
@@ -30,14 +31,6 @@ void cmGlobalVisualStudio10Win64Generator
 
 //
 void cmGlobalVisualStudio10Win64Generator
-::AddPlatformDefinitions(cmMakefile* mf)
-{
-  this-cmGlobalVisualStudio10Generator::AddPlatformDefinitions(mf);
-  mf-AddDefinition(CMAKE_FORCE_WIN64, TRUE);
-}
-
-//
-void cmGlobalVisualStudio10Win64Generator
 ::EnableLanguage(std::vectorstd::string const languages,
  cmMakefile* mf, bool optional)
 {
diff --git a/Source/cmGlobalVisualStudio10Win64Generator.h 
b/Source/cmGlobalVisualStudio10Win64Generator.h
index d95f770..66d77a9 100644
--- a/Source

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

On Mon, 19 Nov 2012 14:50:57 -0500, Brad King wrote:

On 11/19/2012 02:41 PM, David Cole wrote:

Same thing in the 11 version. Missing t generaor - generator


Both fixed, thanks.


Same typo in VS8 and VS9 :-(

-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

Hi,

On Tue, 18 Sep 2012 07:59:58 -0400, Brad King wrote:

On 09/18/2012 02:23 AM, Patrick Gansterer wrote:

If we store everything in one variable (via string concatenation) I
don't see much value in an extra -GP switch. We need to split the
${CMAKE_GENERATOR} variable into generator+platform then all the 
time

anyway.
Maybe we can only change to current exact match of the generator 
name

to a startsWith and let the global generator class decide if the
generator name is valid?


Yes, something like that in cmake::CreateGlobalGenerator will work.
It will be nice to get rid of the platform-varied generator classes.

The reference documentation we generate explicitly lists all names
with the platforms right now.  That will have to be refactored to
list the platformless names with a note about where to specify the
platform name.  Then we need a per-generator list of platform names
along with a note that one specifies Win32 by leaving the platform
name off.


I found some time to work on this again. I only refectored the cmake in 
a first step. If the commits at 
https://gitorious.org/~paroga/cmake/parogas-cmake/commits/factory or a 
similar solution gets merged, I'll refector the Visual Studio Generators 
and then add support for the WinCE platform.


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

On Mon, 17 Sep 2012 09:57:28 -0400, Brad King wrote:

On 09/14/2012 05:59 PM, Patrick Gansterer wrote:

Maybe you can merge the first patch already.


Yes, done.

The idea of a generator platform is not generic among all 
generators.

Rather than the general CMAKE_GENERATOR_PLATFORM infrastructure I'd
generator-specific handling.  The value of -GP should be passed to 
the
global generator created from -G.  If the generator does not 
support

platform specification in this way then -GP should be an error (all
generators except VS = 8).  If the generator does support -GP then 
it
should do its own thing to save the value.  For VS save it in a 
cache

entry like CMAKE_VS_PLATFORM (we have CMAKE_VS_PLATFORM_TOOLSET
already for the VS 10 toolchain in some cases).


I'm not a big fan of your ideas: What about the parts where we
pass the generator platform to other parts? Do we want to add
branches for every generator type to get get correct value for
the -GP parameter (e.g. if (CMAKE_GENERATOR == Visual Studio
...) -GP ${CMAKE_VS_PLATFORM})? IMHO that's not a good
idea. Also handling for making sure that generator platform
isn't changed by the user (like we do for -G already) in a
second run of CMake must be duplicated later if we add -GP to
more than one generator. (and so on...)


Good points, but we still need to reject -GP when using generators
for which it does not make sense.  I think it may be moot anyway;
see below.

I realized that existing projects may test ${CMAKE_GENERATOR} to 
look
for things like Win64.  For compatibility we need to make sure 
that


-G Visual Studio 10 -GP x64

results in CMAKE_GENERATOR being set to

-G Visual Studio 10 Win64

while processing CMake code even if it is not used that way
internally.  Of course for future VS versions the generator names
will not need to work this way, only the existing ones.


Since we need to support -G Visual Studio 10 Win64 anyway, I don't 
see
much problem if such cases will work with -G Visual Studio 10 
Win64,

but not with -G Visual Studio 10 -GP x64.


We are talking about changing the way the user selects the generator
in the GUI to be equivalent to -G/-GP.  We cannot process existing
projects differently depending on how the generator was selected.

I also know there are projects that pass ${CMAKE_GENERATOR} to
internal invocations of CMake in order to say build it like I'm
built.  These paths would not work if any information moved over
to CMAKE_GENERATOR_PLATFORM or an equivalent variable.

I think the value of -GP has to be stored in CMAKE_GENERATOR at
the end of the generator name as it is now.  The new option and GUI
updates are really just about simplifying the selection of the
generator and avoiding per-platform global generators in the internal
implementation.  Users can either use -G and specify the full
generator name with platform or use -G/-GP separately but either way
the value of CMAKE_GENERATOR will be the same.

This can probably be improved in the future with a new cmake policy
but I don't want to open that can of worms just for WinCE.  I think
you can implement -G/-GP such that the values are both stored in the
CMAKE_GENERATOR value.  Internally we won't need a separate global
generator for every platform anymore, but that does not change the
public interface.


If we store everything in one variable (via string concatenation) I 
don't see much value in an extra -GP switch. We need to split the 
${CMAKE_GENERATOR} variable into generator+platform then all the time 
anyway.
Maybe we can only change to current exact match of the generator name 
to a startsWith and let the global generator class decide if the 
generator name is valid?


-- Patrick

--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

Hi,

On Thu, 13 Sep 2012 08:55:16 -0400, Brad King wrote:

On 09/13/2012 08:31 AM, Patrick Gansterer wrote:
we can remove the *Win64|ARM generators from the list of 
generators,

so new users will use the better way?


Yes, I think so.


Since VS 2010 the vcxproj files can specify the toolchain to use
independent of the VS version


Does this help for older generators too? AFAIK this isn't supported
in VS versions before 2010 and the last VS version supporting WinCE
is VS2008.


The new interface should select only the platform and can do so for
all generator versions that support more than one platform.  However,
it can be extended in the future to *also* select the 
PlatformToolset.



We need an interface both on the command line and in the cmake-gui.
An option like your proposed -GP should work well for the command
line, through I'd like to think about the name a bit more.


What can I do with the WinCE changes until you thought about it? ;-)


Implement the -GP option instead of using CMAKE_WINCE_SDK.  If
it is not too hard try to refactor the Win64 and ARM platform
specification to work that way too.

From that prototype we can easily change the name.  Once it works
with the generator from the command line then we can look at adding
the equivalent option to the GUI.

Actually -GP may be good because then we can add -GT to select
the _Tool_ version in VS = 10.


I've pushed a new version to the ce branch again. Maybe you find time 
to give me some feedback. I'll test it in the meantime.


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform

[Patrick Gansterer]

Am 14.09.2012 um 14:11 schrieb Brad King:
 On 9/14/2012 6:47 AM, Patrick Gansterer wrote:
 I've pushed a new version to the ce branch again. Maybe you find time 
 to give me some feedback. I'll test it in the meantime.
 
 Great start!
 
 Good catch on the duplicated local generator implementations.  IIRC
 the methods were originally different but became the same after
 some recent refactoring.  I'm glad to see that enabled even more
 cleanup.

Maybe you can merge the first patch already.

 The idea of a generator platform is not generic among all generators.
 Rather than the general CMAKE_GENERATOR_PLATFORM infrastructure I'd
 generator-specific handling.  The value of -GP should be passed to the
 global generator created from -G.  If the generator does not support
 platform specification in this way then -GP should be an error (all
 generators except VS = 8).  If the generator does support -GP then it
 should do its own thing to save the value.  For VS save it in a cache
 entry like CMAKE_VS_PLATFORM (we have CMAKE_VS_PLATFORM_TOOLSET
 already for the VS 10 toolchain in some cases).

I'm not a big fan of your ideas: What about the parts where we pass the 
generator platform to other parts? Do we want to add branches for every 
generator type to get get correct value for the -GP parameter (e.g. if 
(CMAKE_GENERATOR == Visual Studio ...) -GP ${CMAKE_VS_PLATFORM})? IMHO 
that's not a good idea. Also handling for making sure that generator platform 
isn't changed by the user (like we do for -G already) in a second run of CMake 
must be duplicated later if we add -GP to more than one generator. (and so 
on...)

 I realized that existing projects may test ${CMAKE_GENERATOR} to look
 for things like Win64.  For compatibility we need to make sure that
 
 -G Visual Studio 10 -GP x64
 
 results in CMAKE_GENERATOR being set to
 
 -G Visual Studio 10 Win64
 
 while processing CMake code even if it is not used that way
 internally.  Of course for future VS versions the generator names
 will not need to work this way, only the existing ones.

Since we need to support -G Visual Studio 10 Win64 anyway, I don't see much 
problem if such cases will work with -G Visual Studio 10 Win64, but not with 
-G Visual Studio 10 -GP x64.

 In the compiler id sources, you add this:
 
 +#ifdef ADD_MAINCRTSTARTUP
 +void mainCRTStartup() {}
 +#endif
 
 It should be compiled with the actual compiler for the platform.  Is
 there a predefined macro that could be used instead?  Does it have
 to be conditional?  I do not think they would hurt anything on other
 platforms (just use (void) instead of () in the declaration).

It will work for other platforms, but when compiling with MSVC the linker 
usually searches for mainCRTStartup(). For the desktop platforms the function 
is defined in the C runtime, which is linked by default and would result in a 
duplicated symbol.

 In the Remove TargetMachine for linker change does that work for
 VS 10 too?  Currently the change only affects VS 7-9.

Didn't try, but I'll have a look at it.

--Patrick 
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

Am 13.09.2012 um 13:48 schrieb Brad King:

 On 09/12/2012 09:00 AM, Patrick Gansterer wrote:
 The topic meged a few hours ago. I rebased the code and pushed it again 
 as ce
 
 Thanks.
 
 Normally cross compiling is done with a toolchain file and
 sets CMAKE_CROSSCOMPILING.  Does that work for the NMake
 generator now without this topic?

Should work now for many parts. IMHO there are still a few parts which do not 
work 100% now. But I can figure it out with the current master.

 We need to figure out how to map that approach into the IDE
 generators.  A setting like CMAKE_WINCE_SDK needs to be set
 before any languages are enabled.  How should a user set it?

If you apply it to the other VS genertors we need to extend the list of 
generators with every SDK found (-G Visual Studio 8 2005 ${CMAKE_WINCE_SDK}). 
IMHO selecting the platform for the VS compiler with different compilers isn't 
perfect either (For every new VS version you get 2 (with ARM 3) new generator 
types).
Maybe we can extend the -G parameter with something like -GP 
generatorPlatform and remove the Win64 and ARM VS generators?

 Please also add documentation for CMAKE_WINCE_SDK.
 
 BTW, why is this hunk needed?
 
 +  this-GetCMakeInstance()-AddCacheEntry(CMAKE_C_COMPILER,
 +cl, , cmCacheManager::INTERNAL);
 +  this-GetCMakeInstance()-AddCacheEntry(CMAKE_CXX_COMPILER,
 +cl, , cmCacheManager::INTERNAL);

Otherwiese Visual Studio catches the wrong compiler later. But maybe the CMake 
codebase improved in the meantime (the patch is based on v2.8.3).

-- Patrick 
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Specifying VS target platform (was: Added very basic Windows CE Makefile support)

[Patrick Gansterer]

Hi,

Am 13.09.2012 um 14:21 schrieb Brad King:

 On 09/13/2012 08:06 AM, Patrick Gansterer wrote:
 If you apply it to the other VS genertors we need to extend the list
 of generators with every SDK found (-G Visual Studio 8 2005
 ${CMAKE_WINCE_SDK}). IMHO selecting the platform for the VS
 compiler with different compilers isn't perfect either (For every
 new VS version you get 2 (with ARM 3) new generator types).  Maybe
 we can extend the -G parameter with something like -GP
 generatorPlatform and remove the Win64 and ARM VS generators?
 
 I've never been happy with the platform-in-generator-name approach
 either.  It was first done for VS 2005 and only added one extra
 generator name at the time.  We need to come up with another approach.
 We just need to honor the currently enumerated names for backward
 compatibility though.

Yes, compatibility is important here. But at lease we can remove the 
*Win64|ARM generators from the list of generators, so new users will use the 
better way?

 Since VS 2010 the vcxproj files can specify the toolchain to use
 independent of the VS version (to use the VS 9 tools with VS 10
 for example).  Recently the 'ide-compiler-id' topic was merged.
 With that we should be able to support changing the toolchain
 for VS 2010 and above, but we need to choose an interface to set
 it.  Since toolchains come with SDKs this should be the same
 interface needed to specify the WinCE SDK.

Does this help for older generators too? AFAIK this isn't supported in VS 
versions before 2010 and the last VS version supporting WinCE is VS2008.

 We need an interface both on the command line and in the cmake-gui.
 An option like your proposed -GP should work well for the command
 line, through I'd like to think about the name a bit more.  In the
 IDE there is a dialog that comes up to configure the toolchain
 for other generators in a fresh build tree.  That should be taught
 to select the toolset to use for VS.

What can I do with the WinCE changes until you thought about it? ;-)

 Please also add documentation for CMAKE_WINCE_SDK.
 
 BTW, why is this hunk needed?
 
 +  this-GetCMakeInstance()-AddCacheEntry(CMAKE_C_COMPILER,
 +cl, , cmCacheManager::INTERNAL);
 +  this-GetCMakeInstance()-AddCacheEntry(CMAKE_CXX_COMPILER,
 +cl, , cmCacheManager::INTERNAL);
 
 Otherwiese Visual Studio catches the wrong compiler later.
 But maybe the CMake codebase improved in the meantime (the patch is based on 
 v2.8.3).
 
 The above-mentioned 'ide-compiler-id' topic re-works the way these
 variables get set in the VS IDE generators.  Your branch is now
 based on a version with that topic so please investigate it again.

Yes, I'll look at it.

-- Patrick 
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

On Wed, 05 Sep 2012 16:03:59 -0400, Brad King wrote:

On 09/05/2012 04:26 AM, Patrick Gansterer wrote:
Thanks for the feedback. I've updated my changes and pushed it to 
the

same branch.


Great, thanks.  I've pushed the platform file commits with minor 
tweaks:


 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7cb8055
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=28d744c9

Please rebase the rest of the topic on those, or on master after
they make it there.


The topic meged a few hours ago. I rebased the code and pushed it again 
as ce to
https://gitorious.org/~paroga/cmake/parogas-cmake 
(git://gitorious.org/~paroga/cmake/parogas-cmake.git)


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

On Tue, 04 Sep 2012 16:39:44 -0400, Brad King wrote:

On 09/04/2012 04:18 PM, Patrick Gansterer wrote:

I rebased the code and pushed it as ce to
https://gitorious.org/~paroga/cmake/parogas-cmake
(git://gitorious.org/~paroga/cmake/parogas-cmake.git)


Thanks!  I'm looking at the first commit that adds the WindowsCE
platform files.  These lines look strange:

  set(MSVC_C_ARCHITECTURE_ID ${CMAKE_SYSTEM_PROCESSOR})
  set(MSVC_CXX_ARCHITECTURE_ID ${CMAKE_SYSTEM_PROCESSOR})

Normally the ARCHITECTURE_ID values are detected by

 Modules/CMakePlatformId.h.in

which is built by running CMAKE_(C|CXX)_COMPILER, which should
be set by the toolchain file to the proper compiler for WinCE.
Shouldn't that be taught about the architectures in question?


Thanks for the feedback. I've updated my changes and pushed it to the 
same branch.


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

On Mon, 03 Sep 2012 11:02:22 -0400, Brad King wrote:

On 09/03/2012 10:52 AM, Patrick Gansterer wrote:
I saw that Brad merged one of my changes. Are there any other 
changes

the WinCE stuff depends on to get merged?


Please rebase the remainder of the topic on upstream master, at
least as recent as commit 25b0d946.  Your changes will need to
account for at least this commit:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3ddfef1

Sorry to create these conflicts for you but I've wanted to
modernize the MSVC platform files for years and the last barrier
was recently removed (by the ide-compiler-id topic).


I rebased the code and pushed it as ce to
https://gitorious.org/~paroga/cmake/parogas-cmake
(git://gitorious.org/~paroga/cmake/parogas-cmake.git)

-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

On Wed, 22 Aug 2012 16:46:02 -0400, David Cole wrote:

Brad merged one of your commits to 'next' today.


Cool.


He's coincidentally working on getting compiler ID uniform everywhere
at the moment, and so it was easiest for him to take that change 
first

and base other work on that.

After things settle from his changes, we'll come back and visit the
WindowsCE specific portions of your topic branch.


Do you think it's possible to merge 
0001-Added-very-basic-Windows-CE-Makefile-support.patch too?

This change would allow at least the usage with NMake Makefiles.

-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

is there any chance to get at least a few of this patches into trunk?
Is there anything I can do?
Can some help me in setting up a machine for the dashboard? I haven't 
found any easy way to set up sth cross-compiling and requireing addional 
definitons in the test files.


On Tue, 24 Jul 2012 10:26:30 -0400, David Cole wrote:

I merged this branch into my local 'next' and ran several vs9 and
vs10, 32- and 64-bit dashboards on Sunday:



http://open.cdash.org/index.php?project=CMakedate=2012-07-22filtercount=1showfilters=1field1=site/stringcompare1=63value1=hut11

As you can see, there are test failures here and there, but I'm not
certain if those were problems that would have shown up before trying
this branch. I am re-running the dashboards today based strictly on
'next' without those changes for comparison.

And while those are running, I'll review the code changes to see if I
spot anything objectionable before we merge/push this to origin/next
and give it a whirl on the CMake nightly dashboards.


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

On Tue, 21 Aug 2012 12:04:50 -0400, David Cole wrote:

Which particular patches are you talking about? Are there issues with
patches that are on the 2.8.10 roadmap yet?


About the patches I posted a few weeks ago. I don't see them in master 
or next branch. So my question is, how the can get there.
Maybe you can apply at least apply the cleanup patches, which don't 
add any new behaviour, so that I can get rid of non official changes. 
(E.g. Cleanup AddPlatformDefinitions() of Visual Studio generators)



I might be able to help you set up a machine for a dashboard. We
should probably have a subset of the test suite that gets executed
specifically for cross-compiling scenarios. (Setting up a dashboard 
is

easy; making sure it's testing what we want tested here may be a bit
more difficult...)


I don't see much problem in setting up a machine for dashboard. The 
problem I see is the cross-compilation stuff.
I'd like to add the required pices for WinCE, but unfortunately I don't 
have the time to implement the whole cross compiling stuff into the test 
suite. Or at least I haven't found the correct place for the change(s) 
yet, so it works for the new generator.


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

On Sat, 21 Jul 2012 09:30:58 -0400, David Cole wrote:
On Sat, Jul 21, 2012 at 8:16 AM, Patrick Gansterer 
par...@paroga.com wrote:

Hi,


On Sat, 21 Jul 2012 08:08:43 -0400, David Cole wrote:


Do you have a local branch that has all 6 patches one on top of the 
other?



On Sat, Jul 21, 2012 at 7:49 AM, Patrick Gansterer 
par...@paroga.com

wrote:


Hi,


On Sat, 21 Jul 2012 07:44:33 -0400, David Cole wrote:



What branch did you base these on?

They don't apply cleanly on top of master today.




If I made no mistake the basic revision was the master branch of 
last

weekend:
21b45ce16f88172eac3386f002fe112014053a36

-- Patrick



I pushed it as ce to 
https://gitorious.org/~paroga/cmake/parogas-cmake

(git://gitorious.org/~paroga/cmake/parogas-cmake.git)

BTW: Are there any plans to use gerrit for CMake too?

-- Patrick



(cc'ing the CMake Developers list back in...)


OK, finally got it. Whew. Sometimes I could throw git straight out
the window...

It merges to 'next' cleanly, and builds ok on my machine with Visual
Studio 9, but then one test fails... Looks like MSVC71 is somehow
getting defined for my msvc 9 build:
...
I'll continue following up on this on Monday, (looking more closely 
at
the changes and trying to fix the failing test if you don't beat me 
to

it) -- but for now I have some other deadlines I have to meet.


Uuups. Missed to stage the VS71 generator changes. ^^

I fixed it and pushed again to the same branch (with --force).


Did you make any progress towards setting up a dashboard for this,
that demonstrates actually building some WinCE stuff with a toolchain
file?


Is there any good example how to set up a cross compiling environment?
I changed a few files, but didn't find the correct ones until now. It 
still compiles for the host system and not for the target system.
If someone can give me a few hints, I can set up the machine in the 
next few days. Otherwise I'll need some time to read the code myself, 
but it's still on my todo list. :-)


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

at first: Sorry for the very long delay.

On Mon, 14 Nov 2011 21:12:24 +0100, Alexander Neundorf wrote:

On Saturday 12 November 2011, Patrick Gansterer wrote:

Hi,

I've created a very simple patch to add the basic support for 
WindowsCE to
CMake. I does not provide any automatically architecture detection 
or so

on, but enables user to use a vanilla CMake for compiling Windows CE
projects. If the patch gets accepted I'll write a few lines into the 
wiki.


Looks ok from my side. I'm not sure it's complete.
It hardcodes the ARM architecture.
WinCE supports more than that, right ?
But maybe ARM covers most users, I don't know.

In one of the tickets below there is a patch which tries to detect 
the
architecture and was not applied because of the way it tried to do 
this.


Should we considers the people which reported and commented on those 
bugs:

http://public.kitware.com/Bug/view.php?id=8486
http://public.kitware.com/Bug/view.php?id=8102
http://public.kitware.com/Bug/view.php?id=7919

They include patches, which are also in use by them.


I know of of the other patches and my work is based on them (see als 
https://gitorious.org/~paroga/cmake/parogas-cmake).
But since there is not much progress on the mentioned bugs, I'll try to 
upstream my solution in small reviewable patches.


-- Patrick
From 4579b8be19c0afae66a78691b705b7fcb8d6a935 Mon Sep 17 00:00:00 2001
From: Patrick Gansterer par...@paroga.com
Date: Sat, 14 Jul 2012 07:12:23 +0200
Subject: [PATCH] Added very basic Windows CE Makefile support

This patch enables CMake to create Makefiles targeting
Windows CE devices.
CMake needs to be run within an cross compile command prompt
and requires a toolchain file which sets CMAKE_SYSTEM_NAME
to WindowsCE and CMAKE_SYSTEM_PROCESSOR to the target
machine architecture (e.g. THUMB).
---
 Modules/Platform/Windows-cl.cmake   |   29 ++---
 Modules/Platform/WindowsCE-cl.cmake |   13 +
 Modules/Platform/WindowsCE.cmake|1 +
 3 files changed, 36 insertions(+), 7 deletions(-)
 create mode 100644 Modules/Platform/WindowsCE-cl.cmake
 create mode 100644 Modules/Platform/WindowsCE.cmake

diff --git a/Modules/Platform/Windows-cl.cmake 
b/Modules/Platform/Windows-cl.cmake
index be6abb6..691ac78 100644
--- a/Modules/Platform/Windows-cl.cmake
+++ b/Modules/Platform/Windows-cl.cmake
@@ -7,8 +7,13 @@ SET(WIN32 1)
 
 INCLUDE(Platform/cl)
 
-SET(CMAKE_CREATE_WIN32_EXE /subsystem:windows)
-SET(CMAKE_CREATE_CONSOLE_EXE /subsystem:console)
+IF(CMAKE_SYSTEM_NAME MATCHES WindowsCE)
+  SET(CMAKE_CREATE_WIN32_EXE /subsystem:windowsce /entry:WinMainCRTStartup)
+  SET(CMAKE_CREATE_CONSOLE_EXE /subsystem:windowsce /entry:mainACRTStartup)
+ELSE(CMAKE_SYSTEM_NAME MATCHES WindowsCE)
+  SET(CMAKE_CREATE_WIN32_EXE /subsystem:windows)
+  SET(CMAKE_CREATE_CONSOLE_EXE /subsystem:console)
+ENDIF(CMAKE_SYSTEM_NAME MATCHES WindowsCE)
 
 IF(CMAKE_GENERATOR MATCHES Visual Studio 6)
SET (CMAKE_NO_BUILD_TYPE 1)
@@ -152,18 +157,28 @@ IF(MSVC_VERSION GREATER 1310)
   SET(CMAKE_CXX_LINK_EXECUTABLE CMAKE_COMMAND -E vs_link_exe 
${CMAKE_CXX_LINK_EXECUTABLE})
   SET(CMAKE_C_LINK_EXECUTABLE CMAKE_COMMAND -E vs_link_exe 
${CMAKE_C_LINK_EXECUTABLE})
 
+  IF(CMAKE_SYSTEM_NAME MATCHES WindowsCE)
+STRING(TOUPPER ${MSVC_ARCHITECTURE_FAMILY} MSVC_ARCHITECTURE_FAMILY_UPPER)
+SET(CMAKE_PLATFORM_DEFINES /D_WIN32_WCE=0x500 /DUNDER_CE 
/D${MSVC_ARCHITECTURE_FAMILY} /D_${MSVC_ARCHITECTURE_FAMILY_UPPER}_)
+SET(CMAKE_C_STANDARD_LIBRARIES_INIT coredll.lib corelibc.lib ole32.lib 
oleaut32.lib uuid.lib commctrl.lib )
+SET(CMAKE_EXE_LINKER_FLAGS_INIT ${CMAKE_EXE_LINKER_FLAGS_INIT} 
/NODEFAULTLIB:oldnames.lib)
+  ELSE(CMAKE_SYSTEM_NAME MATCHES WindowsCE)
+SET(CMAKE_PLATFORM_DEFINES /DWIN32)
+SET(CMAKE_DEBUG_PLATFORM_DEFINES /RTC1)
+SET(CMAKE_C_STANDARD_LIBRARIES_INIT kernel32.lib user32.lib gdi32.lib 
winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib 
advapi32.lib )
+  ENDIF(CMAKE_SYSTEM_NAME MATCHES WindowsCE)
+
   SET(CMAKE_BUILD_TYPE_INIT Debug)
-  SET (CMAKE_CXX_FLAGS_INIT /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR)
-  SET (CMAKE_CXX_FLAGS_DEBUG_INIT /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1)
+  SET (CMAKE_CXX_FLAGS_INIT ${CMAKE_PLATFORM_DEFINES} /D_WINDOWS /W3 /Zm1000 
/EHsc /GR)
+  SET (CMAKE_CXX_FLAGS_DEBUG_INIT ${CMAKE_DEBUG_PLATFORM_DEFINES} /D_DEBUG 
/MDd /Zi /Ob0 /Od)
   SET (CMAKE_CXX_FLAGS_MINSIZEREL_INIT /MD /O1 /Ob1 /D NDEBUG)
   SET (CMAKE_CXX_FLAGS_RELEASE_INIT /MD /O2 /Ob2 /D NDEBUG)
   SET (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT /MD /Zi /O2 /Ob1 /D NDEBUG)
-  SET (CMAKE_C_FLAGS_INIT /DWIN32 /D_WINDOWS /W3 /Zm1000)
-  SET (CMAKE_C_FLAGS_DEBUG_INIT /D_DEBUG /MDd /Zi  /Ob0 /Od /RTC1)
+  SET (CMAKE_C_FLAGS_INIT ${CMAKE_PLATFORM_DEFINES} /D_WINDOWS /W3 /Zm1000)
+  SET (CMAKE_C_FLAGS_DEBUG_INIT ${CMAKE_DEBUG_PLATFORM_DEFINES} /D_DEBUG /MDd 
/Zi  /Ob0 /Od)
   SET (CMAKE_C_FLAGS_MINSIZEREL_INIT /MD /O1 /Ob1 /D NDEBUG)
   SET (CMAKE_C_FLAGS_RELEASE_INIT /MD /O2 /Ob2 /D NDEBUG

[cmake-developers] [PATCH] Cleanup AddPlatformDefinitions() of Visual Studio generators

[Patrick Gansterer]

see attached patch

-- PatrickFrom 3ffb686016a7ba40688d28da8974609bf6c5d673 Mon Sep 17 00:00:00 2001
From: Patrick Gansterer par...@paroga.com
Date: Sat, 14 Jul 2012 09:38:54 +0200
Subject: [PATCH] Cleanup AddPlatformDefinitions() of Visual Studio
 generators

Move adding of definitions into cmGlobalVisualStudioGenerator to
share code and avoid duplicate architecture string literals.
---
 Source/cmGlobalVisualStudio10Generator.cxx  |9 +
 Source/cmGlobalVisualStudio10Generator.h|1 -
 Source/cmGlobalVisualStudio10IA64Generator.cxx  |3 +--
 Source/cmGlobalVisualStudio10Win64Generator.cxx |3 +--
 Source/cmGlobalVisualStudio11ARMGenerator.cxx   |   15 ++-
 Source/cmGlobalVisualStudio11ARMGenerator.h |4 +---
 Source/cmGlobalVisualStudio11Generator.cxx  |9 +
 Source/cmGlobalVisualStudio11Generator.h|1 -
 Source/cmGlobalVisualStudio11Win64Generator.cxx |8 ++--
 Source/cmGlobalVisualStudio11Win64Generator.h   |2 +-
 Source/cmGlobalVisualStudio6Generator.cxx   |5 ++---
 Source/cmGlobalVisualStudio7Generator.cxx   |8 +---
 Source/cmGlobalVisualStudio7Generator.h |1 -
 Source/cmGlobalVisualStudio8Generator.cxx   |   10 +-
 Source/cmGlobalVisualStudio8Generator.h |3 ---
 Source/cmGlobalVisualStudio9Generator.cxx   |9 +
 Source/cmGlobalVisualStudio9Generator.h |1 -
 Source/cmGlobalVisualStudioGenerator.cxx|   14 ++
 Source/cmGlobalVisualStudioGenerator.h  |5 +
 19 files changed, 42 insertions(+), 69 deletions(-)

diff --git a/Source/cmGlobalVisualStudio10Generator.cxx b/Source/cmGlobalVisualStudio10Generator.cxx
index 947a1c9..f8d9de0 100644
--- a/Source/cmGlobalVisualStudio10Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Generator.cxx
@@ -19,6 +19,7 @@
 
 cmGlobalVisualStudio10Generator::cmGlobalVisualStudio10Generator()
 {
+  this-VersionId = MSVC10;
   this-FindMakeProgramFile = CMakeVS10FindMake.cmake;
   std::string vc10Express;
   this-ExpressEdition = cmSystemTools::ReadRegistryValue(
@@ -27,14 +28,6 @@ cmGlobalVisualStudio10Generator::cmGlobalVisualStudio10Generator()
 }
 
 //
-void cmGlobalVisualStudio10Generator::AddPlatformDefinitions(cmMakefile* mf)
-{
-  mf-AddDefinition(MSVC10, 1);
-  mf-AddDefinition(MSVC_C_ARCHITECTURE_ID, X86);
-  mf-AddDefinition(MSVC_CXX_ARCHITECTURE_ID, X86);
-}
-
-//
 void cmGlobalVisualStudio10Generator::WriteSLNHeader(std::ostream fout)
 {
   fout  Microsoft Visual Studio Solution File, Format Version 11.00\n;
diff --git a/Source/cmGlobalVisualStudio10Generator.h b/Source/cmGlobalVisualStudio10Generator.h
index 060cdff..58de7da 100644
--- a/Source/cmGlobalVisualStudio10Generator.h
+++ b/Source/cmGlobalVisualStudio10Generator.h
@@ -38,7 +38,6 @@ public:
   virtual const char* GetName() const {
 return cmGlobalVisualStudio10Generator::GetActualName();}
   static const char* GetActualName() {return Visual Studio 10;}
-  virtual void AddPlatformDefinitions(cmMakefile* mf);
   
   /** Get the documentation entry for this generator.  */
   virtual void GetDocumentation(cmDocumentationEntry entry) const;
diff --git a/Source/cmGlobalVisualStudio10IA64Generator.cxx b/Source/cmGlobalVisualStudio10IA64Generator.cxx
index 5f70f6b..25dd88f 100644
--- a/Source/cmGlobalVisualStudio10IA64Generator.cxx
+++ b/Source/cmGlobalVisualStudio10IA64Generator.cxx
@@ -16,6 +16,7 @@
 //
 cmGlobalVisualStudio10IA64Generator::cmGlobalVisualStudio10IA64Generator()
 {
+  this-ArchitectureId = x64;
 }
 
 //
@@ -33,8 +34,6 @@ void cmGlobalVisualStudio10IA64Generator
 {
   this-cmGlobalVisualStudio10Generator::AddPlatformDefinitions(mf);
   mf-AddDefinition(CMAKE_FORCE_IA64, TRUE);
-  mf-AddDefinition(MSVC_C_ARCHITECTURE_ID, x64);
-  mf-AddDefinition(MSVC_CXX_ARCHITECTURE_ID, x64);
 }
 
 //
diff --git a/Source/cmGlobalVisualStudio10Win64Generator.cxx b/Source/cmGlobalVisualStudio10Win64Generator.cxx
index 49dc473..d0a0c49 100644
--- a/Source/cmGlobalVisualStudio10Win64Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Win64Generator.cxx
@@ -16,6 +16,7 @@
 //
 cmGlobalVisualStudio10Win64Generator::cmGlobalVisualStudio10Win64Generator()
 {
+  this-ArchitectureId = x64;
 }
 
 //
@@ -33,8 +34,6 @@ void cmGlobalVisualStudio10Win64Generator
 {
   this-cmGlobalVisualStudio10Generator::AddPlatformDefinitions(mf);
   mf-AddDefinition(CMAKE_FORCE_WIN64, TRUE);
-  mf-AddDefinition

[cmake-developers] [PATCH] VS: Add support for Windows CE

[Patrick Gansterer]

see attached patches

This considers most of the patches in mantis. It still has some issues, 
but it's easier to post follow up patches to improve an existing code 
base, than starting with nothing.


-- PatrickFrom 67bd522e90cdef9f857f57ecb1f41148c518476e Mon Sep 17 00:00:00 2001
From: Patrick Gansterer par...@paroga.com
Date: Sat, 14 Jul 2012 11:23:34 +0200
Subject: [PATCH 1/4] VS: Support setting correct subsystem and entry point
 for WinCE

WinCE has only one SubSystem. So the WIN32_EXECUTABLE property
must be handled via the EntryPointSymbol in the vcproj files.
---
 Source/cmGlobalVisualStudioGenerator.h   |3 +++
 Source/cmLocalVisualStudio7Generator.cxx |   20 +---
 Source/cmLocalVisualStudio7Generator.h   |1 +
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/Source/cmGlobalVisualStudioGenerator.h 
b/Source/cmGlobalVisualStudioGenerator.h
index f2fbefd..5c8228a 100644
--- a/Source/cmGlobalVisualStudioGenerator.h
+++ b/Source/cmGlobalVisualStudioGenerator.h
@@ -69,6 +69,9 @@ public:
   i.e. Can I build Debug and Release in the same tree? */
   virtual bool IsMultiConfig() { return true; }
 
+  /** Return true if building for Windows CE */
+  virtual bool TargetsWindowsCE() const { return false; }
+
   class TargetSet: public std::setcmTarget* {};
   struct TargetCompare
   {
diff --git a/Source/cmLocalVisualStudio7Generator.cxx 
b/Source/cmLocalVisualStudio7Generator.cxx
index f2ab79d..5d0d4d6 100644
--- a/Source/cmLocalVisualStudio7Generator.cxx
+++ b/Source/cmLocalVisualStudio7Generator.cxx
@@ -229,6 +229,9 @@ void cmLocalVisualStudio7Generator
   this-FortranProject =
 static_castcmGlobalVisualStudioGenerator*(this-GlobalGenerator)
 -TargetIsFortranOnly(target);
+  this-WindowsCEProject =
+static_castcmGlobalVisualStudioGenerator*(this-GlobalGenerator)
+-TargetsWindowsCE();
 
   // Intel Fortran for VS10 uses VS9 format .vfproj files.
   VSVersion realVersion = this-Version;
@@ -1172,6 +1175,8 @@ void 
cmLocalVisualStudio7Generator::OutputBuildTool(std::ostream fout,
 cmComputeLinkInformation cli = *pcli;
 const char* linkLanguage = cli.GetLinkLanguage();
 
+bool isWin32Executable = target.GetPropertyAsBool(WIN32_EXECUTABLE);
+
 // Compute the variable name to lookup standard libraries for this
 // language.
 std::string standardLibsVar = CMAKE_;
@@ -1219,15 +1224,24 @@ void 
cmLocalVisualStudio7Generator::OutputBuildTool(std::ostream fout,
   {
   fout  \t\t\t\tGenerateDebugInformation=\TRUE\\n;
   }
-if ( target.GetPropertyAsBool(WIN32_EXECUTABLE) )
+if ( this-WindowsCEProject )
+  {
+  fout  \t\t\t\tSubSystem=\9\\n
+\t\t\t\tEntryPointSymbol=\
+(isWin32Executable ? WinMainCRTStartup : mainACRTStartup)
+\\n;
+  }
+else if ( this-FortranProject )
   {
   fout  \t\t\t\tSubSystem=\
-(this-FortranProject? subSystemWindows : 2)  \\n;
+(isWin32Executable ? subSystemWindows : subSystemConsole)
+\\n;
   }
 else
   {
   fout  \t\t\t\tSubSystem=\
-(this-FortranProject? subSystemConsole : 1)  \\n;
+(isWin32Executable ? 2 : 1)
+\\n;
   }
 std::string stackVar = CMAKE_;
 stackVar += linkLanguage;
diff --git a/Source/cmLocalVisualStudio7Generator.h 
b/Source/cmLocalVisualStudio7Generator.h
index 9aa408e..9ce25df 100644
--- a/Source/cmLocalVisualStudio7Generator.h
+++ b/Source/cmLocalVisualStudio7Generator.h
@@ -122,6 +122,7 @@ private:
   cmVS7FlagTable const* ExtraFlagTable;
   std::string ModuleDefinitionFile;
   bool FortranProject;
+  bool WindowsCEProject;
   std::string PlatformName; // Win32 or x64 
   cmLocalVisualStudio7GeneratorInternals* Internal;
 };
-- 
1.7.10.msysgit.1

From 910b9b6feec9a48fda5751d84f238005fee8db79 Mon Sep 17 00:00:00 2001
From: Patrick Gansterer par...@paroga.com
Date: Sat, 14 Jul 2012 11:49:12 +0200
Subject: [PATCH 2/4] VS: Added cmGlobalGenerator::AddTryCompileCacheEntries()

---
 Source/cmGlobalGenerator.h |3 +++
 Source/cmMakefile.cxx  |1 +
 2 files changed, 4 insertions(+)

diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index ce91793..ebf3d80 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -50,6 +50,9 @@ public:
   /** Get the documentation entry for this generator.  */
   virtual void GetDocumentation(cmDocumentationEntry entry) const;
 
+  ///! Add inital cache entries for TryCompile.
+  virtual void AddTryCompileCacheEntries(cmake cm) { };
+
   /**
* Create LocalGenerators and process the CMakeLists files. This does not
* actually produce any makefiles, DSPs, etc.
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 7b6c450..0c13534 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -2948,6 +2948,7 @@ int cmMakefile::TryCompile(const char *srcdir, const char *bindir,
   cm.SetStartOutputDirectory(bindir

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

On Sat, 14 Jul 2012 21:08:24 +0200, Rolf Eike Beer wrote:
-in Modules/Platform/Windows-cl.cmake you initialize some variables 
in both
branches of an if(). You should keep the order you set them the same 
in both

branches as is makes comparing this much easier.


Where exactly? I don't find it. :-/


-you don't set CMAKE_DEBUG_PLATFORM_DEFINES for WinCE. I don't know
if that is
a bug or intentional. If it is a bug then set it, otherwise I would 
add a

comment why this isn't needed.


The WinCE compier has no support for /RTC1.

This patch also includes the changes mentioned in 
http://public.kitware.com/pipermail/cmake-developers/2011-November/002510.html.


-- Patrick
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

Am 14.07.2012 um 22:08 schrieb David Cole:

 On Sat, Jul 14, 2012 at 3:30 PM, Patrick Gansterer par...@paroga.com wrote:
 Hi,
 
 
 On Sat, 14 Jul 2012 21:08:24 +0200, Rolf Eike Beer wrote:
 -in Modules/Platform/Windows-cl.cmake you initialize some variables in both
 branches of an if(). You should keep the order you set them the same in both
 branches as is makes comparing this much easier.
 
 Where exactly? I don't find it. :-/
 
 
 -you don't set CMAKE_DEBUG_PLATFORM_DEFINES for WinCE. I don't know
 if that is
 a bug or intentional. If it is a bug then set it, otherwise I would add a
 comment why this isn't needed.
 
 The WinCE compier has no support for /RTC1.
 
 This patch also includes the changes mentioned in 
 http://public.kitware.com/pipermail/cmake-developers/2011-November/002510.html.
 
 -- Patrick
 
 --
 
 Powered by www.kitware.com
 
 Visit other Kitware open-source projects at 
 http://www.kitware.com/opensource/opensource.html
 
 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
 
 
 Patrick,
 
 Thanks for your work on this. I'll review this stuff on Monday or Tuesday and 
 apply the patches and merge to next if all looks well.
 
 Part of the problem I've always had with other platform support on Windows 
 or Visual Studio is that we have literally ZERO dashboard coverage of these 
 platforms.
 
 Is there any way you (or somebody else who cares about these platforms) can 
 set up a CMake dashboard to test the platform and to make sure that it 
 submits nightly so that if we change something surrounding this code, we have 
 a chance at catching unintended breakages *before* we make a CMake release?

I'll have a look at it and try to set something up.

 
 This thread, or one like it, probably deserves a cc to the users list as well 
 to see if somebody there can submit such dashboards. From the activity in 
 mantis, it does seem to be a popular issue. Lots of folks will be glad to see 
 stuff like this go in.

-- Patrick

--

Powered by www.kitware.com

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

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

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

[cmake-developers] NSIS auto-uninstall old before installing new

[Patrick Gansterer]

Hi,

can someone have a look at my patch at [1]? The version version is now about an 
year (!) old. 
Are there any plans to use Gerrit at [2] for CMake too, so there is a central 
place for all open patches?

[1] http://public.kitware.com/Bug/view.php?id=9946
[2] http://review.source.kitware.com/

- Patrick 
--

Powered by www.kitware.com

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

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

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

[cmake-developers] [PATCH] Added very basic Windows CE Makefile support

[Patrick Gansterer]

Hi,

I've created a very simple patch to add the basic support for WindowsCE to 
CMake.
I does not provide any automatically architecture detection or so on, but 
enables user to use a vanilla CMake for compiling Windows CE projects.
If the patch gets accepted I'll write a few lines into the wiki.

- Patrick



0001-Added-very-basic-Windows-CE-Makefile-support.patch
Description: Binary data
--

Powered by www.kitware.com

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

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

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