MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007919CMakeModulespublic2008-11-03 05:572013-10-07 10:09
ReporterAndreas Pokorny 
Assigned ToBrad King 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionCMake 2.8.11Fixed in VersionCMake 2.8.11 
Summary0007919: Patch for Windows Platform files to add WinCE support with NMake
DescriptionThese patch files add:
 * Platform/WinCE.cmake which only includes Windows
 * Platform/WinCE-cl.cmake which only includes Windows-cl
 * CMakeTestCLMachineType.c - test case for cl and dumpbin

Modified:
 * Windows-cl.cmake
  - now uses dumpbin to detect the binary format cl creates
  - adds several IF - ELSE - ENDIF blocks to make WINCE specific
  - removed the former 64bit check

The patch is against cmake-2.6.2.tar.gz since I do not have CVS access
through our company proxy :(.





Steps To Reproduce
Additional InformationTo make proper use of these files the environment must be configured properly!
That means %INCLUDE% %LIB% must be configured in a way that the cl picked by
the toolchain file finds the includes and libs of the SDK. I.e. you will need
something like:
INCLUDE=c:\Programme\Windows CE Tools\wce500\WINCE5.0_EN\Include\ARMV4I\;%INCLUDE%
LIB=c:\Programme\Windows CE Tools\wce500\WINCE5.0_EN\Lib\ARMV4I\;%LIB%

Furthermore the toolchain file should pick a valid System Version. Like:
SET(CMAKE_SYSTEM_VERSION 5.02)
This version number will be used in the linker commands and set as macros:
 UNDER_CE=0x502
 _WIN32_WCE=0x0502
TagsNo tags attached.
Relationships
related to 0008486closed Kitware Robot Additional platforms support (Windows CE and Symbian) 
has duplicate 0008102closed  CMake support for mobile platforms in Visual Studio 2005/2008 
related to 0014083closed Patrick R. Gansterer WinCE generators should not default to THUMB for ARMV4 SDKs 
related to 0014088closed Patrick R. Gansterer WinCE Visual Studio generators emit incorrect project if /ENTRY option is changed 
Attached Filespatch modules.patch (12,898) 2008-11-03 05:57
https://public.kitware.com/Bug/file/1822/modules.patch
patch modules_2.patch (10,563) 2008-11-10 10:09
https://public.kitware.com/Bug/file/1841/modules_2.patch
patch modules_3.patch (11,389) 2008-12-15 10:03
https://public.kitware.com/Bug/file/1912/modules_3.patch
patch WinCESupport.patch (101,049) 2009-04-15 12:37
https://public.kitware.com/Bug/file/2162/WinCESupport.patch
patch WinCESupportGeneratorSelection.patch (103,457) 2009-04-16 11:52
https://public.kitware.com/Bug/file/2163/WinCESupportGeneratorSelection.patch
patch WinCENoToolchainFile.patch (106,733) 2009-04-17 09:45
https://public.kitware.com/Bug/file/2166/WinCENoToolchainFile.patch
patch devenv-before-VCExpress.patch (1,120) 2009-04-18 13:26
https://public.kitware.com/Bug/file/2168/devenv-before-VCExpress.patch
patch wince-cmakefiles-support.patch (11,657) 2009-04-18 13:26
https://public.kitware.com/Bug/file/2169/wince-cmakefiles-support.patch
patch wince-generators.patch (69,451) 2009-04-18 13:27
https://public.kitware.com/Bug/file/2170/wince-generators.patch
patch wince-tests.patch (24,444) 2009-04-18 13:27
https://public.kitware.com/Bug/file/2171/wince-tests.patch
patch devenv-before-VCExpress-2.patch (2,804) 2009-04-28 09:23
https://public.kitware.com/Bug/file/2192/devenv-before-VCExpress-2.patch
patch wince-cmakefiles-support-2.patch (13,399) 2009-04-28 09:23
https://public.kitware.com/Bug/file/2193/wince-cmakefiles-support-2.patch
patch generator-factory.patch (6,681) 2009-04-28 09:24
https://public.kitware.com/Bug/file/2194/generator-factory.patch
patch wince-generators-2.patch (66,632) 2009-04-28 09:24
https://public.kitware.com/Bug/file/2195/wince-generators-2.patch
patch wince-tests-2.patch (25,375) 2009-04-28 09:24
https://public.kitware.com/Bug/file/2196/wince-tests-2.patch
patch devenv-before-VCExpress-3.patch (2,812) 2009-05-15 12:42
https://public.kitware.com/Bug/file/2253/devenv-before-VCExpress-3.patch
patch devenv.modified_search_order.patch (3,002) 2009-05-25 18:48
https://public.kitware.com/Bug/file/2268/devenv.modified_search_order.patch
patch wince-cmakefiles-supprt-3.patch (11,911) 2009-05-26 17:40
https://public.kitware.com/Bug/file/2272/wince-cmakefiles-supprt-3.patch
patch 0001-applied-adapted-generator-factory.patch.patch (7,057) 2010-03-09 14:37
https://public.kitware.com/Bug/file/2942/0001-applied-adapted-generator-factory.patch.patch
patch 0002-applied-wince-generators-2.patch.patch (60,888) 2010-03-09 14:37
https://public.kitware.com/Bug/file/2943/0002-applied-wince-generators-2.patch.patch
patch 0003-applied-wince-cmakefiles-supprt-3.patch.patch (12,533) 2010-03-09 14:37
https://public.kitware.com/Bug/file/2944/0003-applied-wince-cmakefiles-supprt-3.patch.patch
patch 0001-Add-WindowsCE-defines-to-Windows-MSVC.cmake.patch (1,418) 2012-10-25 08:30
https://public.kitware.com/Bug/file/4536/0001-Add-WindowsCE-defines-to-Windows-MSVC.cmake.patch
patch 0002-Added-cmGlobalGenerator-AddTryCompileCacheEntries.patch (1,393) 2012-10-25 08:31
https://public.kitware.com/Bug/file/4537/0002-Added-cmGlobalGenerator-AddTryCompileCacheEntries.patch
patch 0003-Added-logic-for-CMAKE_WINCE_SDK-CacheEntry.patch (9,610) 2012-10-25 08:31
https://public.kitware.com/Bug/file/4538/0003-Added-logic-for-CMAKE_WINCE_SDK-CacheEntry.patch
Issue History
Date ModifiedUsernameFieldChange
2008-11-03 05:57Andreas PokornyNew Issue
2008-11-03 05:57Andreas PokornyFile Added: modules.patch
2008-11-05 17:39Bill HoffmanStatusnew => assigned
2008-11-05 17:39Bill HoffmanAssigned To => Alex Neundorf
2008-11-05 17:48Alex NeundorfNote Added: 0014039
2008-11-05 17:50Alex NeundorfNote Added: 0014040
2008-11-10 07:21Andreas PokornyNote Added: 0014079
2008-11-10 10:09Andreas PokornyFile Added: modules_2.patch
2008-12-15 09:26Andreas PokornyNote Added: 0014336
2008-12-15 10:03Andreas PokornyFile Added: modules_3.patch
2008-12-15 10:03Andreas PokornyNote Added: 0014337
2008-12-15 17:10Alex NeundorfNote Added: 0014355
2009-01-10 09:40Alex NeundorfCategoryCMake => Modules
2009-01-10 10:01Alex NeundorfNote Added: 0014524
2009-02-11 12:57Brad KingRelationship addedrelated to 0008486
2009-02-24 09:04Andreas PokornyNote Added: 0015324
2009-04-15 12:37Andreas PokornyFile Added: WinCESupport.patch
2009-04-15 12:41Andreas PokornyNote Added: 0016029
2009-04-15 12:44Andreas PokornyNote Added: 0016030
2009-04-16 11:52Andreas PokornyFile Added: WinCESupportGeneratorSelection.patch
2009-04-17 09:45Andreas PokornyFile Added: WinCENoToolchainFile.patch
2009-04-17 09:46Andreas PokornyNote Added: 0016050
2009-04-18 13:18Alex NeundorfNote Added: 0016053
2009-04-18 13:26Alex NeundorfFile Added: devenv-before-VCExpress.patch
2009-04-18 13:26Alex NeundorfFile Added: wince-cmakefiles-support.patch
2009-04-18 13:27Alex NeundorfFile Added: wince-generators.patch
2009-04-18 13:27Alex NeundorfFile Added: wince-tests.patch
2009-04-18 13:44Alex NeundorfNote Added: 0016054
2009-04-18 15:00Andreas PokornyNote Added: 0016055
2009-04-18 15:05Andreas PokornyNote Added: 0016056
2009-04-18 15:15Alex NeundorfNote Added: 0016057
2009-04-20 12:57Andreas PokornyNote Added: 0016084
2009-04-20 16:57Alex NeundorfNote Added: 0016090
2009-04-20 16:57Alex NeundorfNote Added: 0016091
2009-04-21 03:09Andreas PokornyNote Added: 0016095
2009-04-21 05:29Andreas PokornyNote Added: 0016100
2009-04-21 06:03Andreas PokornyNote Added: 0016101
2009-04-21 09:56Alex NeundorfNote Added: 0016113
2009-04-21 10:34Andreas PokornyNote Added: 0016117
2009-04-21 11:43Andreas PokornyNote Added: 0016119
2009-04-28 09:23Andreas PokornyFile Added: devenv-before-VCExpress-2.patch
2009-04-28 09:23Andreas PokornyFile Added: wince-cmakefiles-support-2.patch
2009-04-28 09:24Andreas PokornyFile Added: generator-factory.patch
2009-04-28 09:24Andreas PokornyFile Added: wince-generators-2.patch
2009-04-28 09:24Andreas PokornyFile Added: wince-tests-2.patch
2009-04-28 09:27Andreas PokornyNote Added: 0016212
2009-04-30 08:32Alex NeundorfNote Added: 0016266
2009-04-30 10:06Andreas PokornyNote Added: 0016269
2009-05-09 18:45Alex NeundorfNote Added: 0016363
2009-05-09 18:55Alex NeundorfNote Added: 0016364
2009-05-11 05:57Andreas PokornyNote Added: 0016368
2009-05-11 06:02Alex NeundorfNote Added: 0016369
2009-05-11 08:55Andreas PokornyNote Added: 0016370
2009-05-12 06:13Andreas PokornyNote Added: 0016394
2009-05-12 14:54Alex NeundorfNote Added: 0016406
2009-05-15 12:42Andreas PokornyFile Added: devenv-before-VCExpress-3.patch
2009-05-15 12:43Andreas PokornyNote Added: 0016481
2009-05-25 18:48Alex NeundorfFile Added: devenv.modified_search_order.patch
2009-05-25 18:49Alex NeundorfNote Added: 0016562
2009-05-26 03:43Andreas PokornyNote Added: 0016563
2009-05-26 17:40Alex NeundorfFile Added: wince-cmakefiles-supprt-3.patch
2009-06-05 13:05David ColeRelationship addedrelated to 0008102
2009-06-28 06:09Alex NeundorfNote Added: 0016768
2009-06-29 10:35Brad KingNote Added: 0016775
2009-06-29 11:58Andreas PokornyNote Added: 0016776
2009-06-29 12:09Brad KingNote Added: 0016777
2009-06-30 03:21Andreas PokornyNote Added: 0016781
2009-06-30 09:20Brad KingNote Added: 0016784
2009-06-30 10:29Andreas PokornyNote Added: 0016785
2009-06-30 11:07Brad KingNote Added: 0016786
2009-06-30 11:43Andreas PokornyNote Added: 0016787
2009-07-24 03:31Andreas PokornyNote Added: 0016955
2009-07-28 09:46Alex NeundorfNote Added: 0016982
2009-07-28 10:55Andreas PokornyNote Added: 0016983
2009-07-28 11:06Brad KingNote Added: 0016984
2009-09-12 02:18Alex NeundorfNote Added: 0017405
2009-09-12 06:56Andreas PokornyNote Added: 0017409
2009-09-23 11:46Andreas PokornyNote Added: 0017732
2010-03-09 14:37Sebastian HerbstFile Added: 0001-applied-adapted-generator-factory.patch.patch
2010-03-09 14:37Sebastian HerbstFile Added: 0002-applied-wince-generators-2.patch.patch
2010-03-09 14:37Sebastian HerbstFile Added: 0003-applied-wince-cmakefiles-supprt-3.patch.patch
2010-03-09 14:39Sebastian HerbstNote Added: 0019779
2010-08-31 15:26David ColeNote Added: 0022022
2010-11-10 13:01David ColeTarget Version => CMake 2.8.4
2011-01-06 16:35David ColeNote Added: 0024487
2011-01-06 16:36David ColeTarget VersionCMake 2.8.4 =>
2011-05-25 16:12Alex NeundorfNote Added: 0026580
2011-05-25 16:12Alex NeundorfAssigned ToAlex Neundorf =>
2011-05-25 16:12Alex NeundorfStatusassigned => backlog
2011-07-18 08:21Andreas PokornyNote Added: 0027053
2011-11-23 17:28tomdeblauweNote Added: 0027854
2011-11-28 11:35Brad KingNote Added: 0027857
2012-10-18 07:01ArtemNote Added: 0031258
2012-10-18 11:41Brad KingNote Added: 0031273
2012-10-25 08:30ArtemFile Added: 0001-Add-WindowsCE-defines-to-Windows-MSVC.cmake.patch
2012-10-25 08:31ArtemFile Added: 0002-Added-cmGlobalGenerator-AddTryCompileCacheEntries.patch
2012-10-25 08:31ArtemFile Added: 0003-Added-logic-for-CMAKE_WINCE_SDK-CacheEntry.patch
2012-10-25 08:49ArtemNote Added: 0031315
2012-10-25 08:52ArtemNote Edited: 0031315bug_revision_view_page.php?bugnote_id=31315#r869
2012-10-25 08:53Brad KingNote Added: 0031317
2012-11-28 16:10Brad KingNote Added: 0031750
2012-11-28 16:10Brad KingAssigned To => Brad King
2012-11-28 16:10Brad KingStatusbacklog => resolved
2012-11-28 16:10Brad KingResolutionopen => fixed
2012-11-28 16:10Brad KingFixed in Version => CMake 2.8.11
2012-11-28 16:10Brad KingTarget Version => CMake 2.8.11
2012-11-28 16:12Brad KingRelationship replacedhas duplicate 0008102
2013-04-15 09:49Brad KingRelationship addedrelated to 0014083
2013-04-15 10:55Brad KingRelationship addedrelated to 0014088
2013-10-07 10:09Robert MaynardNote Added: 0034032
2013-10-07 10:09Robert MaynardStatusresolved => closed

Notes
(0014039)
Alex Neundorf   
2008-11-05 17:48   
Some comments/questions:
WinCE.cmake/WinCE-cl.cmake: since CMAKE_SYSTEM_VERSION is used for something real, can you add a check to see it has a valid value ?

What does the combination of dumpbin and Modules/CMakeTestCLMachineType.c do ?

Why did you remove the 64bit check ? If it was replaced, by what ?

It would be nice if Win-cl.cmake would actually get smaller instead of bigger. Can you modularize it in some way to achieve this ? E.g. move settings for WinCE into WinCE-cl.make etc.

Alex
(0014040)
Alex Neundorf   
2008-11-05 17:50   
The message() for the default stacksize shouldn't appear always. Also you could maybe set the default stacksize for WinCE for something smaller ?

Alex
(0014079)
Andreas Pokorny   
2008-11-10 07:21   
dumpbin prints something like:
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.


Dump of file C:\Programme\Microsoft Platform SDK\test.obj

File Type: COFF OBJECT

FILE HEADER VALUES
            8664 machine (x64)
               3 number of sections
        4918104B time date stamp Mon Nov 10 11:43:23 2008
             138 file pointer to symbol table
               8 number of symbols
               0 size of optional header
               0 characteristics
[...]

The cmake script searches for the line with machine(?), and uses this value for
the linker call within in the /machine parameter.
The 64bit check is hence integrated into the check of the dumpbin output. I.e. if cl is a 64bit compiler the resulting machine value will be "x64" instead of
"x86". In some cases there is a mismatch between the dumpbin value and the /machine parameter:

dumpbin: x86|x64|ARM
machine: i386|x64|THUMB

I need some more time with the version number check. I will send an update this evening.

Regarding stacksize. It seems like that the setting is used to set the maximum stacksize on Windows. Hence the initial stacksize is probably smaller. So 10MB is a "safe" value. Thats why I also removed the message, But I doubt that the WinCE memory management is as good as the one of windows. Is 64kb a reasonable default?
(0014336)
Andreas Pokorny   
2008-12-15 09:26   
Any news?
(0014337)
Andreas Pokorny   
2008-12-15 10:03   
I just made yet another little patch to the patch
(0014355)
Alex Neundorf   
2008-12-15 17:10   
I didn't forget you, it's currently just quite busy in KDE4 land (the 4.2 release is coming nearer), so I don't have much time left right now. Nevertheless you're quite high on my TODO.

Alex
(0014524)
Alex Neundorf   
2009-01-10 10:01   
Will check again after cmake 2.6.3 is released.

Alex
(0015324)
Andreas Pokorny   
2009-02-24 09:04   
*ping*.

cmake 2.6.3 was just released if I am not mistaken :).

