View Issue Details [ Jump to Notes ] [ Print ]
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 :(.





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.
Attached Filespatch file icon modules.patch [^] (12,898 bytes) 2008-11-03 05:57 [Show Content]
patch file icon modules_2.patch [^] (10,563 bytes) 2008-11-10 10:09 [Show Content]
patch file icon modules_3.patch [^] (11,389 bytes) 2008-12-15 10:03 [Show Content]
patch file icon WinCESupport.patch [^] (101,049 bytes) 2009-04-15 12:37 [Show Content]
patch file icon WinCESupportGeneratorSelection.patch [^] (103,457 bytes) 2009-04-16 11:52 [Show Content]
patch file icon WinCENoToolchainFile.patch [^] (106,733 bytes) 2009-04-17 09:45 [Show Content]
patch file icon devenv-before-VCExpress.patch [^] (1,120 bytes) 2009-04-18 13:26 [Show Content]
patch file icon wince-cmakefiles-support.patch [^] (11,657 bytes) 2009-04-18 13:26 [Show Content]
patch file icon wince-generators.patch [^] (69,451 bytes) 2009-04-18 13:27 [Show Content]
patch file icon wince-tests.patch [^] (24,444 bytes) 2009-04-18 13:27 [Show Content]
patch file icon devenv-before-VCExpress-2.patch [^] (2,804 bytes) 2009-04-28 09:23 [Show Content]
patch file icon wince-cmakefiles-support-2.patch [^] (13,399 bytes) 2009-04-28 09:23 [Show Content]
patch file icon generator-factory.patch [^] (6,681 bytes) 2009-04-28 09:24 [Show Content]
patch file icon wince-generators-2.patch [^] (66,632 bytes) 2009-04-28 09:24 [Show Content]
patch file icon wince-tests-2.patch [^] (25,375 bytes) 2009-04-28 09:24 [Show Content]
patch file icon devenv-before-VCExpress-3.patch [^] (2,812 bytes) 2009-05-15 12:42 [Show Content]
patch file icon devenv.modified_search_order.patch [^] (3,002 bytes) 2009-05-25 18:48 [Show Content]
patch file icon wince-cmakefiles-supprt-3.patch [^] (11,911 bytes) 2009-05-26 17:40 [Show Content]
patch file icon 0001-applied-adapted-generator-factory.patch.patch [^] (7,057 bytes) 2010-03-09 14:37 [Show Content]
patch file icon 0002-applied-wince-generators-2.patch.patch [^] (60,888 bytes) 2010-03-09 14:37 [Show Content]
patch file icon 0003-applied-wince-cmakefiles-supprt-3.patch.patch [^] (12,533 bytes) 2010-03-09 14:37 [Show Content]
patch file icon 0001-Add-WindowsCE-defines-to-Windows-MSVC.cmake.patch [^] (1,418 bytes) 2012-10-25 08:30 [Show Content]
patch file icon 0002-Added-cmGlobalGenerator-AddTryCompileCacheEntries.patch [^] (1,393 bytes) 2012-10-25 08:31 [Show Content]
patch file icon 0003-Added-logic-for-CMAKE_WINCE_SDK-CacheEntry.patch [^] (9,610 bytes) 2012-10-25 08:31 [Show Content]

 Relationships
related to 0008486closedKitware Robot Additional platforms support (Windows CE and Symbian) 
has duplicate 0008102closed CMake support for mobile platforms in Visual Studio 2005/2008 
related to 0014083closedPatrick R. Gansterer WinCE generators should not default to THUMB for ARMV4 SDKs 
related to 0014088closedPatrick R. Gansterer WinCE Visual Studio generators emit incorrect project if /ENTRY option is changed 

  Notes
(0014039)
Alex Neundorf (developer)
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 (developer)
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 (reporter)
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 (reporter)
2008-12-15 09:26

 Any news?
(0014337)
Andreas Pokorny (reporter)
2008-12-15 10:03

 I just made yet another little patch to the patch
(0014355)
Alex Neundorf (developer)
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 (developer)
2009-01-10 10:01

 Will check again after cmake 2.6.3 is released.

Alex
(0015324)
Andreas Pokorny (reporter)
2009-02-24 09:04

 *ping*.

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

Andreas
(0016029)
Andreas Pokorny (reporter)
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 (reporter)
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 (reporter)
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 (developer)
2009-04-18 13:18

 Wow, this is a big patch !
I'll split it into multiple smaller ones.

Alex
(0016054)
Alex Neundorf (developer)
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 (reporter)
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 (reporter)
2009-04-18 15:05

 Regarding NMake Makefiles for WinCE. Is it possible to modify the environment variables within NMake?
(0016057)
Alex Neundorf (developer)
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 (reporter)
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 (developer)
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 (developer)
2009-04-20 16:57

 Does this mean that VCExpress doesn't support crosscompiling ?

Alex
(0016095)
Andreas Pokorny (reporter)
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 (reporter)
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 (reporter)
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 (developer)
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 (reporter)
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 (reporter)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (reporter)
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 (developer)
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 (reporter)
2009-05-15 12:43

 There is the update .. at last.
We are in a quite chaotic phase..
(0016562)
Alex Neundorf (developer)
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 (reporter)
2009-05-26 03:43

 Looks fine..
(0016768)
Alex Neundorf (developer)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
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 (developer)
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 (reporter)
2009-07-28 10:55

 For the checks that we plan to do, running only the preprocessor would be already sufficient.
(0016984)
Brad King (manager)
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 (developer)
2009-09-12 02:18

 What's the current state here ?

Alex
(0017409)
Andreas Pokorny (reporter)
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 (reporter)
2009-09-23 11:46

 What do you think about taking this code as-is, and refactoring it later?
(0019779)
Sebastian Herbst (reporter)
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 (manager)
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 (manager)
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 (developer)
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 (reporter)
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 (reporter)
2011-11-23 17:28

 Is there a chance any of this will make it into the next release?
(0027857)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (manager)
2013-10-07 10:09

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2008-11-03 05:57 Andreas Pokorny New Issue
2008-11-03 05:57 Andreas Pokorny File Added: modules.patch
2008-11-05 17:39 Bill Hoffman Status new => assigned
2008-11-05 17:39 Bill Hoffman Assigned To => Alex Neundorf
2008-11-05 17:48 Alex Neundorf Note Added: 0014039
2008-11-05 17:50 Alex Neundorf Note Added: 0014040
2008-11-10 07:21 Andreas Pokorny Note Added: 0014079
2008-11-10 10:09 Andreas Pokorny File Added: modules_2.patch
2008-12-15 09:26 Andreas Pokorny Note Added: 0014336
2008-12-15 10:03 Andreas Pokorny File Added: modules_3.patch
2008-12-15 10:03 Andreas Pokorny Note Added: 0014337
2008-12-15 17:10 Alex Neundorf Note Added: 0014355
2009-01-10 09:40 Alex Neundorf Category CMake => Modules
2009-01-10 10:01 Alex Neundorf Note Added: 0014524
2009-02-11 12:57 Brad King Relationship added related to 0008486
2009-02-24 09:04 Andreas Pokorny Note Added: 0015324
2009-04-15 12:37 Andreas Pokorny File Added: WinCESupport.patch
2009-04-15 12:41 Andreas Pokorny Note Added: 0016029
2009-04-15 12:44 Andreas Pokorny Note Added: 0016030
2009-04-16 11:52 Andreas Pokorny File Added: WinCESupportGeneratorSelection.patch
2009-04-17 09:45 Andreas Pokorny File Added: WinCENoToolchainFile.patch
2009-04-17 09:46 Andreas Pokorny Note Added: 0016050
2009-04-18 13:18 Alex Neundorf Note Added: 0016053
2009-04-18 13:26 Alex Neundorf File Added: devenv-before-VCExpress.patch
2009-04-18 13:26 Alex Neundorf File Added: wince-cmakefiles-support.patch
2009-04-18 13:27 Alex Neundorf File Added: wince-generators.patch
2009-04-18 13:27 Alex Neundorf File Added: wince-tests.patch
2009-04-18 13:44 Alex Neundorf Note Added: 0016054
2009-04-18 15:00 Andreas Pokorny Note Added: 0016055
2009-04-18 15:05 Andreas Pokorny Note Added: 0016056
2009-04-18 15:15 Alex Neundorf Note Added: 0016057
2009-04-20 12:57 Andreas Pokorny Note Added: 0016084
2009-04-20 16:57 Alex Neundorf Note Added: 0016090
2009-04-20 16:57 Alex Neundorf Note Added: 0016091
2009-04-21 03:09 Andreas Pokorny Note Added: 0016095
2009-04-21 05:29 Andreas Pokorny Note Added: 0016100
2009-04-21 06:03 Andreas Pokorny Note Added: 0016101
2009-04-21 09:56 Alex Neundorf Note Added: 0016113
2009-04-21 10:34 Andreas Pokorny Note Added: 0016117
2009-04-21 11:43 Andreas Pokorny Note Added: 0016119
2009-04-28 09:23 Andreas Pokorny File Added: devenv-before-VCExpress-2.patch
2009-04-28 09:23 Andreas Pokorny File Added: wince-cmakefiles-support-2.patch
2009-04-28 09:24 Andreas Pokorny File Added: generator-factory.patch
2009-04-28 09:24 Andreas Pokorny File Added: wince-generators-2.patch
2009-04-28 09:24 Andreas Pokorny File Added: wince-tests-2.patch
2009-04-28 09:27 Andreas Pokorny Note Added: 0016212
2009-04-30 08:32 Alex Neundorf Note Added: 0016266
2009-04-30 10:06 Andreas Pokorny Note Added: 0016269
2009-05-09 18:45 Alex Neundorf Note Added: 0016363
2009-05-09 18:55 Alex Neundorf Note Added: 0016364
2009-05-11 05:57 Andreas Pokorny Note Added: 0016368
2009-05-11 06:02 Alex Neundorf Note Added: 0016369
2009-05-11 08:55 Andreas Pokorny Note Added: 0016370
2009-05-12 06:13 Andreas Pokorny Note Added: 0016394
2009-05-12 14:54 Alex Neundorf Note Added: 0016406
2009-05-15 12:42 Andreas Pokorny File Added: devenv-before-VCExpress-3.patch
2009-05-15 12:43 Andreas Pokorny Note Added: 0016481
2009-05-25 18:48 Alex Neundorf File Added: devenv.modified_search_order.patch
2009-05-25 18:49 Alex Neundorf Note Added: 0016562
2009-05-26 03:43 Andreas Pokorny Note Added: 0016563
2009-05-26 17:40 Alex Neundorf File Added: wince-cmakefiles-supprt-3.patch
2009-06-05 13:05 David Cole Relationship added related to 0008102
2009-06-28 06:09 Alex Neundorf Note Added: 0016768
2009-06-29 10:35 Brad King Note Added: 0016775
2009-06-29 11:58 Andreas Pokorny Note Added: 0016776
2009-06-29 12:09 Brad King Note Added: 0016777
2009-06-30 03:21 Andreas Pokorny Note Added: 0016781
2009-06-30 09:20 Brad King Note Added: 0016784
2009-06-30 10:29 Andreas Pokorny Note Added: 0016785
2009-06-30 11:07 Brad King Note Added: 0016786
2009-06-30 11:43 Andreas Pokorny Note Added: 0016787
2009-07-24 03:31 Andreas Pokorny Note Added: 0016955
2009-07-28 09:46 Alex Neundorf Note Added: 0016982
2009-07-28 10:55 Andreas Pokorny Note Added: 0016983
2009-07-28 11:06 Brad King Note Added: 0016984
2009-09-12 02:18 Alex Neundorf Note Added: 0017405
2009-09-12 06:56 Andreas Pokorny Note Added: 0017409
2009-09-23 11:46 Andreas Pokorny Note Added: 0017732
2010-03-09 14:37 Sebastian Herbst File Added: 0001-applied-adapted-generator-factory.patch.patch
2010-03-09 14:37 Sebastian Herbst File Added: 0002-applied-wince-generators-2.patch.patch
2010-03-09 14:37 Sebastian Herbst File Added: 0003-applied-wince-cmakefiles-supprt-3.patch.patch
2010-03-09 14:39 Sebastian Herbst Note Added: 0019779
2010-08-31 15:26 David Cole Note Added: 0022022
2010-11-10 13:01 David Cole Target Version => CMake 2.8.4
2011-01-06 16:35 David Cole Note Added: 0024487
2011-01-06 16:36 David Cole Target Version CMake 2.8.4 =>
2011-05-25 16:12 Alex Neundorf Note Added: 0026580
2011-05-25 16:12 Alex Neundorf Assigned To Alex Neundorf =>
2011-05-25 16:12 Alex Neundorf Status assigned => backlog
2011-07-18 08:21 Andreas Pokorny Note Added: 0027053
2011-11-23 17:28 tomdeblauwe Note Added: 0027854
2011-11-28 11:35 Brad King Note Added: 0027857
2012-10-18 07:01 Artem Note Added: 0031258
2012-10-18 11:41 Brad King Note Added: 0031273
2012-10-25 08:30 Artem File Added: 0001-Add-WindowsCE-defines-to-Windows-MSVC.cmake.patch
2012-10-25 08:31 Artem File Added: 0002-Added-cmGlobalGenerator-AddTryCompileCacheEntries.patch
2012-10-25 08:31 Artem File Added: 0003-Added-logic-for-CMAKE_WINCE_SDK-CacheEntry.patch
2012-10-25 08:49 Artem Note Added: 0031315
2012-10-25 08:52 Artem Note Edited: 0031315
2012-10-25 08:53 Brad King Note Added: 0031317
2012-11-28 16:10 Brad King Note Added: 0031750
2012-11-28 16:10 Brad King Assigned To => Brad King
2012-11-28 16:10 Brad King Status backlog => resolved
2012-11-28 16:10 Brad King Resolution open => fixed
2012-11-28 16:10 Brad King Fixed in Version => CMake 2.8.11
2012-11-28 16:10 Brad King Target Version => CMake 2.8.11
2012-11-28 16:12 Brad King Relationship replaced has duplicate 0008102
2013-04-15 09:49 Brad King Relationship added related to 0014083
2013-04-15 10:55 Brad King Relationship added related to 0014088
2013-10-07 10:09 Robert Maynard Note Added: 0034032
2013-10-07 10:09 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team