Re: [CMake] Updated WinCE CMakefiles
Hello, I am sorry that it took me so long. I made an entry in mantis: http://public.kitware.com/Bug/view.php?id=7919 2008/10/17 Alexander Neundorf <[EMAIL PROTECTED]>: > Can you please post it again > 1) as a patch > 2) for the beginning without the modifications to the generators > > So we can get it in step by step. Thanks for being so patient. kind regards Andreas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
On Tuesday 14 October 2008, Andreas Pokorny wrote: > Hello, > > 2008/10/14 Alexander Neundorf <[EMAIL PROTECTED]>: > > [...] > > For the files in Platform/ : > > > > Why did you create Generic-Windows.cmake and Generic-Windows-cl.cmake ? > > Until now the "Generic-" prefix is used as the name of the "operating > > system" if there is no operating system (i.e. only when cross compiling). > > So reusing it here for Windows feels wrong. > > I'd suggest to just name them Windows.cmake and Windows-cl.cmake again. > > For now reason. I wasnt aware that Generic- would be detected as operating > system string. So I fully aggree. > > > When I had a look at Windows-cl.cmake last year, it relied on the fact > > that it's running on 32 or 64 bit Intel machines, i.e. if it's 32 bit, > > then it's i386, otherwise the 64 bit version. > > It seems you changed that appropriately ? > > The check is now more complex. It assumes that the selected cl compiler > only creates one type of binary. An object file, created by that cl > compiler is analyzed > with dumpbin. The output of dumpbin is parsed and then the machine type > used for link.exe is selected. I hope that new check, and the fact that the > code relies > on the existance of dumpbin.exe (which is searched quite extensively) does > not break existing setups. Can you please post it again 1) as a patch 2) for the beginning without the modifications to the generators So we can get it in step by step. Thanks Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Hello, 2008/10/14 Alexander Neundorf <[EMAIL PROTECTED]>: > [...] > For the files in Platform/ : > > Why did you create Generic-Windows.cmake and Generic-Windows-cl.cmake ? > Until now the "Generic-" prefix is used as the name of the "operating system" > if there is no operating system (i.e. only when cross compiling). So reusing > it here for Windows feels wrong. > I'd suggest to just name them Windows.cmake and Windows-cl.cmake again. For now reason. I wasnt aware that Generic- would be detected as operating system string. So I fully aggree. > > When I had a look at Windows-cl.cmake last year, it relied on the fact that > it's running on 32 or 64 bit Intel machines, i.e. if it's 32 bit, then it's > i386, otherwise the 64 bit version. > It seems you changed that appropriately ? The check is now more complex. It assumes that the selected cl compiler only creates one type of binary. An object file, created by that cl compiler is analyzed with dumpbin. The output of dumpbin is parsed and then the machine type used for link.exe is selected. I hope that new check, and the fact that the code relies on the existance of dumpbin.exe (which is searched quite extensively) does not break existing setups. regards Andreas Pokorny ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
On Tuesday 14 October 2008, Alexander Neundorf wrote: > On Friday 10 October 2008, Clemens Arth wrote: > > Andreas, > > > > sorry but it took me a little longer to get the diff done, but now I > > included some more things I found useful. Currently everything runs fine > > for PPC2003,SP2003,WM5,WM6, and CE5.0, based on your configuration and > > some additional flags set - basically it's all in there what we (or at > > least I) wanted :-) > > Ok, some comments. One more question, how does this relate to this bug report ? http://public.kitware.com/Bug/view.php?id=7434 What do you think about the patch attached there ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
On Friday 10 October 2008, Clemens Arth wrote: > Andreas, > > sorry but it took me a little longer to get the diff done, but now I > included some more things I found useful. Currently everything runs fine > for PPC2003,SP2003,WM5,WM6, and CE5.0, based on your configuration and > some additional flags set - basically it's all in there what we (or at > least I) wanted :-) Ok, some comments. For the files in Platform/ : Why did you create Generic-Windows.cmake and Generic-Windows-cl.cmake ? Until now the "Generic-" prefix is used as the name of the "operating system" if there is no operating system (i.e. only when cross compiling). So reusing it here for Windows feels wrong. I'd suggest to just name them Windows.cmake and Windows-cl.cmake again. When I had a look at Windows-cl.cmake last year, it relied on the fact that it's running on 32 or 64 bit Intel machines, i.e. if it's 32 bit, then it's i386, otherwise the 64 bit version. It seems you changed that appropriately ? For the other files: please post this as a patch, so we can see what the changes compared to original cmake are ? This makes incorporating your work *much* easier. Thanks Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Andreas,
sorry but it took me a little longer to get the diff done, but now I
included some more things I found useful. Currently everything runs fine
for PPC2003,SP2003,WM5,WM6, and CE5.0, based on your configuration and
some additional flags set - basically it's all in there what we (or at
least I) wanted :-)
For enthusiastic users of cmake and Visual Studio like me, there are
some suggestions I'd make for future versions of the generators which I
found to be reasonable. Some of them I have already changed in the
patched version.
First I came across the settings for program optimization. There are
multiple settings, one for the compiler (/GL), one for the linker
(/LTCG), and finally a global flag to be enabled for the configuration
(WholeProgramOptimization="X"). While the compiler and the linker flags
can be set in the project, there is no option to enable the optimization
in the project file (maybe leading to the linker complaining about a
useless /LTCG flag, which is ignored if this global optimization flag is
not set). This means that there should also be some type of flag like
CMAKE_MFC_FLAG to enable to control this optimization from outside (ie.
the CMakeLists.txt project file).
The second issue is related to the way flags are handled in the current
versions of the generators. There is one FlagTable for the VS7 and
ExtraFlagTables for VS8 and VS9 for controlling the compiler flags.
That's totally fine. There is also a LinkFlagTable for VS7, but this one
is not extended by ExtraLinkFlagTables for VS8 and VS9. This is also the
reason why some of the flags passed from the project file are not
translated automatically into settings in the project file, but are only
passed as additional link options. I'd suggest introducing this
ExtraLinkFlagTables, which I already introduced in my version and which
help me controlling the build in my patched version for using platform
SDKs. This causes almost no overhead, but allows for a more granular way
of controlling the compiler and linker settings.
The last issue is the way to pass compile options for building a library
or executable. While there are settings passed to the linker by
LINK_FLAGS_{configname} scheme using SET_TARGET_PROPERTIES, there is no
such operation for COMPILE_FLAGS which can only be set for all
configurations to be the same. This is really a mess, because one is
forced to alter the CMAKE_C{XX}_FLAGS_{configname} variables by misusing
SET, REGEX REPLACE kind of stuff, which on the one hand makes things
quite complicated on the project file level, on the other hand might
break completely for some pathological cases. What about introducting
the COMPILE_FLAGS_{configname} scheme for SET_TARGET_PROPERTIES?
Please review!
kind regards
Clemens
Andreas Pokorny wrote:
Hello Clemens,
2008/9/30 Clemens Arth <[EMAIL PROTECTED]>:
[...] I further modified your WinCE.cmake(-cl) configuration to
WM5.cmake(-cl) to contain additional flags needed. Also a cached variable
PLATFORM_SDKS is used that selects only those platforms from the set of all
platforms installed. This works pretty well, as one simply has to create
this cache file first, and the rest works as expected.[...]
Shall we treat Windows Mobile and Windows CE as different operating systems?
What are the differences in this case? I found that info on the entry point:
http://msdn.microsoft.com/en-us/library/aa934487.aspx
There seem to be countless variants of WinCE. I recently heard about
Windows CE Auto
and Windows CE Automotive. CE seems to be constantly moving target.
kind regards
Andreas
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Andreas, I'm sorry but I was wrong about the CE versioning for WM5 and WM6, because the underlying CE versions are 5.01 and 5.02 (and not 5.1 and 5.2 I was assuming). Your original code works perfectly. I have now used your WINCE templates and compiled for Smartphone 2003/PPC 2003 and WM5 Smartphone/PPC. Everything works pretty well except that I had to add some additional definitions in the CMakelists.txt file, which is a good tradeoff against having templates for each platform (which would all look the same except for one or two additional ADD_DEF(...) calls). Let's wait until WM7 is released, then we will know if your templates have to be altered or work with it. Now I improved my VS SDK generators to include extra link flag tables, which are not available in the original VS generators. Tomorrow I will make another diff against the original version 2.6.2 and send you the new files. The main clue now is that a lot of additional things are included that allow setting things like MACHINE:THUMB and SUBSYSTEM:WINDOWSCE from cmake in VS, which obviously did not work before. I think with your template files and my SDK generators this has become a pretty neat solution now ;-) kind regards Clemens Andreas Pokorny schrieb: Hello Clemens, 2008/9/30 Clemens Arth <[EMAIL PROTECTED]>: [...] I further modified your WinCE.cmake(-cl) configuration to WM5.cmake(-cl) to contain additional flags needed. Also a cached variable PLATFORM_SDKS is used that selects only those platforms from the set of all platforms installed. This works pretty well, as one simply has to create this cache file first, and the rest works as expected.[...] Shall we treat Windows Mobile and Windows CE as different operating systems? What are the differences in this case? I found that info on the entry point: http://msdn.microsoft.com/en-us/library/aa934487.aspx There seem to be countless variants of WinCE. I recently heard about Windows CE Auto and Windows CE Automotive. CE seems to be constantly moving target. kind regards Andreas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Hello Clemens, 2008/9/30 Clemens Arth <[EMAIL PROTECTED]>: > [...] I further modified your WinCE.cmake(-cl) configuration to > WM5.cmake(-cl) to contain additional flags needed. Also a cached variable > PLATFORM_SDKS is used that selects only those platforms from the set of all > platforms installed. This works pretty well, as one simply has to create > this cache file first, and the rest works as expected.[...] Shall we treat Windows Mobile and Windows CE as different operating systems? What are the differences in this case? I found that info on the entry point: http://msdn.microsoft.com/en-us/library/aa934487.aspx There seem to be countless variants of WinCE. I recently heard about Windows CE Auto and Windows CE Automotive. CE seems to be constantly moving target. kind regards Andreas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Hi, Is the code attached to this thread the most recent source code for WinCE and Windows Mobile support? kind regards Andreas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Hi,
Andreas Pokorny schrieb:
Hello Clemens,
I still try to get some time slot to try your patches here. Since we
do not have that many 2005
licenses, I cannot do that as a kind of submarine project :).
2008/9/30 Clemens Arth <[EMAIL PROTECTED]>:
Andreas,
I had a look at your modified files and, like the old ones, they seem to
work quite well. However, there are some things that are somehow unclear to
me or cause problems here:
First, in WinCE.cmake, you replace the decimal string of the system version
CMAKE_SYSTEM_VERSION, which does not work in my case. Although WM5 is
considered as 5.1 and WM6 as 5.2, this causes a version of 0x51 and 0x52
respectively, which should be 0x501 and 0x502, otherwise compilation fails
with some error like "versions of Windows CE < 3.0 are not supported".
Changing your syntax to
STRING(REGEX REPLACE "([0-9]*)\\.([0-9]*)" "0x\\10\\2"
CMAKE_SYSTEM_VERSION_HEX "${CMAKE_SYSTEM_VERSION}")
Maybe we can skip that at least for the Visual Studio stuff. I don't
know if CEVER can be accessed somewhere outside of Visual Studio, but I
can also write something like $(CEVER) in -D_WIN32_WCE=$(CEVER) and the
visual studio compiler fills it up automatically.
Oh yes thats one of the uglier problems. I guess we need to do something like
STRING(REGEX MATCH "([0-9]*)\\.([0-9]*)" matched_CMAKE_SYSTEM_VERSION
"${CMAKE_SYSTEM_VERSION}")
STRING(LENGTH CMAKE_MATCH_1 CMAKE_MATCH_1_LENGTH) # or MATCH_2 ?
IF(CMAKE_MATCH_1_LENGTH GREATER 1)
SET(CMAKE_SYSTEM_VERSION_HEX "0x${CMAKE_MATCH_0}${CMAKE_MATCH_1}")
ELSE(CMAKE_MATCH_1_LENGTH GREATER 1)
SET(CMAKE_SYSTEM_VERSION_HEX "0x${CMAKE_MATCH_0}0${CMAKE_MATCH_1}")
ENDIF(CMAKE_MATCH_1_LENGTH GREATER 1)
fixes this in my case. I now wrote some generator for Visual Studio which
only takes a cached CMAKE_SYSTEM_NAME variable and, thus selects the right
toolchain. I further modified your WinCE.cmake(-cl) configuration to
WM5.cmake(-cl) to contain additional flags needed. Also a cached variable
PLATFORM_SDKS is used that selects only those platforms from the set of all
platforms installed. This works pretty well, as one simply has to create
this cache file first, and the rest works as expected. I still have to
modify the original files in the modules directory responsible for the test
build, because the test compile uses the right compiler in
VDSIR/VC/ce/bin/x86_arm, but cannot link the test program due to a missing
entry point.
And the linker flag /ENTRY:mainACRTStartup does not help here? If not we will
have to modify the test code in share/cmake-x/Modules/*.{in,c,cxx,cpp}
Unfortunately not, but if I update the CMakeTestCCompiler.cmake and
CMakeTestCXXCompiler.cmake files to contain a function called
mainCRTStartup doing the same thing as the original main function it
works. To remove the ABI Compiler check errors that follow without any
harm, I also have to alter the CMakeCCompilerABI.c and
CMakeCXXCompilerABI.cpp files to also contain a function called
mainCRTStartup doing the same as the already defined main function.
I tried using your WinCE file for generating NMake Makefiles without caching
anything and by typing
"cmake.exe -G"NMake Makefiles" -DCMAKE_SYSTEM_NAME=WINCE"
If you do not set the compiler to the arm cl.exe you will always
create x86 binaries,
and since you set WinCE it will try to link to libs that only exist for WinCE.
So you need:
"cmake.exe -G"NMake Makefiles" -DCMAKE_SYSTEM_NAME=WINCE" \
-DCMAKE_CXX_COMPILER=${VSDIR}/VC/ce/x86_arm/cl.exe" \
-DCMAKE_C_COMPILER=${VSDIR}/VC/ce/x86_arm/cl.exe"
or something similar
This fails here because it tries to link the coredll.lib trying to compile
the simple test program. I'm not sure if this is the error you mentioned,
because whatever I try to test-compile it tells me that he uses the cl.exe
located in VSDIR/VC/bin, which is not an embedded compiler anyway. However,
I'm sure that internally it uses the right compiler to compile the program,
and the information message about what cl is used is simply wrong. How do
you get your project configured for Makefiles?
We have a toolchain file here that sets these variables, but the
toolchain file relies
on environment variables to be set. We have one that tells us the path
to the visual
studio install. Another one that tells us the SDK path. And finally we have to
mention respective SDK subdirectories inside INCLUDE and LIBS. Otherwise
TRY_COMPILE checks would fail, because for some reason it ignores LINK_LIBRARIES
and other cmake flags. At least we had problems with that recently. I wanted to
invest more time on that issue, but I did not find the time slot yet.
Now I've set the compilers manually and it sets the CL platform to THUMB
automatically. Then it raises the /RTC1 warning and finally fails in
opening the coredll.lib. When using the VS generator the correct libs
are found because the new generator with SDK support always uses the
first SDK found on the c
Re: [CMake] Updated WinCE CMakefiles
Hello Clemens,
I still try to get some time slot to try your patches here. Since we
do not have that many 2005
licenses, I cannot do that as a kind of submarine project :).
2008/9/30 Clemens Arth <[EMAIL PROTECTED]>:
> Andreas,
>
> I had a look at your modified files and, like the old ones, they seem to
> work quite well. However, there are some things that are somehow unclear to
> me or cause problems here:
>
> First, in WinCE.cmake, you replace the decimal string of the system version
> CMAKE_SYSTEM_VERSION, which does not work in my case. Although WM5 is
> considered as 5.1 and WM6 as 5.2, this causes a version of 0x51 and 0x52
> respectively, which should be 0x501 and 0x502, otherwise compilation fails
> with some error like "versions of Windows CE < 3.0 are not supported".
> Changing your syntax to
>
> STRING(REGEX REPLACE "([0-9]*)\\.([0-9]*)" "0x\\10\\2"
> CMAKE_SYSTEM_VERSION_HEX "${CMAKE_SYSTEM_VERSION}")
Oh yes thats one of the uglier problems. I guess we need to do something like
STRING(REGEX MATCH "([0-9]*)\\.([0-9]*)" matched_CMAKE_SYSTEM_VERSION
"${CMAKE_SYSTEM_VERSION}")
STRING(LENGTH CMAKE_MATCH_1 CMAKE_MATCH_1_LENGTH) # or MATCH_2 ?
IF(CMAKE_MATCH_1_LENGTH GREATER 1)
SET(CMAKE_SYSTEM_VERSION_HEX "0x${CMAKE_MATCH_0}${CMAKE_MATCH_1}")
ELSE(CMAKE_MATCH_1_LENGTH GREATER 1)
SET(CMAKE_SYSTEM_VERSION_HEX "0x${CMAKE_MATCH_0}0${CMAKE_MATCH_1}")
ENDIF(CMAKE_MATCH_1_LENGTH GREATER 1)
>
> fixes this in my case. I now wrote some generator for Visual Studio which
> only takes a cached CMAKE_SYSTEM_NAME variable and, thus selects the right
> toolchain. I further modified your WinCE.cmake(-cl) configuration to
> WM5.cmake(-cl) to contain additional flags needed. Also a cached variable
> PLATFORM_SDKS is used that selects only those platforms from the set of all
> platforms installed. This works pretty well, as one simply has to create
> this cache file first, and the rest works as expected. I still have to
> modify the original files in the modules directory responsible for the test
> build, because the test compile uses the right compiler in
> VDSIR/VC/ce/bin/x86_arm, but cannot link the test program due to a missing
> entry point.
And the linker flag /ENTRY:mainACRTStartup does not help here? If not we will
have to modify the test code in share/cmake-x/Modules/*.{in,c,cxx,cpp}
>
> I tried using your WinCE file for generating NMake Makefiles without caching
> anything and by typing
>
> "cmake.exe -G"NMake Makefiles" -DCMAKE_SYSTEM_NAME=WINCE"
>
If you do not set the compiler to the arm cl.exe you will always
create x86 binaries,
and since you set WinCE it will try to link to libs that only exist for WinCE.
So you need:
"cmake.exe -G"NMake Makefiles" -DCMAKE_SYSTEM_NAME=WINCE" \
-DCMAKE_CXX_COMPILER=${VSDIR}/VC/ce/x86_arm/cl.exe" \
-DCMAKE_C_COMPILER=${VSDIR}/VC/ce/x86_arm/cl.exe"
or something similar
> This fails here because it tries to link the coredll.lib trying to compile
> the simple test program. I'm not sure if this is the error you mentioned,
> because whatever I try to test-compile it tells me that he uses the cl.exe
> located in VSDIR/VC/bin, which is not an embedded compiler anyway. However,
> I'm sure that internally it uses the right compiler to compile the program,
> and the information message about what cl is used is simply wrong. How do
> you get your project configured for Makefiles?
We have a toolchain file here that sets these variables, but the
toolchain file relies
on environment variables to be set. We have one that tells us the path
to the visual
studio install. Another one that tells us the SDK path. And finally we have to
mention respective SDK subdirectories inside INCLUDE and LIBS. Otherwise
TRY_COMPILE checks would fail, because for some reason it ignores LINK_LIBRARIES
and other cmake flags. At least we had problems with that recently. I wanted to
invest more time on that issue, but I did not find the time slot yet.
regards
Andreas
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Andreas,
I had a look at your modified files and, like the old ones, they seem to
work quite well. However, there are some things that are somehow unclear
to me or cause problems here:
First, in WinCE.cmake, you replace the decimal string of the system
version CMAKE_SYSTEM_VERSION, which does not work in my case. Although
WM5 is considered as 5.1 and WM6 as 5.2, this causes a version of 0x51
and 0x52 respectively, which should be 0x501 and 0x502, otherwise
compilation fails with some error like "versions of Windows CE < 3.0 are
not supported". Changing your syntax to
STRING(REGEX REPLACE "([0-9]*)\\.([0-9]*)" "0x\\10\\2"
CMAKE_SYSTEM_VERSION_HEX "${CMAKE_SYSTEM_VERSION}")
fixes this in my case. I now wrote some generator for Visual Studio
which only takes a cached CMAKE_SYSTEM_NAME variable and, thus selects
the right toolchain. I further modified your WinCE.cmake(-cl)
configuration to WM5.cmake(-cl) to contain additional flags needed. Also
a cached variable PLATFORM_SDKS is used that selects only those
platforms from the set of all platforms installed. This works pretty
well, as one simply has to create this cache file first, and the rest
works as expected. I still have to modify the original files in the
modules directory responsible for the test build, because the test
compile uses the right compiler in VDSIR/VC/ce/bin/x86_arm, but cannot
link the test program due to a missing entry point.
I tried using your WinCE file for generating NMake Makefiles without
caching anything and by typing
"cmake.exe -G"NMake Makefiles" -DCMAKE_SYSTEM_NAME=WINCE"
This fails here because it tries to link the coredll.lib trying to
compile the simple test program. I'm not sure if this is the error you
mentioned, because whatever I try to test-compile it tells me that he
uses the cl.exe located in VSDIR/VC/bin, which is not an embedded
compiler anyway. However, I'm sure that internally it uses the right
compiler to compile the program, and the information message about what
cl is used is simply wrong. How do you get your project configured for
Makefiles?
Regards
Clemens
Andreas Pokorny schrieb:
Hi there,
I have attached a zip with slightly cleaned up WinCE and Windows
Platform files. I modified the check
that tries to decide whether cl builds for x86 or amd64, at least
thats what I thought it was doing.
Now there is a check that inspects an object file of cl, then sets
respective flags to link.exe.
The check only happens when building Makefiles, hence the /machine
linker flag is only set when
generating makefiles. I assume visual studio would do the right
thing(tm), since it should be possible
to select the SDK and platform inside the IDE, if I am not mistaken.
There are some remaining issues:
* the flag /RTC[1] is not supported by cl vs2005 for arm at least
- is there a cmake macro that checks if a compiler flag is supported?
* when not using thumb code, one cannot use the libs provided with an
ARM SDK, hence
setting coredll.lib and friends breaks the build
* If I am not mistaken there is yet no clean facility to specify the
libpath and include path
from the toolchain file
Please review.
In the following days I will try to use Clemens patch for the visual
studio generators.
kind regards
Andreas Pokorny
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Hi again
Or we let the user set n-different toolchain files each identifying an
individual
SDK (or maybe no toolchain files, just SDKs), and execute the CMakelists
multiple times using separate CMakeCaches.
that was definitely a good idea. Now I've predefined the names of
several different SDKs and simply copy the cache file into the build
directory before configuring and creating the projects. I modified my
version of the WindowsMobile generator to parse the cache variable and
select only those SDKs specified. If you already had a look into the
cmGlobalVisualStudio8_WindowsMobile_Generator.cxx file, lines 235-265
are used to circumvent many settings that might go into a separate
toolchain file. For example, CMAKE_SYSTEM_VERSION might change from 5.1
for WM5 to 5.2 for WM6 and 5.3 for upcoming WM7.
How would you change the way this currently hardcoded information should
be passed in a more flexible way in the future? I would suggest that the
CMAKE_SYSTEM_NAME is also passed as an additional variable using the
cache file, maybe with allowed values of WM5,WM6,WINCE5,WINCE6 a.s.o.
Setting CMAKE_SYSTEM_NAME to any of these values should then cause cmake
to use a toolchain file with the same name, containing all this information.
regards,
Clemens
/*=
Program: CMake - Cross-Platform Makefile Generator
Module:$RCSfile: cmGlobalVisualStudio8_WindowsMobile_Generator.cxx,v $
Language: C++
Date: $Date: 2008-04-02 13:16:04 $
Version: $Revision: 1.36.2.1 $
Copyright (c) 2002 Kitware, Inc., Insight Consortium. All rights reserved.
See Copyright.txt or http://www.cmake.org/HTML/Copyright.html for details.
This software is distributed WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the above copyright notices for more information.
=*/
#include "windows.h" // this must be first to define GetCurrentDirectory
#include "cmGlobalVisualStudio8_WindowsMobile_Generator.h"
#include "cmLocalVisualStudio7Generator.h"
#include "cmMakefile.h"
#include "cmake.h"
#include "cmGeneratedFileStream.h"
cmWindowsMobileConfigParser::cmWindowsMobileConfigParser()
: cmXMLParser()
{
current_platform_valid = false;
}
void cmWindowsMobileConfigParser::StartElement(const char* name, const char**
atts)
{
if ( strcmp(name, "Macro") == 0 )
{
const char* rev = this->FindAttribute(atts, "Name");
if (rev)
{
if ( strcmp(rev, "PLATFORMDEFINES") == 0 &&
current_platform_valid)
{
rev = this->FindAttribute(atts, "Value");
PlatformDefs * defs =
&(this->platformVec.back());
defs->PlatformDefines = std::string(rev);
}
else if ( strcmp(rev, "CEVER") == 0 &&
current_platform_valid)
{
rev = this->FindAttribute(atts, "Value");
PlatformDefs * defs =
&(this->platformVec.back());
defs->CEver = std::string(rev);
}
else if ( strcmp(rev, "ARCHFAM") == 0 &&
current_platform_valid)
{
rev = this->FindAttribute(atts, "Value");
PlatformDefs * defs =
&(this->platformVec.back());
defs->Archfam = std::string(rev);
}
else if ( strcmp(rev, "_ARCHFAM_") == 0 &&
current_platform_valid)
{
rev = this->FindAttribute(atts, "Value");
PlatformDefs * defs =
&(this->platformVec.back());
defs->Archfam_ = std::string(rev);
}
else if ( strcmp(rev, "INSTRUCTIONSET") == 0 &&
current_platform_valid)
{
rev = this->FindAttribute(atts, "Value");
PlatformDefs * defs =
&(this->platformVec.back());
defs->InstructionSet= std::string(rev);
}
}
}
this->CharacterData.erase(
this->CharacterData.begin(), this->CharacterData.end());
}
void cmWindowsMobileConfigParser::EndElement(const char* name)
{
if ( strcmp(name, "PlatformName") == 0 )
{
PlatformDefs defs; defs.added = false;
defs.PlatformName =
std::string(this->CharacterData.begin(),this->CharacterData.end());
// if(defs.PlatformName.find("ARMV4") != std::string
Re: [CMake] Updated WinCE CMakefiles
Hi, Andreas Pokorny schrieb: Hello, 2008/9/19 Clemens Arth <[EMAIL PROTECTED]>: [...] I completely agree with you about the issue of adding and removing individual files within a single solution, and I think the entire hack is not a good solution. I would also prefer using an individual cross compile configuration for each SDK. Or we let the user set n-different toolchain files each identifying an individual SDK (or maybe no toolchain files, just SDKs), and execute the CMakelists multiple times using separate CMakeCaches. I think that will really be the best way to do it. Concerning Visual Studio projects, the main problem is that one would wish to have a generator for any combination of Visual Studio and any SDK, which simply does not exist. A possible solution might be to e.g. use a somewhat generic "Visual Studio 9 2008 - SDK" generator, which might get configured in more detail by sticking back to a dedicated cross compile configuration based on a SDK to be selected in advance (also by setting some flag). First I was thinking about implementing it like that, integrating something like a dialog box or an additional flag to specify a single SDK (or a set of SDKs) to be used during project generation. Finally I did not do it because I did not find a nice solution to the problem of interacting with cmake to specify SDKs - maybe one might think about some mechanism to "generate generators" at cmake startup based on the number of SDKs installed. What was the problem with the cmake user interface? Maybe there's really a simple solution and I don't find it, but there are several issues. In my case I want cmake to set up a project using a SDK to be defined and I want that to be done using the GUI. For example, I want it to create a project which has to be compiled using the "Windows Mobile 5.0 Smartphone SDK (ARMV4I)" SDK. Note that many SDKs have such long names that you might not remember easily. Now what you need is a generator which takes the information what SDK to use (and what toolchain file to use), so you have to create such a generator. I think the main problem with this is that you have to create such a generator for each individual SDK you might install on your computer - and that's definitely not what I want to do. I think it would be good to create an universal generator for SDKs which simply takes additional information what SDKs to use. BUT: if you create such a generator, how should you pass the information to it which SDK to use? How should this be done if you want to create the project using the CMakeSetup.exe GUI? If you let cmake configure your project, you have to know this in advance, so at the same time as you select which generator to use. Beside this issue, there is also the problem that even if you can pass this information using a variable, you have to know the exact name of an SDK which might be tricky. Thus I would prefer determining the SDK name somehow automatically and let the user choose from the set. Do you think that multiple cmakecaches might solve this problem? kind regards Clemens ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Hello, 2008/9/19 Clemens Arth <[EMAIL PROTECTED]>: > [...] > > > I completely agree with you about the issue of adding and removing > individual files within a single solution, and I think the entire hack is > not a good solution. I would also prefer using an individual cross compile > configuration for each SDK. Or we let the user set n-different toolchain files each identifying an individual SDK (or maybe no toolchain files, just SDKs), and execute the CMakelists multiple times using separate CMakeCaches. > Concerning Visual Studio projects, the main > problem is that one would wish to have a generator for any combination of > Visual Studio and any SDK, which simply does not exist. A possible solution > might be to e.g. use a somewhat generic "Visual Studio 9 2008 - SDK" > generator, which might get configured in more detail by sticking back to a > dedicated cross compile configuration based on a SDK to be selected in > advance (also by setting some flag). First I was thinking about implementing > it like that, integrating something like a dialog box or an additional flag > to specify a single SDK (or a set of SDKs) to be used during project > generation. Finally I did not do it because I did not find a nice solution > to the problem of interacting with cmake to specify SDKs - maybe one might > think about some mechanism to "generate generators" at cmake startup based > on the number of SDKs installed. What was the problem with the cmake user interface? kind regards, Andreas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Andreas, well, considering the first issue I usually hoped that this might be solved by Visual Studio somehow automatically by some internal magic. After a cleanup of the WinCE.cmake and WinCE-cl.cmake a.s.o. these files should mainly contain settings which are universal to all SDKs (I wonder if there are such settings, and I have no idea what these settings might be). The trick would just to make the test-compiles run through. Then I would rely on Visual Studio to fill up the rest of the settings which were not set prior using the WinCE.cmake files automatically the first time the project file is opened. Maybe it can do that like you were creating a standard project for a platform using a SDK and Visual Studios assistant which comes up with some standard settings. However, I don't think that this will really work well... I completely agree with you about the issue of adding and removing individual files within a single solution, and I think the entire hack is not a good solution. I would also prefer using an individual cross compile configuration for each SDK. Concerning Visual Studio projects, the main problem is that one would wish to have a generator for any combination of Visual Studio and any SDK, which simply does not exist. A possible solution might be to e.g. use a somewhat generic "Visual Studio 9 2008 - SDK" generator, which might get configured in more detail by sticking back to a dedicated cross compile configuration based on a SDK to be selected in advance (also by setting some flag). First I was thinking about implementing it like that, integrating something like a dialog box or an additional flag to specify a single SDK (or a set of SDKs) to be used during project generation. Finally I did not do it because I did not find a nice solution to the problem of interacting with cmake to specify SDKs - maybe one might think about some mechanism to "generate generators" at cmake startup based on the number of SDKs installed. I'd really appreciate if you could help me with implementing a final solution to this and to find a way to abstract from individual definitions for various generators like nmake and VS. to create a single definition. Regards, Clemens Andreas Pokorny schrieb: Hi, I am still wondering how this all fits together. The patch you are working on, will generate a visual studio file that contains build rules for all installed SDKs. But when generating for nmake we will have a cross compile configuration for a single SDK. How can we ensure that both things work. I am thinking about similar cases like the /machine linker flag. For nmake we have to set it for visual studio we must have individual settings for each sdk. The same applies to cl, for nmake we pick one cl and for visual studio we could have a project that uses cl for MIPS sh4 and arm... Lets hope that no project decides to conditionally add or remove source files based on the target architecture. kind regards Andreas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Hi, I am still wondering how this all fits together. The patch you are working on, will generate a visual studio file that contains build rules for all installed SDKs. But when generating for nmake we will have a cross compile configuration for a single SDK. How can we ensure that both things work. I am thinking about similar cases like the /machine linker flag. For nmake we have to set it for visual studio we must have individual settings for each sdk. The same applies to cl, for nmake we pick one cl and for visual studio we could have a project that uses cl for MIPS sh4 and arm... Lets hope that no project decides to conditionally add or remove source files based on the target architecture. kind regards Andreas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Am Thursday 18 September 2008 14:08:05 schrieb Andreas Pokorny: > * If I am not mistaken there is yet no clean facility to specify the > libpath and include path > from the toolchain file The lib path can normally be derived from the root path by specifying the proper PATH_SUFFIXES when using find_library. The include paths can be set by adding include_libraries(SYSTEM .) in the toolchain file. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