Andreas
(0016029)
Andreas Pokorny   
2009-04-15 12:41   
I just uploaded a new version of the patch. Now the changes of Clemens from http://cmake.org/Bug/view.php?id=8102 [^] have been integrated. There are changes to that version of the patch:
 * The mainCRTStartup functions have been removed - instead the subsystem and EntrPoint is properly set - even for TRY_COMPILE calls.
 * UNDER_CE is set to $(CEVER) when building for WinCE using a Visual Studio generator.
 * The respective arch and Instruction set macros are set automatically based on the Visual Studio macros $(INSTRUCTIONSET) $(ARCHFAM) and $(_ARCHFAM_) but only when generating with a Visual Studio Generator.
(0016030)
Andreas Pokorny   
2009-04-15 12:44   
PS: just discovered a bug. For some reason INSTURCTIONSET ARCHFAM and _ARCHFAM_ is only set of C++ but not for C projects.
(0016050)
Andreas Pokorny   
2009-04-17 09:46   
Fixed the bugs mentioned above. I improved the patch, now you do not need a toolchain file. The SDK Generators do all important settings on their own.

Can I delete the old patches?
Or mark the most current one?
(0016053)
Alex Neundorf   
2009-04-18 13:18   
Wow, this is a big patch !
I'll split it into multiple smaller ones.

