I think that would be the best approach. If you work on it, please ensure
the implementation supports all Windows toolchains on all generators, or at
least those combinations that already support WIN32_EXECUTABLE.
I had a look trough the code. I found that the VS6 generator also sets the
Fixed typo in commit message:
VS, WINCE: Fix entry point for Unicode builds
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=681cda02
I figured out that the combination /ENTRY:mainCRTStartup is also possible even
if UNICODE is enabled.
The question is now what should CMake do as
On 12/09/2014 09:45 AM, Bach, Pascal wrote:
the old behavior was better. The user should then be able to set the
entry point independent of the UNICODE setting via a target property.
This would be similar to how WIN32_EXECUTABLE selects WinMain as
startup.
Good catch
On 10/27/2014 09:11 AM, Brad King wrote:
Tests: Run Tutorial steps 1-4 as tests for Windows CE
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e690d0db
Please take a look at the test failures on your dashboard submission
for these tests.
I'm already on it. I will let you know if
I even would prefer to not hardcode the SDK but I was unable to list key
entries from the registry.
Usually all installed SDKs are listed as subkeys of
HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows CE Tools\\SDKs
in this case it is SDK_AM335X_SK_WEC2013_V310.
I think the test
.
I think the test would be nicer if it checks for available SDKs and just picks
the first.
Any ideas how to do this?
Regards
Pascal
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Dienstag, 21. Oktober 2014 14:58
To: Bach, Pascal; cmake-developers@cmake.org
Thanks. I split that into two commits with slight edits, and added
my own commit to add subsections for Windows Phone and Store:
Help: Add Cross Compiling subsections in cmake-toolchains.7 manual
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d72451a
Help: Add Windows CE
If you don't mind, please precede this patch with a change that
adds such subsection headers for the Clang and QCC cases.
Bellow you find the updated patch, I rearranged the cross compiling section a
bit and added subsections.
Pascal
From 01aa7fd739ff6bdaf05f882199e79549a04f7bda Mon Sep 17
On 09/05/2014 03:53 PM, Brad King wrote:
I think CMAKE_GENERATOR_PLATFORM may be a suitable name. Ideally
this setting should be added as a general-purpose replacement for
putting ARM or Win64 in the generator name. The changes for
that are more sweeping than I'd like to ask of you just
On 09/08/2014 05:35 AM, Pascal Bach wrote:
Even better would be to make the search case insensitive.
How do we know which flags are sensitive to case?
It has nothing to do with Visual Studio as it doesn't care about the casing.
The problem is in the CMake generator. The tables in (eg.
Maybe a better solution would be to do this matching in a case insensitive
way,
this way it would work in any case even with user passed flags in lower
case.
I'm saying that some flags are case sensitive and others are not.
We cannot blindly match all cl flags insensitive to case, for
Those are all for the Makefile and Ninja generators, as are
CMAKE_CREATE_WIN32_EXE and CMAKE_CREATE_CONSOLE_EXE. For VS
generators the knowledge has always been hard-coded, with a
special case for Windows CE:
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalVisual
On 09/09/2014 10:19 AM, Bach, Pascal wrote:
Wouldn't it make sense to use the same variables in the VS10+ Generator
too?
It seems redundant to have the same information again. What's the reason
it is hardcoded?
That's just the way it was written. The rule variables like
CMAKE_${lang
At first I tought the way things work was:
Windows-MSVC.cmake and Co construct a commandline with the required
flags.
The VS generator parses this command line and uses the cmVS7FlagTable
to
translate the known flags to XML elements.
(Unknown arguments get passed as additional
Right, it gets called inside try_compile projects too. Actually
the SDK information will have to be propagated into those too.
That means it needs to go in files like CMakeSystem.cmake or
CMakeCCompiler.cmake that are configured in the build tree,
or be explicitly propagated by
Here is an update version of my patchset:
It also works with older versions of Windows CE but it tells the user that he
might to manually se the CMAKE_PLATFORM_TOOLSET
(I hope the resubmission is OK like this)
From 145c3189abf84aca046f555c5452396f0e5936eb Mon Sep 17 00:00:00 2001
From: Pascal
On 09/05/2014 09:16 AM, Bach, Pascal wrote:
I'm not clear what you mean.
As far as I understand the solution files that do try compile
are generated using the same generator that generates the
final solution file.
A generator with the same name is used but it is not the same
+ else if (this-SystemName == WindowsCE)
+{
+this-SystemIsWindowsCE = true;
+if (!this-InitializeWindowsCE(mf))
At the beginning of this block you should check/reject when
the generator name specified a platform name. Something like:
if(this-PlatformName !=
This won't' work as the code gets called multiple times
Right, it gets called inside try_compile projects too. Actually
the SDK information will have to be propagated into those too.
That means it needs to go in files like CMakeSystem.cmake or
CMakeCCompiler.cmake that are configured in
On 09/02/2014 11:27 AM, Bach, Pascal wrote:
we should now be able to activate cross-compiling
with -DCMAKE_SYSTEM_NAME=WindowsCE or -
DCMAKE_TOOLCHAIN_FILE=...
while still using -G Visual Studio 12 2013 as the generator.
I think proposal would make things cleaner.
Great
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Mittwoch, 3. September 2014 15:35
To: Bach, Pascal
Cc: cmake-developers@cmake.org; Patrick Roland Gansterer
Subject: Re: VS 2013 WindowsCE support
On 09/03/2014 05:23 AM, Bach, Pascal wrote:
elseif
Let's use a name specific to WindowsCE like CMAKE_VS_WINCE_SDK,
I'm not sure this is really Windows CE specific. There is already
an internal variable CMAKE_VS_PLATFORM_NAME that is set to Win32,
Win64, ARM etc. This is also the variable that gets set to the SDK
name. Currently this
is inspired by WindowsPhone and WindowsStore.
Current limitations:
- Only works with Windows CE 8.0
Pascal
-Original Message-
From: Pascal Bach [mailto:pascal.b...@siemens.com]
Sent: Mittwoch, 3. September 2014 19:16
To: cmake-developers@cmake.org
Cc: Bach, Pascal
Subject: [PATCH
Hi Brad
In combination with your related issue report:
WindowsCE: /SUBSYSTEM and /ENTRYPOINT does not end up in the
generated Visual Studio project
http://www.cmake.org/Bug/view.php?id=15115
it looks like a bit of work is needed to get Windows CE support
working with VS 2013. Also,
Hi
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
On Behalf Of Bill Hoffman
Sent: Freitag, 29. August 2014 17:35
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Cross compile tests on open.cdash.org
On 8/29/2014 9:47 AM, Bach
Hi Guys
This is a good idea. There has been some recent work on the windows
phone support: Tests/VSWinStorePhone/. However, I would think what
you would want would be a more comprehensive test of CMake. Most of
the tests run executables that are built. We would either have to not
Hi Everybody
I'm interested in cross compilation, and am already using it extensively for
Linux and Embedded Linux.
But now I ran into some problems cross compiling for Windows Compact Embedded
2013 using Visual Studio.
After some discussion on IRC, Nils Gladitz pointed out that there are no
27 matches
Mail list logo
