|
Notes |
|
|
(0014882)
|
|
Brad King
|
|
2009-02-10 09:28
|
|
Thank you for your work on CMake!
I cloned your repo to take a look. So far I've looked through the ValidValues branch. This is a great feature, especially for GUI users. I'd like to propose an alternative interface though.
Currently cache entry properties do not use the same mechanism (cmPropertyMap) or interface (set_property/get_property commands) used by source, target, directory, global, and test properties. The main user-controlled property for cache entries is the 'ADVANCED' mark. Your feature adds a 'VALID_VALUES' property. I suggest that we use the set_property and get_property commands as the interface to set and get these properties:
set_property(CACHE MY_SELECTION_ENTRY PROPERTY VALID_VALUES
ValueA ValueB ValueC)
This interface nicely integrates with existing commands.
Furthermore, I'd like to use a different representation in CMakeCache.txt for the list of valid values. They can be stored in an INTERNAL cache entry called <var>-VALID_VALUES just like the advanced flag is stored in <var>-ADVANCED. This approach reduces the impact on the cache format and will allow old versions of CMake to load and save these caches transparently while preserving the values. |
|
|
|
(0014885)
|
|
Sergey Rudchenko
|
|
2009-02-10 13:26
|
|
Thanks, Brad. We expected some changes from a CMake core developer, to implement this feature in the most "CMake" way.
I think we could adjust our code to your vision quickly. I will add a comment here when the git repository is updated.
Please look also at the platforms implementations, they are very important for our project where we use CMake intensively. |
|
|
|
(0015670)
|
|
Brad King
|
|
2009-03-12 11:34
|
|
We've committed a change similar to the VALID_VALUES patch. The property is called 'STRINGS'. CMake does not enforce that the value match. It is only for convenience of GUI users being given a drop-down. For now only the Qt dialog (cmake-gui) will do it.
I'm sorry I've not been able to review the other platform changes. I'm assigning this to Alex since he is more experienced with cross-compiling. |
|
|
|
(0015673)
|
|
Alex Neundorf
|
|
2009-03-12 16:08
|
|
Hi,
I just had a look at Symbian.cmake. Is that all you had to do ?
(I have only very basic git skills).
So I got your cmake tree using git clone.
Now I need the Symbian branch. How do I get it ?
git checkout -b Symbian said "Switched to a new branch "Symbian", so it seems this was wrong. So how do I do this ?
And is it possible to retrieve the set of patches which were committed to the Symbian branch since its branching point ?
Alex |
|
|
|
(0015884)
|
|
Sergey Rudchenko
|
|
2009-04-01 06:39
|
|
Hi Alex,
Thanks for your great work on CMake!
Sorry for long delay - Mantis didn't notify me about new comments on this bug, though I "monitor" it :(
Here is the sequence which will give you the Symbian branch source:
$ git clone git://github.com/AlexeyS/cmake.git [^] # clone the repo
$ cd cmake
$ git checkout -b Symbian # create a local branch named "Symbian"
$ git pull origin Symbian # synchronize it with the remote branch "Symbian"
And this command line will give you a patch against pure cmake-2.6.2:
$ git diff master Symbian
Best regards,
Sergey |
|
|
|
(0015957)
|
|
Alex Neundorf
|
|
2009-04-07 17:13
|
|
Wow, that's a lot of work ! :-)
Some comments/questions:
CMakeDetermineCCompiler.cmake, CMakeDetermineCXXCompiler.cmake:
why do you use CMAKE_FORCE_C_COMPILER() here ? This should only be used if the compiler is in some way not able to create a most basic executable without additional information. IOW, what is a valid command to build "int main(){return 0;}" ?
CMakeDetermineSystem.cmake:
That's a shortcut. I'm not sure the other CMake developers will like that. But eben if this would be the case, this patch isn't really necessary.
CMakeSymbianFindMake.cmake:
Can you use FIND_PROGRAM() to find bldmake ? It would be nice if we would have the full path to it.
Also, if you add it to the cache, please add a useful comment in the set() command.
cmAddSymbianBitmapCommand, cmAddSymbianResourceCommand:
Hmm, two new commands specially for Symbian support. They are adding something to the target. What are they doing exactly, or, how is this used later on ?
It would be nicer if this could be done via cmake macros, maybe you could use target properties for this ?
Ah, you use this in the generators.
I think you most probably can write a cmake macro which sets target properties, and then you can query these properties in the generators.
The generators:
I can't really comment on them. Do they also support the rules created via ADD_CUSTOM_COMMAND() and ADD_CUSTOM_TARGET() ?
cmTarget.cxx:
The "IMPORT" keyword for target_link_libraries() definitely won't go in, even the other keywords are just kept for compatibiltity, this will not be extendend. Why do you need this ?
So, some thing left to do, but we're almost there :-)
Nice work !
Two coding style comments:
-please make sure the lines are not longer than 79 characters
-please start your member functions with an upper case letter
Alex |
|
|
|
(0015958)
|
|
Alex Neundorf
|
|
2009-04-07 17:14
|
|
Attached the patch with the symbian changes, so it is easier to have a look for others.
Alex |
|
|
|
(0015964)
|
|
Sergey Rudchenko
|
|
2009-04-08 12:14
|
|
Hi Alex,
Thank you very much for your review! I didn't expect so quick and kind comments on that code. :)
I had to use CMAKE_FORCE_C_COMPILER because at the configuration/generation time an actual toolchain is undefined, unfortunately. A toolchain is picked at the final stage of building.
CMakeDetermineSystem.cmake:
Sorry, I'm not sure I understand.
CMakeSymbianFindMake.cmake:
Yup, I think I can use FIND_PROGRAM for that.
cmAddSymbianBitmapCommand, cmAddSymbianResourceCommand:
These commands add some symbian specific structured sections to the .mmp file. I think that could be implemented via properties, but that would cause awkward constructions in user's CMakeLists.txt.
ADD_CUSTOM_TARGET was already supported and I have committed ADD_CUSTOM_COMMAND_SUPPORT. They are both implemented via external makefiles (bld.inf syntax supports such feature).
The IMPORT keyword:
It's a dead-end for me, really. Symbian toolchains cannot distinguish import libraries and static ones. Specifying a wrong type of library causes build errors (damn x 100). Alex, I hope in your CMake concept understanding, please suggest a way to implement this :(
coding style:
Oops, I tried to mimic it. Just deviated occasionally. I'll adjust it, sure.
Also, I'm going to fix that ugly solution with <target>_UID & friends variables. It is in the local generator code. That was just a lack of experience in the CMake code. They are definitely must be properties.
Sergey |
|
|
|
(0015966)
|
|
Brad King
|
|
2009-04-08 13:09
|
|
It looks like the purpose of the IMPORT keyword is to distinguish "foo.lib" static libraries and "foo.lib/foo.dll" import/shared libraries because the project file format needs either LIBRARY or STATICLIBRARY keywords. When the library name is a CMake target it is easy to distinguish the type based on the cmTarget::GetType() method. The hard part is when the library is not built by the project.
As Alex said, the 'debug' and 'optimized' keywords are out-dated. The new way to do things is to use IMPORTED targets (the name 'IMPORTED' refers to importing into CMake, not to dll import libraries):
http://www.cmake.org/Wiki/CMake_2.6_Notes#Importing_Targets [^]
The advantage of imported targets is that lots of information about a library can be specified (full paths, library type, soname, etc.). They have full cmTarget instances in CMake's representation, so cmTarget::GetType() can distinguish things:
add_library(foo SHARED IMPORTED)
set_property(TARGET foo PROPERTY IMPORTED_LOCATION c:/path/to/bin/foo.dll)
set_property(TARGET foo PROPERTY IMPORTED_IMPLIB c:/path/to/lib/foo.lib)
add_library(bar STATIC IMPORTED)
set_property(TARGET bar PROPERTY IMPORTED_LOCATION c:/path/to/lib/libfoo.lib)
target_link_libraries(myexe foo bar)
Currently IMPORTED_LOCATION must be set to the location of the dll even though we do not need it to build. This problem can be addressed though. |
|
|
|
(0015967)
|
|
Sergey Rudchenko
|
|
2009-04-08 13:20
|
|
Symbian projects usually link LOTS of system libraries (most of them are implib/dll pairs). So this approach will lead to extra many lines which are very similar for every Symbian-aware CMakeLists.txt. Symbian SDK libraries are fine grained and we cannot just link some core libs by default. :(
Maybe there is a way to detect the lib type at configuration time by opening the .lib file and searching for some "magic" bytes... That would be quite complicated solutions, but it allows to avoid the IMPORT keyword. |
|
|
|
(0015968)
|
|
Brad King
|
|
2009-04-08 13:28
|
|
|
Perhaps the Symbian platform file in CMake can create imported targets for all the system libraries. Then projects can just link to them by name. They could even do "if(TARGET somesyslib)" to detect if a particular library is available. |
|
|
|
(0015970)
|
|
Abuse
|
|
2009-04-08 14:31
|
|
|
BTW there was added a Windows CE project generator for MSVS 2008 to the git repo. Also Windows CE CMake variable CMAKE_WINDOWS_MOBILE_PLATFORM was renamed to CMAKE_WINDOWS_CE_PLATFORM, because we can generate projects not only for Windows Mobile platform, but also for basic Windows CE. |
|
|
|
(0016031)
|
|
Brad King
|
|
2009-04-15 13:21
|
|
|
I recently committed "ENH: Allow IMPORTED_IMPLIB w/o IMPORTED_LOCATION" to address the case I mentioned above. |
|
|
|
(0016032)
|
|
Brad King
|
|
2009-04-15 13:24
|
|
|
Since you're developing a new generator please base it on HEAD to avoid conflicts when we integrate it. We won't be adding a generator in a patch release. |
|
|
|
(0016051)
|
|
Alex Neundorf
|
|
2009-04-18 11:54
|
|
> I had to use CMAKE_FORCE_C_COMPILER because at the configuration/generation
> time an actual toolchain is undefined, unfortunately. A toolchain is picked
> at the final stage of building.
In general the idea would be that you define the (cross)-compiler in the toolchain-file, and then this compiler is used.
For which architectures does Symbian exist ?
Is it possible to compile a simple "hello world" by just calling the compiler on the source file ? If not, how does it fail ?
> cmAddSymbianBitmapCommand, cmAddSymbianResourceCommand:
> These commands add some symbian specific structured sections to the .mmp
> file. I think that could be implemented via properties, but that would cause
> awkward constructions in user's CMakeLists.txt.
I'm quite sure this could be wrapped in a cmake macro, so that from the outside it would look more or less identical to a built-in cmake command. The argument parsing is a bit harder to do in cmake script than in C++, but it is possible.
I attached a ParseArgs.cmake, which should help with that (I didn't write that file, I haven't tested it myself yet, but it should work).
Alex |
|
|
|
(0016142)
|
|
Sergey Rudchenko
|
2009-04-22 12:58
(edited on: 2009-04-22 12:59) |
|
Hi Brad, Alex
I have attached symbian_220409cvs.patch to this bug. This patch is my current work status. Key points:
* the patch is based on current CVS source (Wed Apr 22 16:55:17 UTC 2009)
* the IMPORT keyword is removed. Now the Symbian global generator pre-adds all SDK libraries as imported targets (Thanks, Brad)
I'm ready to solve the next problems. I will keep you informated about my progress.
Sergey
|
|
|
|
(0016152)
|
|
Sergey Rudchenko
|
|
2009-04-23 06:35
|
|
|
Is there a real need to detect the bldmake? What would be it used for? |
|
|
|
(0016155)
|
|
Sergey Rudchenko
|
|
2009-04-23 10:14
|
|
Hi Alex,
I succeeded to write corresponding macros for add_symbian_resource and add_symbian_bitmap commands, which can parse all necessary arguments.
Now I'm stuck on internal representation of the data. First, I was thinking about target properties, but a target can have multiple resources associated. That seems to be a bad way to append a property value since it will accumulate.
The most close abstraction is a source file. A resource is a source file for target, and it can have own properties (UID, LANG, etc). I can't found a way to inject a source file to a target from a script. Is this possible? I would request such a feature in order to complete this enhancement of the Symbian generator.
My vision:
function(add_symbian_resource _cmake_target _resource_file)
# parse args
...
target_add_source(${_cmake_target} ${_resource_file}) # if it would exist
set_properties(TARGET ${_cmake_target}
SOURCE ${_resource_file}
PROPERTIES
..
UID ${_parsed_uid}
LANG ${_parsed_lang})
endfunction(add_symbian_resource)
Does this make sense?
Sergey |
|
|
|
(0016156)
|
|
Brad King
|
|
2009-04-23 10:23
|
|
Currently there is no equivalent to target_add_source, but it is an oft-requested feature.
The bigger problem is the per-source-per-target property. Currently source files are assigned to targets but have directory scope. There is no way to associate a property with a source file only for one target.
How are symbian resources and bitmaps different from what the MS resource compiler (rc) uses? Generally we just add resources as any other source file to a target and then define build rules for it. Why do you need a separate command? |
|
|
|
(0016158)
|
|
Sergey Rudchenko
|
|
2009-04-23 10:48
|
|
Hmm, that fits add_symbian_resource functionality ideally, thanks Brad!
But there is still trouble with add_symbian_bitmap. This command represents such section in an mmp file:
START BITMAP result.mbm
TARGETPATH \blah\blah
HEADER
SOURCE c12 one.bmp
SOURCE c12 two.bmp
SOURCE c12 three.bmp
END
So, it's more like a separate target of type "Symbian bitmap" which generates the "result.mbm" bundle file. |
|
|
|
(0016171)
|
|
Alex Neundorf
|
|
2009-04-23 16:46
|
|
What happens with the bmp files during building ?
What is c12 ?
Alex |
|
|
|
(0016176)
|
|
Sergey Rudchenko
|
|
2009-04-24 07:52
|
|
|
AFAIK, they are just being bundled and "c12" stands for color depth. |
|
|
|
(0019158)
|
|
Andrew Manson
|
|
2010-01-17 16:32
|
|
|
How is this progressing? Is there a patch ( or better yet a patched binary ) floating about that works with 2.8? is the attached patch the most up to date work? |
|
|
|
(0019174)
|
|
Mateusz Loskot
|
|
2010-01-18 17:43
|
|
I'm strongly interested in Windows CE and Symbian support in CMake. What would be closest CMake release to expect this features included?
Great work, indeed! |
|
|
|
(0019197)
|
|
Andrew Manson
|
|
2010-01-19 14:18
|
|
|
May I just rephrase my question from two days ago... Does anyone know of a repo that has a working patched 2.8 version of cmake or has this project been deserted? This project might be very important in the current climate as Qt has recently been released for Symbian ( http://qt.nokia.com/products/platform/symbian [^] ) and there should be a lot of KDE developers interested in developing for Symbian, and as you know most KDE developers are quite fond of CMake. |
|
|
|
(0019199)
|
|
Alex Neundorf
|
|
2010-01-19 14:26
|
|
There is no fixed schedule, and there is currently also no payed contract for working on this AFAIK.
So I'll do this in my spare time when I find time (I'm not working for Kitware).
Alex |
|
|
|
(0019201)
|
|
Andrew Manson
|
|
2010-01-19 15:29
|
|
@neundorf thanks for the reply! No I fully understand that it is an open source project/branch and I'm used to the way the "Schedule" works ;) The reason why I was letting you know about the Qt for Symbian thing is that I'm sure that your project will be gaining a lot of publicity in the near future. If you would like some help then I'm willing to give you some programming help ( If you are willing to mentor a little bit ) or some financial help in the form of a donation. Also if you are going to be developing this project further then I could whip you up a little website that describes what you are intending to do and acts as a medium for involvement and donations.
Let me know if any of this is interesting to you and maybe we can take this discussion of this list. You can find me on #cmake on freenode and we can exchange emails. |
|
|
|
(0019204)
|
|
Alex Neundorf
|
|
2010-01-19 16:51
|
|
Ok, here we go.
Since last week I actually own a Symbian phone, so this priority got higher on my personal list.
Today I built the helloworld executable with the GnuPOC SDK :-)
Lots of strange tools I encountered along the way...
abld, bldmake, makesis, signsis
The original patch here sets "sdk" as compiler.
I was just using arm-none-symbianelf-gcc here.
When building the following main.c:
int main() {return 0;}
it complains:
rm-none-symbianelf/bin/ld: warning: cannot find entry symbol _start;
defaulting to 00008000
I guess some library needs to be linked ?
But maybe this could be ignored, an a.out is produced anyway.
Do you think it is necessary to really create mmp-files or should normal Makefiles do ?
Alex |
|
|
|
(0019205)
|
|
Alex Neundorf
|
|
2010-01-19 16:56
|
|
Can you recommend a book (pdf or on paper) on developing for Symbian ?
Alex |
|
|
|
(0019213)
|
|
Sergey Rudchenko
|
|
2010-01-20 09:19
|
|
Hi Alex,
I have tried to write a Makefile generator for Symbian but there are some complications with it. Particularly - many compile flags and preprocessor definitions are spread across perl scripts of SDK :( I was trying to create a universal generator, not tied to any specific SDK.
However, you can take a look at my attempt by checking the "SymbianMakefiles" branch from the same git repo.
Sergey |
|
|
|
(0019218)
|
|
Alex Neundorf
|
|
2010-01-20 12:39
|
|
There are many SYMBIAN_something variables in your SymbianMakefiles tree, and I didn't find a place where they are set.
Can you please explain what value they should have, where this value should be set ?
Alex |
|
|
|
(0019227)
|
|
Andrew Manson
|
|
2010-01-20 16:31
|
|
Hi Alex,
Unfortunately I'm not an expert in developing for Symbian so I'm going through the same learning curve as yourself it would seem. Like I said in my previous message I will be using the Qt framework. Currently Qt uses its own Makefile builder called qmake to generate Makefiles for the symbian platform since Qt 4.6. The whole software is Open source and on Gitorious so it might be worth looking at some of their code and seeing how its done, what do you think? I don't really know how either the cmake or the qmake systems work but I can learn to help out with this project. I would really like to see it succeed.
Andrew |
|
|
|
(0019236)
|
|
Sergey Rudchenko
|
|
2010-01-21 05:40
|
|
|
Alex, they are imported from a Symbian SDK, take a look at cmGlobalSymbianMakefileGenerator::SelectToolchain(..) |
|
|
|
(0019282)
|
|
Alex Neundorf
|
|
2010-01-23 15:10
|
|
Ok, I'm getting somewhere slowly.
I got a few questions:
1) It seems the entry point for programs under Symbian is "E32Main()" instead of "main()".
Is this correct ?
What happens if I have an executable which has only main() but not E32Main() ?
(I can link successfully if I leave the linker options "--entry _E32Startup -u _E32Startup" away).
2) Symbian is written in C++. Is plain C actually supported ? Entry point is also E32Main() then ?
3) I'm doing this under Linux. There are .lib files and .dso files in the SDK library directories. Which seems to be normal static ar-archives and normal ELF shared libraries. Is Symbian then also a "DLL platform", as you set in cmTarget.cxx ? Or is this only the case when using Windows as development platform ?
4) Which compilers are supported under Windows ?
Alex |
|
|
|
(0019283)
|
|
Alex Neundorf
|
|
2010-01-23 15:41
|
|
And another one:
what do all these arguments mean ?
elf2e32 --sid=0xa000017f --stack=0x00005000 --uid1=0x1000007a --uid2=0x100039ce --uid3=0xa000017f --vid=0x00000000 --capability=none --fpu=softvfp --targettype=EXE --output="$@" --elfinput="$(EPOCBLDUREL)/helloworldbasic.exe" --linkas=helloworldbasic{000a00}0[a000017f].exe --libpath="$(EPOCLIB)/lib/
Especially the sid, uid and linkas ?
Alex |
|
|
|
(0019284)
|
|
Alex Neundorf
|
|
2010-01-23 15:49
|
|
I attached what I have so far.
The file Symbian.patch adds Symbian as a platform to CMake.
CMakeLists.txt is a CMakeLists.txt for the helloworld-example shipped with the SDK (S60 3rd edition).
This is cross compiling, so a toolchainfile has to be used, I uploaded this too.
With these files I am able to compile and link helloworld, and also to run elf2e32 successfully on it.
For now, instead of the normal add_executable() a new symbian_add_executable() has to be used, which is a thin wrapper around add_executable(), see Symbian-GNU-Common.cmake.
Please comment on the current patch.
If this is ok so far, what else needs to be done to get a fully working helloworld ? There are these strange resource files...
Alex |
|
|
|
(0019300)
|
|
Alex Neundorf
|
|
2010-01-25 12:33
|
|
|
|
|
(0019561)
|
|
Alex Neundorf
|
|
2010-02-21 10:42
|
|
I've patched the cvs HEAD tree and built CMake correctly.
I've also edited the toolchain file to fit my SDK installation on WindowsXP (I use Debian normally but a I develop for Symbian on Windows) and I've had to use the macros
CMAKE_FORCE_C_COMPILER()
CMAKE_FORCE_CXX_COMPILER()
in order to create the makefile.
The compilation ends correctly but the linkage doesn't end. The first error is due to unquoted path with spaces: "Arm: No such file or directory", so I edited the file build.make (created by CMake) at the line of arm-none-symbianelf-ld.exe: every path that follows the ld.exe file must be quoted, so I added " at the begining and at the end. Then I got a lot of errors, probably each one depends on the first: "ERROR: Source object C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/euser.lib has EABI version 2, but target helloworld.exe has EABI version 4. Failed to merge target specific data to file C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/euser.lib".
This error is the same for each linked library, then I got some errors of "undefined reference" and I think that these last errors depend on the first one.
Now I am at this point, I didn't manage to resolve this problem.
This is with S60 3rd FP1. |
|
|
|
(0019562)
|
|
Alex Neundorf
|
|
2010-02-21 10:47
|
|
Ok. First I'd like to find out why you had to use CMAKE_FORCE_C_COMPILER().
Can you please post the output of cmake during the initial run in an empty build directory ?
Alex |
|
|
|
(0019563)
|
|
Mateusz Loskot
|
|
2010-02-21 10:49
|
|
|
|
|
(0019564)
|
|
Alex Neundorf
|
|
2010-02-21 10:50
|
|
If you build a program with the symbian tools, does it also link against C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/euser.lib, or does it link against other files ?
Alex |
|
|
|
(0019571)
|
|
Droscy
|
|
2010-02-21 13:58
|
|
> Ok. First I'd like to find out why you had to use CMAKE_FORCE_C_COMPILER().
> Can you please post the output of cmake during the initial run in an empty build directory ?
If I use Msys Makefile or Unix Makefile I get
# ===============================================================
# CMake Error: Could not COPY_FILE.
# OutputFile: ''
# copyFile: 'C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin'
#
# Unable to find executable for try_compile: tried "C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp/cmTryCompileExec.exe" and "C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe" and "C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe".
#
# Detecting CXX compiler ABI info - done
# CMake Error at C:/Programmi/CMake 2.9/share/cmake-2.9/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE):
# file STRINGS file
# "C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin"
# cannot be read.
# Call Stack (most recent call first):
# C:/Programmi/CMake 2.9/share/cmake-2.9/Modules/CMakeTestCXXCompiler.cmake:64 (CMAKE_DETERMINE_COMPILER_ABI)
# CMakeLists.txt:1 (project)
#
#
# *************** missing euser
# CMake Error at CMakeLists.txt:30 (symbian_add_executable):
# Unknown CMake command "symbian_add_executable".
# ===============================================================
If I use MinGW Makefile I get
# ===============================================================
# CMake Error at C:/Programmi/CMake 2.9/share/cmake-2.9/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE):
# The C++ compiler "C:/Programmi/File comuni/Symbian/tools/g++.exe" is not
# able to compile a simple test program.
#
# It fails with the following output:
#
# Change Dir: C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp
#
# Run Build Command:C:/MinGW/bin/mingw32-make.exe "cmTryCompileExec/fast"
#
# C:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTryCompileExec.dir\build.make
# CMakeFiles/cmTryCompileExec.dir/build
#
# mingw32-make.exe[1]: Entering directory
# `C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp'
#
#
# "C:\Programmi\CMake 2.9\bin\cmake.exe" -E cmake_progress_report
# C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\build\CMakeFiles\CMakeTmp\CMakeFiles
# 1
#
# Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o
#
# C:\PROGRA~1\FILECO~1\Symbian\tools\G__~1.EXE -o
# CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.o -c
# C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\build\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
#
#
# Sorry, \epoc32\gcc\bin\g++.exe is not supported in this release. Please
# use a different device. Use 'devices' to view the available devices.
#
# mingw32-make.exe[1]: ***
# [CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o] Error 2
#
# mingw32-make.exe[1]: Leaving directory
# `C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp'
#
# mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
#
# CMake will not be able to correctly generate this project.
# Call Stack (most recent call first):
# CMakeLists.txt:1 (project)
# ===============================================================
> If you build a program with the symbian tools, does it also link against
> C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/euser.lib, or does it link against
> other files ?
I cannot understand if it links against that file, but in the generated HELLOWORLD.GCCE by abld there is this:
LIBSUREL= \
-( \
$(EPOCSTATLINKUREL)\usrt2_2.lib \
-) \
$(EPOCLIB)\LIB\euser.dso \
$(EPOCLIB)\LIB\dfpaeabi.dso \
$(EPOCLIB)\LIB\dfprvct2_2.dso \
$(EPOCLIB)\LIB\drtaeabi.dso \
$(EPOCLIB)\LIB\scppnwdl.dso \
$(EPOCLIB)\LIB\drtrvct2_2.dso \
$(STATIC_LIBS_LIST)
where $(EPOCLIB) points to \Symbian\9.2\S60_3rd_FP1\EPOC32\RELEASE\ARMV5, so I think that it links against that file.
If you need some automatic-generated files tell me, I'll upload them. |
|
|
|
(0019581)
|
|
Alex Neundorf
|
|
2010-02-22 16:20
|
|
From your output:
# Sorry, \epoc32\gcc\bin\g++.exe is not supported in this release. Please
# use a different device. Use 'devices' to view the available devices.
What does that mean ? Do you multiple compilers ?
Also, I think there is something missing in the cmake output.
Did you post everything starting at the very first line of output ?
If so, there were probably still the FORCE_COMPILER() calls in the cmake files.
The first messages should be about determining the compiler ID.
Alex |
|
|
|
(0019592)
|
|
Droscy
|
|
2010-02-23 05:39
|
|
> From your output:
> # Sorry, \epoc32\gcc\bin\g++.exe is not supported in this release. Please
> # use a different device. Use 'devices' to view the available devices.
> What does that mean ? Do you multiple compilers ?
No, I don't.
> Did you post everything starting at the very first line of output ?
No, I posted only from the firt error line...
I noticed that the first error line reports: The C++ compiler "C:/Programmi/File comuni/Symbian/tools/g++.exe" is not able to compile a simple test program. This because "C:/Programmi/File comuni/Symbian/tools" folder doesn't exist. I remove that folder from system PATH variable.
Now if a choose Unix Makefile i get (complete output from the first line)
# CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
# CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
# Missing variable is:
# CMAKE_CXX_COMPILER_ENV_VAR
# CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
# Missing variable is:
# CMAKE_CXX_COMPILER
# CMake Error: Could not find cmake module file:C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeCXXCompiler.cmake
# CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
# Configuring incomplete, errors occurred!
Instead if I use MinGW or Msys Makefile I get this http://pastry.se/216007/ [^] |
|
|
|
(0019599)
|
|
Alex Neundorf
|
|
2010-02-23 16:19
|
|
The CXX compiler identification is GNU
SYMBIAN_EPOCROOT="C:/Symbian/9.2/S60_3rd_FP1/Epoc32"
SYMBIAN_ecrt0_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/ecrt0.lib
SYMBIAN_edll_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/edll.lib
SYMBIAN_edllstub_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/edllstub.lib
SYMBIAN_eexe_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/eexe.lib
SYMBIAN_mcrt0_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/mcrt0.lib
SYMBIAN_usrt2_2_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/usrt2_2.lib
SYMBIAN_wecrt0_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/wecrt0.lib
SYMBIAN_wmcrt0_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/wmcrt0.lib
SYMBIAN_dfpaeabi_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/dfpaeabi.lib
SYMBIAN_dfprvct2_2_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/dfprvct2_2.lib
SYMBIAN_drtaeabi_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/drtaeabi.lib
SYMBIAN_scppnwdl_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/scppnwdl.lib
SYMBIAN_drtrvct2_2_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/drtrvct2_2.lib
SYMBIAN_euser_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/euser.lib
SYMBIAN_apparc_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/apparc.lib
SYMBIAN_cone_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/cone.lib
SYMBIAN_eikcore_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/eikcore.lib
SYMBIAN_avkon_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/avkon.lib
SYMBIAN_commonengine_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/commonengine.lib
SYMBIAN_efsrv_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/efsrv.lib
SYMBIAN_estor_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/estor.lib
SYMBIAN_dfpaeabi_LIBRARY="C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/dfpaeabi.lib"
SYMBIAN_CXX_STDLIB_PATH="C:/MinGW/lib/gcc/mingw32/3.4.5"
SYMBIAN_CXX_LIBSUPCPP_PATH="/MinGW/lib"
Check for working CXX compiler: C:/MinGW/bin/g++.exe
Check for working CXX compiler: C:/MinGW/bin/g++.exe -- broken
CMake Error at C:/Programmi/CMake 2.9/share/cmake-2.9/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "C:/MinGW/bin/g++.exe" is not able to compile a simple
test program.
It fails with the following output:
Change Dir: C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp
Run Build Command:C:/MinGW/bin/mingw32-make.exe "cmTryCompileExec/fast"
C:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp'
"C:\Programmi\CMake 2.9\bin\cmake.exe" -E cmake_progress_report
C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\build\CMakeFiles\CMakeTmp\CMakeFiles
1
Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o
C:\MinGW\bin\g++.exe -IC:/Symbian/9.2/S60_3rd_FP1/Epoc32/include
-IC:/Symbian/9.2/S60_3rd_FP1/Epoc32/include/variant -include
C:/Symbian/9.2/S60_3rd_FP1/Epoc32/include/gcce/gcce.h
-D__PRODUCT_INCLUDE__=C:/Symbian/9.2/S60_3rd_FP1/Epoc32/include/variant/symbian_os_v9.1.hrh
-D__SYMBIAN32__ -D__EPOC32__ -D__GCCE__ -D_UNICODE -D__EXE__
-D__SUPPORT_CPP_EXCEPTIONS__ -D__MARM__ -D__EABI__ -D__MARM_ARMV5__
-nostdinc -msoft-float -march=armv5t -mapcs -fexceptions -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.o -c
C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\build\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
cc1plus.exe: error: invalid option `apcs'
C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\build\CMakeFiles\CMakeTmp\testCXXCompiler.cxx:1:
error: bad value (armv5t) for -march= switch
C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\build\CMakeFiles\CMakeTmp\testCXXCompiler.cxx:1:
error: bad value (armv5t) for -mtune= switch
mingw32-make.exe[1]: ***
[CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:1 (project)
Configuring incomplete, errors occurred! |
|
|
|
(0019600)
|
|
Alex Neundorf
|
|
2010-02-23 16:24
|
|
This doesn't look too bad actually.
It just complains about bad compiler arguments -mapcs and -march=armv5t.
These are set in Modules/Platform/Symbian-GNU-Common.cmake
Which compiler options do you get with a "normal" symbian-style build ?
The question is whether the difference is due to the different symbian version or because I'm doing that from Linux and you are using it from Windows.
Alex |
|
|
|
(0019604)
|
|
Droscy
|
|
2010-02-24 09:15
|
|
> Which compiler options do you get with a "normal" symbian-style build ?
I'll look for this and I'll answer.
But, just one question: why is CMake finding "C:/MinGW/bin/g++.exe" as compiler? Shouldn't it find "C:/Programmi/CSL Arm Toolchain/bin/arm-none-symbianelf-g++.exe" as I've set on toolchain file? |
|
|
|
(0019607)
|
|
Droscy
|
|
2010-02-24 10:20
|
|
> Which compiler options do you get with a "normal" symbian-style build ?
It uses both -mapcs and -march=armv5t
But wait! Something strange happened: now the folder "C:/Programmi/File comuni/Symbian/tools", that I removed from system path, exists and it is needed to build HelloWorld with standard Symbian tools. Maybe I made some mistakes yesterday.
Re-adding it to PATH I get the following output from CMake:
### Using Unix Makefile
# The CXX compiler identification is GNU
# SYMBIAN_EPOCROOT="C:/Symbian/9.2/S60_3rd_FP1/Epoc32"
# SYMBIAN_ecrt0_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/ecrt0.lib
# SYMBIAN_edll_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/edll.lib
# SYMBIAN_edllstub_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/edllstub.lib
# SYMBIAN_eexe_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/eexe.lib
# SYMBIAN_mcrt0_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/mcrt0.lib
# SYMBIAN_usrt2_2_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/usrt2_2.lib
# SYMBIAN_wecrt0_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/wecrt0.lib
# SYMBIAN_wmcrt0_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/urel/wmcrt0.lib
# SYMBIAN_dfpaeabi_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/dfpaeabi.lib
# SYMBIAN_dfprvct2_2_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/dfprvct2_2.lib
# SYMBIAN_drtaeabi_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/drtaeabi.lib
# SYMBIAN_scppnwdl_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/scppnwdl.lib
# SYMBIAN_drtrvct2_2_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/drtrvct2_2.lib
# SYMBIAN_euser_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/euser.lib
# SYMBIAN_apparc_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/apparc.lib
# SYMBIAN_cone_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/cone.lib
# SYMBIAN_eikcore_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/eikcore.lib
# SYMBIAN_avkon_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/avkon.lib
# SYMBIAN_commonengine_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/commonengine.lib
# SYMBIAN_efsrv_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/efsrv.lib
# SYMBIAN_estor_LIBRARY C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/estor.lib
# SYMBIAN_dfpaeabi_LIBRARY="C:/Symbian/9.2/S60_3rd_FP1/Epoc32/release/armv5/lib/dfpaeabi.lib"
# SYMBIAN_CXX_STDLIB_PATH="C:/MinGW/lib/gcc/mingw32/3.4.5"
# SYMBIAN_CXX_LIBSUPCPP_PATH="/MinGW/lib"
# Check for working CXX compiler: C:/MinGW/bin/c++.exe
# Check for working CXX compiler: C:/MinGW/bin/c++.exe -- works
# Detecting CXX compiler ABI info
# CMake Error: Could not COPY_FILE.
# OutputFile: ''
# copyFile: 'C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin'
#
# Unable to find executable for try_compile: tried "C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp/cmTryCompileExec.exe" and "C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe" and "C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe".
#
# Detecting CXX compiler ABI info - done
# CMake Error at C:/Programmi/CMake 2.9/share/cmake-2.9/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE):
# file STRINGS file
# "C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin"
# cannot be read.
# Call Stack (most recent call first):
# C:/Programmi/CMake 2.9/share/cmake-2.9/Modules/CMakeTestCXXCompiler.cmake:64 (CMAKE_DETERMINE_COMPILER_ABI)
# CMakeLists.txt:1 (project)
#
#
# *************** got euser
# _codeSegmentStart="_codeSegmentStart-NOTFOUND"
# Configuring incomplete, errors occurred!
### Using MinGW Makefile
# The CXX compiler identification is unknown
# Check for working CXX compiler: C:/Programmi/File comuni/Symbian/tools/g++.exe
# Check for working CXX compiler: C:/Programmi/File comuni/Symbian/tools/g++.exe -- broken
# CMake Error at C:/Programmi/CMake 2.9/share/cmake-2.9/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE):
# The C++ compiler "C:/Programmi/File comuni/Symbian/tools/g++.exe" is not
# able to compile a simple test program.
#
# It fails with the following output:
#
# Change Dir: C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp
#
# Run Build Command:C:/MinGW/bin/mingw32-make.exe "cmTryCompileExec/fast"
#
# C:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTryCompileExec.dir\build.make
# CMakeFiles/cmTryCompileExec.dir/build
#
# mingw32-make.exe[1]: Entering directory
# `C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp'
#
#
# "C:\Programmi\CMake 2.9\bin\cmake.exe" -E cmake_progress_report
# C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\build\CMakeFiles\CMakeTmp\CMakeFiles 1
#
# Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o
#
# C:\PROGRA~1\FILECO~1\Symbian\tools\G__~1.EXE -o
# CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.o -c
# C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\build\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
#
#
# Sorry, \epoc32\gcc\bin\g++.exe is not supported in this release. Please
# use a different
#
# device. Use 'devices' to view the available devices.
#
# mingw32-make.exe[1]: ***
# [CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o] Error 2
#
# mingw32-make.exe[1]: Leaving directory
# `C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeTmp'
#
#
# mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
#
#
# CMake will not be able to correctly generate this project.
# Call Stack (most recent call first):
# CMakeLists.txt:1 (project)
#
#
# Configuring incomplete, errors occurred!
Why neither the first nor the second look for the right g++ compiler? |
|
|
|
(0019612)
|
|
Alex Neundorf
|
|
2010-02-24 16:46
|
|
Your toolchain file should look like that:
# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Symbian)
SET(SYMBIAN_EPOCROOT "C:/Symbian/9.2/S60_3rd_FP1/Epoc32" )
# which C and C++ compiler to use
set(CMAKE_C_COMPILER "C:/Programmi/CSL Arm Toolchain/bin/arm-none-symbianelf-gcc.exe")
set(CMAKE_CXX_COMPILER "C:/Programmi/CSL Arm Toolchain/bin/arm-none-symbianelf-g++.exe")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Then it should really use that compiler.
Does that work ?
Alex |
|
|
|
(0019616)
|
|
Droscy
|
2010-02-25 02:34
(edited on: 2010-02-25 02:44) |
|
That is my file, but it doesn't work. I get the error reported on the previews post. CMake uses "C:/MinGW/bin/g++.exe" instead of "C:/Programmi/CSL Arm Toolchain/bin/arm-none-symbianelf-g++.exe"
If I remove every path exept the right one (C:/Programmi/CSL Arm Toolchain/bin/) I get:
### Unix Makefile
CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER
CMake Error: Could not find cmake module file:C:/Symbian/9.2/S60_3rd_FP1/Examples/Basics/HelloWorld/build/CMakeFiles/CMakeCXXCompiler.cmake
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
Configuring incomplete, errors occurred!
### MinGW makefile: CMake continue to look for C:/MinGW/bin/g++.exe
After your CMake configuration, which is the value of CMAKE_MAKE_PROGRAM variable? Because I don't have a make.exe file in C:/Programmi/CSL Arm Toolchain/bin/ so if CMake uses C:/MinGW/bin/make.exe it also tries to use C:/MinGW/bin/g++.exe, instead if CMake uses C:/Programmi/File Comuni/Symbian/tools/bin/make.exe it tries to use C:/Programmi/File Comuni/Symbian/tools/bin/g++.exe but none of them are correct.
|
|
|
|
(0019652)
|
|
Alex Neundorf
|
|
2010-02-26 16:25
|
|
No, something must be going wrong.
If CMAKE_C_COMPILER is already set, CMake doesn't look for another one.
Did you try that each time from a completely fresh (empty) build dir ?
If there was already a CMakeCache.txt, it will not search for another compiler.
And you do
cmake -DCMAKE_TOOLCHAIN_FILE=your_toolchain_file.cmake path/to/CMakeLists.txt ?
Alex |
|
|
|
(0019707)
|
|
Droscy
|
|
2010-03-04 05:22
|
|
Yes, I execute cmake in an empty build folder. I use cmake-gui on Windows, but if I use the command-line version I get the same result.
> cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\Toolchain-symbian-gcc.cmake ..
The first 3 lines of output are:
# The CXX compiler identification is unknown
# Check for working CXX compiler: C:/Programmi/File comuni/Symbian/tools/g++.exe
# Check for working CXX compiler: C:/Programmi/File comuni/Symbian/tools/g++.exe -- broken
> cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\Toolchain-symbian-gcc.cmake ..
After all the SYMBIAN_libs I get
# Check for working CXX compiler: C:/MinGW/bin/c++.exe
# Check for working CXX compiler: C:/MinGW/bin/c++.exe -- works
Looking at my previews posts I noticed this line: "SYMBIAN_CXX_STDLIB_PATH="C:/MinGW/lib/gcc/mingw32/3.4.5"
Why is cmake looking in that folder?
Should I use different makefile generators? |
|
|
|
(0019714)
|
|
Alex Neundorf
|
|
2010-03-04 15:31
|
|
> cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=C:\Symbian\9.2\S60_3rd_FP1\Examples\Basics\HelloWorld\Toolchain-symbian-gcc.cmake ..
The first 3 lines of output are:
# The CXX compiler identification is unknown
# Check for working CXX compiler: C:/Programmi/File comuni/Symbian/tools/g++.exe
# Check for working CXX compiler: C:/Programmi/File comuni/Symbian/tools/g++.exe -- broken
What happens if you just call "c:/..../g++.exe main.cpp" with a hello-world style main.cpp on the command line ?
Does it build it ?
Alex |
|
|
|
(0019797)
|
|
Assaf Raman
|
|
2010-03-10 08:28
|
|
Hi all,
My name is Assaf Raman and I am an OGRE team member (www.ogre3d.org).
We have been working on porting OGRE to Symbian.
OGRE uses cmake - so - we needed a version of cmake that support Symbian mmp files (to be used with Carbide.c++).
Sadly - I found out about this bug report from Bill Hoffman after I finished my own version of the same work as you have been doing here and sent my patch directly to Bill's e-mail. I am to blame, I guess I should have done more research before doing the work (about seven full days worth of work).
With our patch I am able to create the mmp and the bld.inf file for OGRE trunk - then open the result with Carbide.c++ and compile OGRE.
You can see a video of the result here: http://www.youtube.com/watch?v=HsRFcx6V6hw [^]
I had a look at your work and it is in really good quality.
I think that our work covers some areas that your doesn't and vice versa.
I attached a patch of our work to this bug report.
What all of us want is to get the Symbian support the official release of cmake, that will be best for the cmake users.
What is on the todo list before this is done? I offer my assistance.
Regards,
Assaf Raman |
|
|
|
(0019798)
|
|
Bill Hoffman
|
|
2010-03-10 09:23
|
|
I would like to see this effort move forward. It seems that the approaches are a bit different. Assaf has a new generator, and the other patch seems to use the makefiles. I have not had the time to look into this in great detail. Are the efforts the same or not? To move forward with this effort, I would like a dashboard running. I think Assaf has made some good progress with running the CMake tests with the Symbian generator he created. It would be great if all interested parties could work together to create a solution that passes the CMake tests cases and runs a nightly dashboard. At that point, we can move this work into git master of CMake, and avoid anyone else doing the same thing again in the future... :)
Thanks for the contribution to CMake, I am excited that we will be able to support Symbian soon! |
|
|
|
(0019805)
|
|
Assaf Raman
|
|
2010-03-10 10:45
|
|
Regarding the CMake tests:
1. A part of the tests is to run exe and get the result, I was able to run the emulation as part of the tests run.
2. Some of the test are of dll projects - on Symbian dll are different then on other platforms, for the tests to work - we will need to add #ifdef SIMBIAN or the sort for them to work.
3. There are tests that you can treat c files as cpp files and the other visa versa, I didn't write the code for it yet - but the only solution I can think of is creating a cpp file with the same name and having an #include to the original file - not that elegant - but it will work.
4. There are some test that look for files - the files are on a local folder next to the code - but when you run the emulation - you can't reach the source folder from the emulation - we will need to copy the files to the emulation folder for it to work. |
|
|
|
(0019809)
|
|
Bill Hoffman
|
|
2010-03-10 11:49
|
|
1, and 2 sounds doable...
For 3, is there no command line switch to force a .c file to use the c++ compiler? Can you call the c++ compiler and pass it a .c file?
4. These tests may need some re-factoring, or have to be skipped. |
|
|
|
(0019816)
|
|
Alex Neundorf
|
|
2010-03-10 15:52
|
|
I'm currently trying to get the makefile generator to work for Symbian. I think it is actually mostly working (... at least for my setup), where I'm currently a bit stuck is with the stuff to do after having linked an executable, to turn it into something which can be installed on Symbian.
I myself will not be able to maintain a mmp-generator once it has found its way into cmake. OTOH maintaining the platform-files necessary to generate valid makefiles for symbian is something I can do I think.
...and it would be nice if the normal build tools/IDEs could be used for symbian development, instead of there own weird stuff.
But I really don't object to an mmp-generator, it's just that I myself will not be able to maintain it.
Alex |
|
|
|
(0019817)
|
|
Alex Neundorf
|
|
2010-03-10 15:53
|
|
Is you generator also working under Linux ?
IIRC the official tools from Symbian are for Windows only.
Alex |
|
|
|
(0019820)
|
|
Bill Hoffman
|
|
2010-03-10 16:50
|
|
|
I would not mind having both, but they have to be tested on the dashboard before they go into CMake. That is the big requirement. If it was shown to be working and easy to setup, Kitware "might" be able to host the dashboard. |
|
|
|
(0019823)
|
|
Assaf Raman
|
|
2010-03-10 17:51
|
|
@bill.hoffman
Regarding item 3 on my CMake tests issues - the test SetLang is the one I mean - it has this line in the CMakeLists.txt file:
set_source_files_properties(foo.c bar.c PROPERTIES LANGUAGE CXX)
Look at foo.c line 5 - it declares a local var after a function statement - illegal in c. This is what using set_source_files_properties with CXX as a parameter means - this file has c ext - but you need to compile it as c++.
What I suggested was an idea how to support set_source_files_properties in a mmp file. Moreover - cxx compiles as c - so I can also solve this issue by creating the new c\cpp files.
Regarding my patch - well - the aim of my work was to have a project that works with the tools provided by the Symbian guys, my target users are Symbian developers - and I assume that most of them will want to compile and debug using Carbide.c++ or from command line. I based my work on the tutorials I found on Symbian.org.
I created a working dashboard for most samples already (part of the patch I attached to this bug) and I described the solutions for the problematic samples.
I can even run the dashboard on my computer for a few weeks until it is stable.
The setup of an environment is two setups from Nokia on a windows computer and you are good to go - so we can later see if you take it, this can be worked out later - don't worry about it.
The code I looked at was the Symbian branch on AlexeyS git, from what I saw there - mmp files were created - but from what I read from neundorf now - he doesn't want to maintain the mmp output - so I guess what we can do is this - I will get all the relevant tests going using my code and run the dashboard on my computer for now. When Bill will feel good about the test results - he will commit my work to the cmake trunk (to be released in the next version of cmake).
My generator has a different name then the neundorf one - since we both have different targets (I target Carbide.c++ and he target makefiles) - there is no harm having both in cmake as Bill suggested (like Microsoft vs Borland on windows).
Bill - is this a go for more work on my side? I don't mind doing the work - but I do want my work to be released as part of CMake (After it does the job, the code is clear and it follows CMake coding standards). |
|
|
|
(0019862)
|
|
Sergey Rudchenko
|
|
2010-03-13 05:27
|
|
@Alex
I was developing both on Windows with official SDK. The .mmp generator is used in production for about 1.5 years already.
Sergey |
|
|
|
(0019871)
|
|
Bill Hoffman
|
|
2010-03-13 17:04
|
|
|
Sergey are you interested in working with Assaf to clean up and finish the .mmp generator? I would like to get this work tested and into CMake master. Sergey do you know how to force the compiler to compile a file as C++ no matter the extension with the .mmp? |
|
|
|
(0019951)
|
|
Droscy
|
|
2010-03-18 03:35
|
|
Hi Alex, I'm sorry for the late answer but I've been busy.
If I execute "c:/..../g++.exe main.cpp" manually I get:
"Sorry \epoc32\gcc\bin\g++.exe is not supported in this release. Please use a different device. Use `devices` to view the available devices"
But, as reported here http://discussion.forum.nokia.com/forum/showthread.php?t=90329 [^] the g++.exe program cannot be executed directly. |
|
|
|
(0019956)
|
|
Bill Hoffman
|
|
2010-03-18 08:52
|
|
Sergey, you say: "The .mmp generator is used in production for about 1.5 years"
Assaf is working on a new .mmp generator, would you be willing test his generator and make sure it works as good as the one you are using? It should have the best of both in it, but I would like a second party to verify that by trying it out. We are going to try and get some more tests working with the generator, and then push it into cmake master, so it would be great if you could verify it. Do not try the patches in this bug as Assaf is still working on it.
Assaf, can you post a "link" to your most recent patches somewhere for testing? |
|
|
|
(0019958)
|
|
Assaf Raman
|
|
2010-03-18 10:19
|
|
No problem - I will post my current work.
Before that - I think we should split my work to a new "bug report" - what do you think? |
|
|
|
(0019961)
|
|
Assaf Raman
|
|
2010-03-18 21:22
|
|
|
|
|
(0019966)
|
|
Assaf Raman
|
|
2010-03-19 20:45
|
|
|
|
|
(0020014)
|
|
Assaf Raman
|
|
2010-03-26 09:38
|
|
I fixed some issues raised by Brad King:
Here is an updated patch: https://docs.google.com/leaf?id=0BzHCK1hf14h2OGI1ODkxOWItNWUyMS00NzA0LWJmMTQtNTUwNDBkMjMwMmE1&hl=en [^]
The Compiler Id renamed to “Carbide".
refactored Modules/Platform/Symbian.cmake – moved language-specific stuff to -Carbide-C.cmake and Symbian-Carbide-CXX.cmake
Fixed cxx as c++ extension support test (and removed SET(CMAKE_CXX_COMPILER_WORKS 1 CACHE INTERNAL ""))
Renamed "CMake_BUILD_EXE_DIR" to " "Symbian_OUTPUT_DIR"
Removed an unneeded function - cmGlobalCarbideGenerator::AddPlatformDefinitions
Fixed some more test Symbian DLL export (I hope I finished them all).
In the Symbian emulation compile - _WIN32 and WIN32 are defined – I needed to fix some of the test to reflect that (EX: “#if defined(_WIN32) && !defined(__SYMBIAN32__)” )
Bill also recommend adding support for static v. shared system libraries flags in the mmp file - but from what I have seem - this is not relevant any more, at least not relevant for the emulation. |
|
|
|
(0020029)
|
|
Alex Neundorf
|
|
2010-03-29 15:31
|
|
Hi Assaf,
I had a look at your patch and have some questions:
Why do you need the special handling in CMakeDetermineCCompiler.cmake for Symbian ? I don't know about Carbide, but with the gcc compiler for Symbian I was able to get it working without any special handling. Where/what fails otherwise ?
CMAKE_C/CXX_STANDARD_LIBRARIES_INIT: do really all applications have to link against all these libs ? Why doesn't commonengine and estor appear in this list ? They seem to be used here on my installation (S60 3rd edition).
Is Carbide actually using the GNU compiler or the MS compiler ? Or can it be used with both ?
Alex |
|
|
|
(0020034)
|
|
Assaf Raman
|
|
2010-03-30 16:34
|
|
I fixed one more issue raised by Brad King:
Here is an updated patch: https://docs.google.com/leaf?id=0BzHCK1hf14h2OWNlNzVmZWItY2Q0MS00YWE1LTkzYzgtY2I0YmI5YTBiZWYx&hl=en [^]
I replaced the Symbian_Carbide_OUTPUT_DIR prop with a function named GetPlatformRuntimeDirectory that I added to cmGlobalGenerator and override it in cmGlobalCarbideGenerator.
@Alex: I found the the special handling in CMakeDetermineCCompiler.cmake for Symbian an easy way to make sure the CMAKE_CXX_PLATFORM_ID is right. Moreover - Carbide uses all sort of compilers - it really depends on your output - so what I am saying is that the same cmake output can be used for more then one compile - so I don't want to detect the compiler here in this case - but to set it manually to Carbide. I think we can live with my code for now - later we can improve - this shouldn't keep the the patch commit to the main cmake branch.
Regarding CMAKE_C/CXX_STANDARD_LIBRARIES_INIT - I don't know about commonengine and estor - but the rest seem to be in common use in most of the symbian code samples that come with the SDK - so I added them - we can also improve this in the future. |
|
|
|
(0020035)
|
|
Assaf Raman
|
|
2010-03-30 17:09
|
|
|
|
|
(0020088)
|
|
Sergei Krivonos
|
|
2010-04-07 10:39
|
|
Hi everyone.
I am working with Sergei Rudchenko.
How soon can we expect the changes to be in upstream?
How can we participiate to make this moment closer?
Very big thanks! |
|
|
|
(0020089)
|
|
Bill Hoffman
|
|
2010-04-07 11:28
|
|
The best way to help would be to figure out why so many tests are failing:
http://www.cdash.org/CDash/viewTest.php?onlyfailed&buildid=580668 [^]
The ones that use code generators I am willing to disable, and tell people that if they have code generators they have to use two build trees and imported targets. A special test that does that would be great as well. However, many of the other tests are failing for some other reason. They seem to be building things, but ctest can not find them. Also, it looks like out of source source is not working, so calls like this add_subdirectory(../CTestTest/SmallAndFast) fail. It seems to be only a few issues left. We should have an explanation for each failed test because as soon as this becomes part of CMake, people will try code that uses those cases.... :)
Thanks, I think this is very close! |
|
|
|
(0020099)
|
|
Assaf Raman
|
|
2010-04-07 17:36
|
|
|
|
|
(0020114)
|
|
Alex Neundorf
|
|
2010-04-09 15:14
|
|
Is CMAKE_CROSSCOMPILING set to TRUE with your generator ?
Normally, CMAKE_CROSSCOMPILING is set to TRUE in CMakeDetermineSystem.cmake when CMAKE_SYSTEM_NAME is already set when this file is processed.
Is this the case with your patch ?
If not, I guess the Carbide generator could set it explicitely to TRUE.
Alex |
|
|
|
(0020117)
|
|
Assaf Raman
|
|
2010-04-09 20:46
|
|
I am not sure what the value for "CMAKE_CROSSCOMPILING" is in my patch - but the right value may be also "false" - I am not sure this is a clear case.
If the target is the emulator - you do get an a win32 exe you can run and test.
CMake can autodetect the target system.
Dependencies can be searched.
So - basically I don't think that CMAKE_CROSSCOMPILING is the case here.
Correct me if you think differently. |
|
|
|
(0020121)
|
|
Alex Neundorf
|
|
2010-04-10 15:12
|
|
Can you please put something like
message(STATUS "cross compiling: ${CMAKE_CROSSCOMPILING}")
into one of you CMakeLists.txt (e.g. the toplevel one) and see what it prints ?
I'd say something is cross compiling if
* you cannot execute the executables on the build host
* you are not using the system libraries of the build host, but a special set
> If the target is the emulator - you do get an a win32 exe you can run and
> test.
In this case it's maybe not cross compiling, but... you are loading Symbian.cmake, and not Windows.cmake. Yes, this is not a completely clear case.
When not building for this emulator it clearly is cross compiling.
> CMake can autodetect the target system.
How ?
Can you implement such a check and set/unset CMAKE_CROSSCOMPILING accordingly ?
Alex |
|
|
|
(0020123)
|
|
Alex Neundorf
|
|
2010-04-10 18:35
|
|
I have a few more questions.
You do
diff --git a/Modules/CMakePlatformId.h.in b/Modules/CMakePlatformId.h.in
index e20348a..cdfd384 100644
--- a/Modules/CMakePlatformId.h.in
+++ b/Modules/CMakePlatformId.h.in
@@ -77,6 +77,9 @@
#elif defined(__XENIX__) || defined(_XENIX) || defined(XENIX)
# define PLATFORM_ID "Xenix"
+#elif defined(__SYMBIAN32__)
+# define PLATFORM_ID "Symbian"
+
#else /* unknown platform */
# define PLATFORM_ID ""
Somewhere I found (don't remember right now, where it was) that not only for __SYMBIAN32__ should be tested, but also for __symbian__ .
Would you mind adding this, or do you object to that ?
In the initial patch posted to this issue here there is also the following patch contained:
Index: Source/cmTarget.cxx
===================================================================
RCS file: /cvsroot/CMake/CMake/Source/cmTarget.cxx,v
retrieving revision 1.286
diff -b -u -p -r1.286 cmTarget.cxx
--- Source/cmTarget.cxx 13 Jan 2010 18:00:29 -0000 1.286
+++ Source/cmTarget.cxx 10 Apr 2010 21:41:34 -0000
@@ -1010,7 +1010,8 @@ void cmTarget::SetMakefile(cmMakefile* m
// Check whether this is a DLL platform.
this->DLLPlatform = (this->Makefile->IsOn("WIN32") ||
this->Makefile->IsOn("CYGWIN") ||
- this->Makefile->IsOn("MINGW"));
+ this->Makefile->IsOn("MINGW") ||
+ this->Makefile->IsOn("SYMBIAN"));
As far as I can see this is not done in your patches. Why ?
diff --git a/Modules/CMakeCCompilerABI.c b/Modules/CMakeCCompilerABI.c
index e6a07f4..5f3ebf0 100644
--- a/Modules/CMakeCCompilerABI.c
+++ b/Modules/CMakeCCompilerABI.c
@@ -1,7 +1,12 @@
#ifdef __cplusplus
-# error "A C++ compiler has been selected for C."
+# ifdef __SYMBIAN32__
+ A_C++_compiler_has_been_selected_for_C
+# else
+# error "A C++ compiler has been selected for C."
+# endif
#endif
Why do you do this ?
When building for Symbian with gcc, #error works.
Doesn't it work for you, and in which way does it not work then ?
Alex |
|
|
|
(0020125)
|
|
Assaf Raman
|
|
2010-04-11 04:50
|
|
@Alex Neundorf: CMAKE_CROSSCOMPILING is not defined for now.
Regarding "CMake can autodetect the target system" - I guess we are not talking about the same thing - so just to be clear - what do you mean by "target system"?
Regarding the CMAKE_CROSSCOMPILING value in this case - it should be false. Because you can compile the an exe that run the emulation and run - this is the case here, even if you can compile exe that only run on the device. This is the same as with visual studio - you can compile for 64 bit on a 32 bit computer (you can have a project with two configurations - one 32 and one 64) - it will not run when you compile the 32 bit config - is the flag on in that case?
Regarding the __SYMBIAN32__ - I make sure that this flag is defined in any mmp file I create - so don't worry - it always exists - so no need to check the other flag.
Regarding DLLPlatform - this member is unclear to me and I rather not touch that code if I don't know what it does. I think this is a small issue and you guys can patch later if you feel like it - it shouldn't keep my patch commit.
Regarding #error - well - it works in most case - but not in this case. In this case you get an internal compiler error when you compile from command line the code I changed. My solution gets the same result as an #error. I don't see any better workaround for now. I think we can live with it. I think it shouldn't keep the commit.
I am sure there are many other improvements and features that can be added to this generator - but I recommend committing the code and handling them later.
I think that the generator is usable for many real case and is a good base.
The generator can handle many complex cmake scenarios and can be tested with ctest.
This patch doesn't affect any other generator (as far as I can tell) - you can mark is as experimental or whatever - but I do recommend committing it in this stage. In it's current state - OGRE should be able to compile with it to a stage you can run it on the Symbian emulation - I am waiting for this patch commit before posting a "how to compile OGRE for Symbian", and I also have a patch for bullet physics - to enable bullet to compile for Symbian, I am waiting with the bullet patch for the patch here to be committed. |
|
|
|
(0020126)
|
|
Alex Neundorf
|
|
2010-04-11 05:14
|
|
Regarding __SYMBIAN32__:
Ok.
Regarding #error:
Ok. Maybe you can add a comment in the code which says that, because I guess everybody else would wonder why this is there.
Regarding DLLPlatform:
Brad, Sergey, can you please have a look ? This is about this patch:
Index: Source/cmTarget.cxx
===================================================================
RCS file: /cvsroot/CMake/CMake/Source/cmTarget.cxx,v
retrieving revision 1.286
diff -b -u -p -r1.286 cmTarget.cxx
--- Source/cmTarget.cxx 13 Jan 2010 18:00:29 -0000 1.286
+++ Source/cmTarget.cxx 10 Apr 2010 21:41:34 -0000
@@ -1010,7 +1010,8 @@ void cmTarget::SetMakefile(cmMakefile* m
// Check whether this is a DLL platform.
this->DLLPlatform = (this->Makefile->IsOn("WIN32") ||
this->Makefile->IsOn("CYGWIN") ||
- this->Makefile->IsOn("MINGW"));
+ this->Makefile->IsOn("MINGW") ||
+ this->Makefile->IsOn("SYMBIAN"));
Regarding '"CMake can autodetect the target system" ... what do you mean by "target system"? '
Well, you wrote that "CMake can autodetect the target system" in comment 20117. I assumed you mean that CMake can detect whether the stuff which is built for Symbian is built for ARM or for x86 Windows.
Did I understand correctly ?
For the case that the target is built for ARM, CMAKE_CROSSCOMPILING definitely should be on, also if there exists something to execute the executable under Windows. You are building for a different processor architecture, a different OS and use separate headers and libraries, so this is 100% cross compiling.
If the executable is built for the Windows Symbian emulator (i.e. it will be x86 code), we could argue whether it is cross compiling or not. If you think it's not, that's ok with me for now.
Regarding 32 vs. 64 bit Visual Studio builds:
CMAKE_CROSSCOMPILING is currently not set when doing this, but IMO it would be more correct if it was set. You will not be able to run the 64bit executables on the build host, so you have to handle e.g. add_custom_command() with generated executables differently. So, I think it should be set there too.
Alex |
|
|
|
(0020127)
|
|
Assaf Raman
|
|
2010-04-11 05:29
|
|
Regarding #error: - I will add a comment in the next patch I will post.
Regarding turning the CMAKE_CROSSCOMPILING on - where is the right place to do that? Should I add "set(CMAKE_CROSSCOMPILING TRUE)" to Symbian.cmake? I will wait for your replay before posting a patch for this.
Regarding the "target system" - well - the same mmp and bld.inf files are used when compiling to different targets, I can't guess what the target is going to be. |
|
|
|
(0020128)
|
|
Alex Neundorf
|
|
2010-04-11 06:19
|
|
Normally CMAKE_CROSSCOMPILING is set in Modules/CMakeDetermineSystem.cmake, there where also CMAKE_SYSTEM_NAME, CMAKE_HOST_SYSTEM_NAME etc. are set.
So I think this belongs together, so I would suggest to set CMAKE_CROSSCOMPILING in the same place where you set CMAKE_SYSTEM_NAME.
Alex |
|
|
|
(0020130)
|
|
Assaf Raman
|
|
2010-04-11 13:16
|
|
|
|
|
(0020136)
|
|
Bill Hoffman
|
|
2010-04-12 11:02
|
|
|
We should be able to use the CMAKE_CROSSCOMPILNG variable to disable or fix some of the tests. Assaf, can you create a wiki entry or some documentation on how to install the symbian tool set? |
|
|
|
(0020137)
|
|
Assaf Raman
|
|
2010-04-12 11:40
|
|
|
No problem, I will do that - then post a link to it here. |
|
|
|
(0020172)
|
|
Assaf Raman
|
|
2010-04-13 17:41
|
|
|
|
|
(0020734)
|
|
Kirill Tolstoluzhskiy
|
|
2010-05-13 16:29
|
|
Hello everyone!
Im also working with a Sergey as a symbian developer. Thanks Assaf for your great work on Carbide generator! I tried it with your last patches, and i have following questions:
1) Your are including stdapis/stlport by default. For this reason cmake fails to generate mmp with Symbian S60 FP1 sdk. Our project target old phones, which doesn't have OpenC installed, so we using estlib + custom version of stlport. Is there a way to disable references to that libs?
2) Compared to Sergey's generator, you set UID3 via cache variable and not via target properties as capability of app, etc. I think that your way is better.
3) I checked a source of your generator, and i didn't find there a staticlibrary keyword in mmp, to link with a static lib instead of import lib. Is it possible to do this with your current implementation?
4) We was using add_custom_command( ... POST_BUILD) to generate a sis file after exe build and sign it with a cert. I written a simple test which just add_executable and then add_custom_command. But I don't see any occurence of that command in .mk file. Are custom commands supported in your generator?
5) I see in your patches that you had cmSymbianBitmapSource, and then removed it. Are you going to put it back or you have a better way to add BITMAP section to the mmp file? |
|
|
|
(0020751)
|
|
Assaf Raman
|
|
2010-05-16 02:49
|
|
Hi Kirill,
1. You can change it in this script file: cmake\Modules\Platform\Symbian-Carbide-CXX.cmake or change the definition CMAKE_CXX_STANDARD_LIBRARIES - to whatever you want.
2. Great.
3. Well - I tested it and didn't see that the keyword had any effect, if you can give a sample that this is not true - I will add this issue to the open issues.
4. I am not sure, it should be supported as a line that will be added to one of the mk files.
5. Well - I copied the BITMAP code from the Sergey's code - but after thinking more about it I decided that the way the support was added will make it this patch harder to get excepted into cmake, because it added Symbian proprieties to the base generator or something of the sort. This is one of the open issues my generator still has.
Are there any other issues except the stlport, staticlibrary, add_custom_command and BITMAP that keeps you from using this generator in your project? |
|
|
|
(0020752)
|
|
Bill Hoffman
|
|
2010-05-16 13:45
|
|
|
A short note on 4, this is why the testing is so important. And, one of the reasons I am worried about the patch. It is failing too many tests that test things other than code generators and things that will never work with a cross compile setup like this. It is going to take some work to clean up the CMake tests to work better with this generator, but the effort will be well worth it. |
|
|
|
(0020925)
|
|
Kirill Tolstoluzhskiy
|
|
2010-06-04 10:14
|
|
Hello Assaf,
answering to your questions.
1. Thanks, that works well.
3. On library/staticlibrary. Which one keyword to use is important, i tried a simple test on 5th sdk. Two projects LIBRARY and EXE, if i reference to lib with LIBRARY keyword linker returns an error (arm-none-symbianelf-ld: <EPOC_DIR>\RELEASE\ARMV5\LIB\<libname>.dso: No such file: No such file or directory). So instead of looking for .lib linker looks for .dso file in this case. Using of STATICLIBRARY keyword solves this issue.
4. add_custom_command seems to be not supported. I'll try to setup tests with both yours and ours generator to see which issues do we have except this
What related to our project, i think we can move on your generator after fixing staticlibrary/custom_command and bitmap issues. |
|
|
|
(0020928)
|
|
Assaf Raman
|
|
2010-06-04 15:27
|
|
|
Thanks for answering, when I will find some time I will fix the issues you need. |
|
|
|
(0022024)
|
|
David Cole
|
|
2010-08-31 15:28
|
|
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. |
|
|
|
(0022277)
|
|
breezeight
|
|
2010-09-20 10:32
|
|
Hi,
thanks for the works on Carbide. I'm using QMake+QtCreator to develop on symbian. It generates .pkg files and then use make ( see here http://doc.qt.nokia.com/4.6/deployment-symbian.html [^]). Is it possible/hard to create a similar generator starting from the your carbide generator?
A lot of people is now working on symbian devices without Carbide and would be great to work with QtCreator and cmake. |
|
|
|
(0022281)
|
|
Assaf Raman
|
|
2010-09-20 11:08
|
|
|
@breezeight - My work was focused on Carbide, I don't know if QMake used the same file format. If not - most of my work is not relevant for you. |
|
|
|
(0023767)
|
|
Alex Neundorf
|
|
2010-12-07 15:10
|
|
|
|
|
(0024276)
|
|
shivaji badade
|
|
2010-12-20 08:15
|
|
Hi Assaf,
Not sure this is right place to ask...
But i m using Visual studio 9, and on top of master git of Cmake i applied the patch mentioned by u . I am getting following error in compilation.
3>cmCPackNSISGenerator.cxx
2>..\..\Source\cmGlobalCarbideGenerator.cxx(284) : error C2039: 'CreateGUID' : is not a member of 'cmGlobalCarbideGenerator'
2> c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : see declaration of 'cmGlobalCarbideGenerator'
2>..\..\Source\cmGlobalCarbideGenerator.cxx(285) : error C2039: 'CreateGUID' : is not a member of 'cmGlobalCarbideGenerator'
2> c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : see declaration of 'cmGlobalCarbideGenerator'
2>..\..\Source\cmGlobalCarbideGenerator.cxx(286) : error C2039: 'CreateGUID' : is not a member of 'cmGlobalCarbideGenerator'
2> c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : see declaration of 'cmGlobalCarbideGenerator'
2>..\..\Source\cmGlobalCarbideGenerator.cxx(287) : error C2039: 'CreateGUID' : is not a member of 'cmGlobalCarbideGenerator'
2> c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : see declaration of 'cmGlobalCarbideGenerator'
2>..\..\Source\cmGlobalCarbideGenerator.cxx(288) : error C2039: 'CreateGUID' : is not a member of 'cmGlobalCarbideGenerator'
2> c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : see declaration of 'cmGlobalCarbideGenerator'
2>..\..\Source\cmGlobalCarbideGenerator.cxx(289) : error C2039: 'CreateGUID' : is not a member of 'cmGlobalCarbideGenerator'
2> c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : see declaration of 'cmGlobalCarbideGenerator'
2>..\..\Source\cmGlobalCarbideGenerator.cxx(395) : error C2660: 'cmGlobalGenerator::TryCompile' : function does not take 7 arguments
I am not much familiar with CMake... and need symbian converter...
Thanks...
plz guide me to mailing list.... |
|
|
|
(0024277)
|
|
Assaf Raman
|
|
2010-12-20 08:31
|
|
|
Looks like you didn't apply all the patches in the list. |
|
|
|
(0024493)
|
|
David Cole
|
|
2011-01-06 16:47
|
|
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. |
|
|
|
(0026491)
|
|
Kalle Raita
|
|
2011-05-11 09:29
|
|
|
Apparently there is currently no target release for Symbian/Carbide support? Is there any way to make the releasing the feature more likely, apart from taking the patches and fixing unit test failures myself? |
|
|
|
(0026581)
|
|
Alex Neundorf
|
|
2011-05-25 16:15
|
|
I don't feel competent for the WinCE part, and personally I don't like the Carbide generator, I'd prefer a normal makefile-based generator.
So since I won't be driving this one forward, I'm unassigning it.
|
|
|
|
(0026584)
|
|
Andrew Manson
|
|
2011-05-25 16:38
|
|
Is it feasible to write a qmake file generator instead of a makefile generator for symbian? this you could support any platform that Qt officially supports.
Is this a possibly with the architecture of CMake? |
|
|
|
(0031752)
|
|
Brad King
|
|
2012-11-28 16:14
|
|
|
|
|
(0041500)
|
|
Kitware Robot
|
|
2016-06-10 14:27
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
symbian.patches (32,140) 2009-04-07 17:13
symbian_220409cvs.patch (39,236) 2009-04-22 12:52
SymbianGeneatorCreateByAssafFromOgre.zip (18,410) 2010-03-10 08:30