Alex
(0016054)
Alex Neundorf   
2009-04-18 13:44   
Ok, I've split it into four smaller patches.

----------------------------------
devenv-before-VCExpress.cmake:
Andreas: what's the reason for changing the search order of devenv and VCExpress ?
Brad, Bill: can you please have a look whether the changed order is ok to commit ?

----------------------------------
wince-cmakefiles-support.patch
It seems you removed setting CMAKE_CL_64 ?
I think this has to stay for compatibility reasons, somebody may use this in its cmake files.

Are the cross compiler also named "cl.exe" or do they have some prefix/suffix ?
Are they recognized as the MS compilers at the beginning of the cmake run, i.e. when it tries to determine the compiler id ?
This is done by compiling Modules/CMakeCCompilerId.c.in. Is _MSC_VER defined for the cross compilers ?
If so, I would suggest to name the file not WinCE-cl.cmake, but use the "compiler id"-style names, i.e. WinCE-MSVC-C.cmake and WinCE-MSVC-CXX.cmake.

Why do you have this code:
+ IF(CMAKE_CL_MACHINE_TYPE)
+ SET (CMAKE_EXE_LINKER_FLAGS_INIT
+ "${CMAKE_EXE_LINKER_FLAGS_INIT} /machine:${CMAKE_CL_MACHINE_TYPE}")
+ ELSE(CMAKE_CL_MACHINE_TYPE)
+ SET (CMAKE_EXE_LINKER_FLAGS_INIT
+ "${CMAKE_EXE_LINKER_FLAGS_INIT} /machine:i386")
+ ENDIF(CMAKE_CL_MACHINE_TYPE)

Can you for that case just set CMAKE_CL_MACHINE_TYPE to "i386" so we don't need this if() here.

Beside that I think this part looks good.
With this patch it should already be possible to generate a makefile-based project for WinCE ?

-----------------------------
wince-generators.patch:
can you please split this patch into smaller even smaller ones ?
E.g. a first one which introduces the factory, and why introduced this factory.

To the coding style:
-max line length is 79 characters
-there must be no tabs at all in the code (otherwise the commit hook doesn't permit committing)
-indentation always using 2 spaces
-the curly braces are already indented
E.g.:
int DoSomething()
{
  if (foo)
    {
    printf("hello world\n");
    }
  return 0;
}

-----------------------------
wince-tests.patch
I didn't have a closer look, it seems to be quite comprehensive already.

Alex
(0016055)
Andreas Pokorny   
2009-04-18 15:00   
----------------------------------
devenv-before-VCExpress.cmake:

If both are installed, VCExpress is chosen. Then for example try_compile will fail because vcexpress cannot handle Platform tags in the vcproj files. The change only affects people that have both (me :-) ). Most people wont have both.

----------------------------------
wince-cmakefiles-support.patch
> It seems you removed setting CMAKE_CL_64?

This happened probably by accident.

> Are the cross compiler also named "cl.exe" or do they have some prefix/suffix ?

Yes since 2005 they are named cl. Only EVC had an architecture suffix.

> Are they recognized as the MS compilers at the beginning of the cmake run, i.e. when it tries to determine the compiler id ?
> This is done by compiling Modules/CMakeCCompilerId.c.in. Is _MSC_VER defined for the cross compilers ?
> If so, I would suggest to name the file not WinCE-cl.cmake, but use the "compiler id"-style names, i.e. WinCE-MSVC-C.cmake and WinCE-MSVC-CXX.cmake.

Yes they behave exactly like the orignial compiler. I think the link.exe is even the same binary.

> Why do you have this code:
> + IF(CMAKE_CL_MACHINE_TYPE)
> + SET (CMAKE_EXE_LINKER_FLAGS_INIT
> + "${CMAKE_EXE_LINKER_FLAGS_INIT} /machine:${CMAKE_CL_MACHINE_TYPE}")
> + ELSE(CMAKE_CL_MACHINE_TYPE)
> + SET (CMAKE_EXE_LINKER_FLAGS_INIT
> + "${CMAKE_EXE_LINKER_FLAGS_INIT} /machine:i386")
> + ENDIF(CMAKE_CL_MACHINE_TYPE)

Initially I thought I would not evaluate the CMAKE_CL_MACHINE_TYPE when we run the Visual Studio generator, so I thought it might be undefined. But I changed that in the last patches. Thanks for cleaning that up.

> With this patch it should already be possible to generate a makefile-based project for WinCE ?

Yes, with a toolchain file. Similar to the VS SDK Generators, we could also provide a new NMake SDK Generator that even sets the required environment variables for cl and link.exe. The correct contents for the environment can also be found in the WCEplatform.config.xml.

-----------------------------
wince-generators.patch:
> can you please split this patch into smaller even smaller ones ?
> E.g. a first one which introduces the factory, and why introduced this factory.

The two new generators required a constructor parameter. It only simpified the init of the Generator.

Do you have a tool to enforce the indenting? Or maybe a Vim cinoptions setting?
I do not have access to windows / cl during the weekend.
(0016056)
Andreas Pokorny   
2009-04-18 15:05   
Regarding NMake Makefiles for WinCE. Is it possible to modify the environment variables within NMake?
(0016057)
Alex Neundorf   
2009-04-18 15:15   
Is there a shortcut to automatically start a cmd.exe with the env. vars. set up correctly for the intended build ?
That's how it is recommended for using nmake for building native targets, if this also exists for cross compiling we should just recommend running cmake and nmake from such a shell.

Alex
(0016084)
Andreas Pokorny   
2009-04-20 12:57   
Just checked again.
No batch file for CE is provided. You have to write your own env batch file, based on the WCE.VCPlatform.config.
(0016090)
Alex Neundorf   
2009-04-20 16:57   
Could you avoid the problem with VCExpress and devenv by checking which one was found and only generate these tags if it wasn't VCExpress ?

Alex
(0016091)
Alex Neundorf   
2009-04-20 16:57   
Does this mean that VCExpress doesn't support crosscompiling ?

Alex
(0016095)
Andreas Pokorny   
2009-04-21 03:09   
VCExpress does not support crosscompiling. But you can have both installed and they can have the same $(VSInstalldir), and the user has not means to select which one should be used by CMake.
(0016100)
Andreas Pokorny   
2009-04-21 05:29   
Just discovered that the visual studio dlls required to run cl or dumpbin are not part of the PATH, hence the patched version of cmake only works from the developer shell.
(0016101)
Andreas Pokorny   
2009-04-21 06:03   
I could fix that by:
 1. not executing the CL-Machine Type test unless generating for NMake.
 2. setting the CMAKE_CL_MACHINE_TYPE for VS out of the SDK config.
 3. If nothing is set CMAKE_CL_MACHINE_TYPE would default to i386, unless forced to 64bit.

Or do you have another idea how I could ensure that dumpbin.exe is executeable?
(0016113)
Alex Neundorf   
2009-04-21 09:56   
> ... hence the patched version of cmake only works from the developer shell.

Didn't you say that there is no batch file for WinCE ?

In general, there should be no regression compared to the present state.
Right now cmake executed not from a developer shell works for the Visual Studio generators, but not for nmake, right ?
And this also is able to detect 32 and 64 bit builds, right ?
This functionality must be preserved.

I think for cross compiling still CMAKE_SYSTEM_NAME should be preset (to "WinCE"). This will cause CMake to "know" that it is cross compiling, and e.g. warn about TRY_RUN()s etc.
It will also make the variable CMAKE_CROSSCOMPILING be set to TRUE.
So e.g. when you look for devenv and VCExpress, you could do:

set(possibleTools devenv)
if(NOT CMAKE_CROSSCOMPILING)
   set(possibleTools ${possibleTools} VCExpress)
endif(NOT CMAKE_CROSSCOMPILING)

find_program(... ${possibleTools} ... )

etc.

Maybe you also only need the dumpbin stuff if CMAKE_CROSSCOMPILING ?
At least the 64bit-detection must still work as good as it does today.

Another idea:
once you found devenv, maybe you can set the env.var. PATH before executing dumpbin so it finds the necessary dlls ?
This can be done via
set(ENV{PATH} c:/some/location)
execute_process( ... dumpbin ...)

Alex
(0016117)
Andreas Pokorny   
2009-04-21 10:34   
Btw: I did not manage to rename WinCE-cl.cmake to WinCE-MSVC-C.cmake. If I do so I run into a hen-egg problem, because the contents of WinCE-cl.cmake and Windows-cl.cmake were acutally evaluating settings required to build and link a simple c program. So I have to ensure that the cmake files are executed prior to CMakeTestCCompiler.cmake.
(0016119)
Andreas Pokorny   
2009-04-21 11:43   
> Another idea:
> once you found devenv, maybe you can set the env.var. PATH before executing dumpbin so it finds the necessary dlls ?
> This can be done via
> set(ENV{PATH} c:/some/location)
> execute_process( ... dumpbin ...)

Wow - saved my day!

I now have nicely indented clean version of CMake. Will create a new patch tomorrow.
(0016212)
Andreas Pokorny   
2009-04-28 09:27   
This is the split up version of the patch.
I also made some cleanups .. removed uncessary code that showed up in previous versions of the SDK generators.
(0016266)
Alex Neundorf   
2009-04-30 08:32   
Why do you change the order of the search directories in devenv-before-VCExpress-2.patch ?

wince-cmakefiles-support-2.patch: instead of
IF(NOT CMAKE_DUMPBIN STREQUAL CMAKE_DUMPBIN-NOTFOUND)
you can simply write:
IF(NOT CMAKE_DUMPBIN)

Beside that, I think we'll put the first two patches to test RSN.
We'll deal with the generator patches will come after that.

Alex
(0016269)
Andreas Pokorny   
2009-04-30 10:06   
I thought it makes more sense that way. The .NET paths are common for Visual Studio 2003, and I assumed the order specifies a preference.
(0016363)
Alex Neundorf   
2009-05-09 18:45   
I don't have Windows here...
Why should the other directories be preferred over the ones from Visual Studio 2003 ?

Alex

P.S. I already committed the part of the patch which changes the order of devenv and VCExpress.
(0016364)
Alex Neundorf   
2009-05-09 18:55   
about wince-cmakefiles-support-2.patch :
I think setting WIN32 and WINCE in WinCE-cl.cmake is unnecessary, since this is already done in WinCE.cmake.

OTOH I think setting CMAKE_WINDOWS_STACKSIZE in WinCE.cmake is unnecessary, since you do this also in WinCE-cl.cmake (where it fits better IMO).

In Windows-cl.cmake: when using FIND_PROGRAM() to find dumpbin, would it make sense to somehow use the path from CMAKE_C_COMPILER or CMAKE_CXX_COMPILER as a hint where to find dumpbin ?

There is a typo: "assuimg"

Can you please check these issues ?
I think then we can give it a test drive.

Alex
(0016368)
Andreas Pokorny   
2009-05-11 05:57   
Agreed.

Agreed

Regarding dumpbin: I wanted to do that, but had problems getting it done. It would be directoryof(CMAKE_C_COMPILER) or directoryof(CMAKE_C_COMPILER)/../../bin.

Shall I send an update?
(0016369)
Alex Neundorf   
2009-05-11 06:02   
Yes, please :-)

And, why should the other directories be preferred over the ones from Visual Studio 2003 ?
(I don't have any Windows around)
 
Alex
(0016370)
Andreas Pokorny   
2009-05-11 08:55   
Well I think the script shouldnt even look in vs7.1 or vs8.0 directories when actually looking for vs9. Maybe the script is also used in a different context, so I just moved the common vs7.1 and vs8.0 behind the vs9 paths.

If the generator produces vs9 project files, but the script searching for devenv finds a vs7 or vs8, compiling will fail. While the other way round should work. I believe vs9 can convert vcproj files of previous versions.
(0016394)
Andreas Pokorny   
2009-05-12 06:13   
I just read the doc of find_program paying more attention to the steps of the search algorithm. Now i think the file should look like that:

FIND_PROGRAM(CMAKE_MAKE_PROGRAM
  NAMES devenv VCExpress
  HINTS
  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\9.0\\Setup\\VS;EnvironmentDirectory]
  [HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\9.0\\Setup;Dbghelp_path]
    "$ENV{ProgramFiles}/Microsoft Visual Studio 9.0/Common7/IDE"
  "$ENV{ProgramFiles}/Microsoft Visual Studio9.0/Common7/IDE"
  "$ENV{ProgramFiles}/Microsoft Visual Studio 9/Common7/IDE"
  "$ENV{ProgramFiles}/Microsoft Visual Studio9/Common7/IDE"
  "$ENV{ProgramFiles} (x86)/Microsoft Visual Studio 9.0/Common7/IDE"
  "$ENV{ProgramFiles} (x86)/Microsoft Visual Studio9.0/Common7/IDE"
  "/Program Files/Microsoft Visual Studio 9.0/Common7/IDE/"
  PATHS
  "$ENV{ProgramFiles} (x86)/Microsoft Visual Studio .NET/Common7/IDE"
  "$ENV{ProgramFiles}/Microsoft Visual Studio .NET/Common7/IDE"
  )
MARK_AS_ADVANCED(CMAKE_MAKE_PROGRAM)
SET(MSVC90 1)
SET(MSVC_VERSION 1500)

The "valid" paths are now in HINTS instead of PATHS, because the installer of visual studio tends to pollute the path environment variable. Since many people have multiple visual studio and or express versions installed the %PATH% variable is very likely to point to the wrong devenv executeable.
(0016406)
Alex Neundorf   
2009-05-12 14:54   
Could you please attach this as a ready-to-apply patch against HEAD so I can just forward it to the Windows-using cmake developers ?

Thanks
Alex
(0016481)
Andreas Pokorny   
2009-05-15 12:43   
There is the update .. at last.
We are in a quite chaotic phase..
(0016562)
Alex Neundorf   
2009-05-25 18:49   
I updated the patch to current HEAD.
I also kept all paths for VS9 which contain just the "9" and not only the ones containing "9.0".
How does it look ?

Alex
(0016563)
Andreas Pokorny   
2009-05-26 03:43   
Looks fine..
(0016768)
Alex Neundorf   
2009-06-28 06:09   
Ok, the devenv-before-VCExpress patch and the devenv.modified_search_order patch have been committed, next is wince-cmakefiles-support.

Alex
(0016775)
Brad King   
2009-06-29 10:35   
The execute_process calls for cl and dumpbin may not be necessary. There is already a framework in place for detecting the target architecture. Currently it is used mostly for detecting sizeof(void*) but on the SGI it also detects o32, n32, and 64-bit ABIs.

Look at the CMakeDetermineCompilerABI.cmake module and the CMakeCompilerABI.h header file. They use the C preprocessor to detect information about the target. It should be simple to add "INFO:machine[...]".
(0016776)
Andreas Pokorny   
2009-06-29 11:58   
I havent found any preprocessor macros defined by CL yet, that would identify the architecture apart from just x86 vs x86_64.
(0016777)
Brad King   
2009-06-29 12:09   
http://msdn.microsoft.com/en-us/library/b0084kay(VS.80).aspx [^]
_M_IX86 - Defined for x86 processors.
_M_X64 - Defined for x64 processors.

There also seems to be an undocumented "_M_AMD64".
(0016781)
Andreas Pokorny   
2009-06-30 03:21   
If there is also _M_ARM _M_SH and _M_MIPS..
... just checked .. There is _M_ARM _M_SH and _M_MIPS! Yay!

Now that I know the names, google helped to find some docs (not all of them are documented, i.e. there is nothing about _M_MIPS):
http://msdn.microsoft.com/en-us/library/aa448763.aspx [^]
http://msdn.microsoft.com/en-us/library/ms253537.aspx [^]

So we have:
_M_IX86
_M_ARM armv4 and higher
_M_ARMT armv4 with thumb mode
_M_SH any renesas/SH
_M_PPC
_M_AMD64
_M_X64
_M_SH_REV arch revision of sh
_M_MIPS

Mips has lots of variants that can be controlled via /QMmipsNN but i could not detect them via the preprocessor yet. There is no _M_MIPS_REV defined.

How is the machine string extracted? Do I need to link the header file to an executeable, or is a plain object file enough?
(0016784)
Brad King   
2009-06-30 09:20   
It's exctracted by file(STRINGS) in the Modules/CMakeDetermineCompilerABI.cmake module. What I'm proposing is to modify that module to also look for INFO:machine and to set a variable like CMAKE_${lang}_COMPILER_ARCHITECTURE. This is not a WinCE-specific solution but a general one.
(0016785)
Andreas Pokorny   
2009-06-30 10:29   
Looks simple so far.

Then where would I do things like adding /MACHINE:FOOBAR to the linker flags? At the moment I do that inside Windows-cl.cmake.
(0016786)
Brad King   
2009-06-30 11:07   
Ugh, that makes it not simple. There is a chicken-and-egg problem caused by the low granularity of the CMake platform files. The CMakeDetermineCompilerABI.cmake module gets loaded by CMakeTest(LANG)Compiler.cmake which runs *after* Windows-cl.cmake, so it is too late (the purpose of the CMakeTest(LANG)Compiler.cmake module is to make sure CMake knows how to generate build rules for the target platform, which it doesn't know until after Windows-cl.cmake is loaded).

The compiler-specific files like Windows-cl.cmake were originally supposed to only *provide* memorized information, rather than *detect* it. This is the second time recently I've encountered a case where that design is not sufficient, but it cannot be addressed without a major overhaul of the platform configuration rules.

Fortunately it may not be necessary to specify /machine at all:

  http://msdn.microsoft.com/en-us/library/5wy54dk2(VS.71).aspx [^]

I think the only reason we started passing /machine is because that's what the VS IDE does. We could probably just take it out.
(0016787)
Andreas Pokorny   
2009-06-30 11:43   
I have to check whether I can really skip this flag for ARM/THUMB. I believe that I had to add it for some strange reason.
(0016955)
Andreas Pokorny   
2009-07-24 03:31   
Can we somehow avoid the link step in try_compile? And extract the ABI info from the object file?
(0016982)
Alex Neundorf   
2009-07-28 09:46   
No. try_compile() always creates an executable. So it's actually more a try_compile_and_link().
Maybe something could be added so that it try_compile() tries to build a statis library instead of an executable.

Alex
(0016983)
Andreas Pokorny   
2009-07-28 10:55   
For the checks that we plan to do, running only the preprocessor would be already sufficient.
(0016984)
Brad King   
2009-07-28 11:06   
Actually it is possible to build a static library with try_compile if you use the signature that accepts a pre-made source tree. However, it doesn't matter in this case. The Windows-cl.cmake platform file is too early to run try_compile. That file is supposed to provide information that CMake uses to implement try_compile.

Until we resolve the chicken-and-egg problem I mention above, I think running the preprocessor with execute_process will be the easiest solution. The main thing I want to avoid is running dumpbin since it needs help to find its DLLs. Using the preprocessor makes this unnecessary.
(0017405)
Alex Neundorf   
2009-09-12 02:18   
What's the current state here ?

Alex
(0017409)
Andreas Pokorny   
2009-09-12 06:56   
I am quite busy at work right now, since the solution is already working nobody complained, hence I can only invest free time. Anyhow the last thing I did, was looking for a generic way of executing the preprocessor instead of try_compile. ...
(0017732)
Andreas Pokorny   
2009-09-23 11:46   
What do you think about taking this code as-is, and refactoring it later?
(0019779)
Sebastian Herbst   
2010-03-09 14:39   
I updated the patches for wince generator support to cmake 2.8.0.
and attached the patches 'git format-patch' produced.
(0022022)
David Cole   
2010-08-31 15:26   
We will not be addressing this for the upcoming CMake 2.8.3 release.

The groundwork for this issue is being laid, but it will not be "finished enough" for inclusion in the 2.8.3 release.
(0024487)
David Cole   
2011-01-06 16:35   
Punting once more into a future release. We are too close to 2.8.4 to even have time to *talk* about this one enough before rc1...

Unsetting "target version" field.
(0026580)
Alex Neundorf   
2011-05-25 16:12   
I can't do more for this one, so I'm un-assigning it.
I think Brad wanted to have some things changed, and to actually get it into cmake, it needs somebody who has the SDK actually installed (which is not me).

Alex
(0027053)
Andreas Pokorny   
2011-07-18 08:21   
I would like to point out that one can easily download a standard wince5 sdk here:
http://www.microsoft.com/download/en/details.aspx?id=17310 [^]

Furthermore there are WinCE6 SDKs available at chip/board vendors, like FreeScale, Nvidia ...

Since 2008 we are using CMake in our company with these patches applied. We also provide source code examples with our software. So we would also like to provide CMake build files as simple solution to our customers...
(0027854)
tomdeblauwe   
2011-11-23 17:28   
Is there a chance any of this will make it into the next release?
(0027857)
Brad King   
2011-11-28 11:35   
Re 0007919:0027854: IIRC there are some implementation problems with the patches that have not been addressed. See 0007919:0016984 and 0007919:0017409.

Further progress will require a volunteer to rebase the patches on master and resolve the concerns already discussed.
(0031258)
Artem   
2012-10-18 07:01   
Hello,

What is the current state for the bug ? Is there another bug according WinCE that will appear in the next release ?
 I've got task to get cmake support WinCE in stock. And I've found that the bug is the most actual one targeting my task. So, am I right that the bug is the most completed and almost ready for release except some issues mentioned by Brad King ?
(0031273)
Brad King   
2012-10-18 11:41   
Several separate efforts have been made on this front. Some progress has been made elsewhere but I do not know how much of this issue it addresses.

There were some minimal WindowsCE platform files contributed recently:

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

See related discussion threads on the developers list here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4328 [^]
 http://www.cmake.org/pipermail/cmake-developers/2012-September/005168.html [^]

It left off with discussion of additional patches to get VS IDE generator support working that have not been finished to the point of acceptance.
(0031315)
Artem   
2012-10-25 08:49   
(edited on: 2012-10-25 08:52)
I've found out that this three patches are enough for my project. It is totally Patrick Gansterer's work from his parogas-cmake/wince project with little modifications during rebasing to the current next.
Is it good start point for windows ce support in the cmake ?
If so, what is the next step ? Should I become maintainer and add this patches to the windows-ce topic that already exists or create new one ?
(0031317)
Brad King   
2012-10-25 08:53   
Re 0007919:0031315: Please join the developer's list:

 http://www.cmake.org/cgi-bin/mailman/listinfo/cmake-developers [^]

and post asking about reviving the rest of Patrick's topic. IIRC the main remaining problem was how to tell CMake's VS IDE generators what architecture to use up front so it could locate the appropriate pieces of the toolchain.
(0031750)
Brad King   
2012-11-28 16:10   
Patrick Gansterer's work has been merged to master:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=581b0c0d [^]

It is now possible to use NMake, VS 8, or VS 9 to build for WinCE.
(0034032)
Robert Maynard   
2013-10-07 10:09   
Closing resolved issues that have not been updated in more than 4 months.