[CMake] MSVC10 redistributable issue
Hi,
I tried to install the following redistributable package after seeing the
issue below, but it did not help, not even after a reboot.
Got a clue?
Laszlo
=
-- Building for: Visual Studio 10
-- The C compiler identification is MSVC 16.0.30319.1
-- The CXX compiler identification is MSVC 16.0.30319.1
-- Check for working C compiler using: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 10
-- Check for working CXX compiler using: Visual Studio 10 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
--
-- == COLOURRAMP Build Information ==
-- Build Version: 0.1.0 (Technical Test)
-- Install Prefix: C:/Program Files (x86)/COLOURRAMP
-- Install the *.cmake files into CMake root (INSTALL_CMAKE_FILES): OFF
--
-- To change any of these options, override them using -D{OPTION_NAME} on the co
mmandline.
-- To build and install COLOURRAMP, run make and make install
--
CMake Warning at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/Instal
lRequiredSystemLibraries.cmake:343 (message):
system runtime library file does not exist:
'MSVC10_REDIST_DIR-NOTFOUND/x86/Microsoft.VC100.CRT/msvcp100.dll'
Call Stack (most recent call first):
cmake/CPack.cmake:1 (include)
CMakeLists.txt:81 (include)
CMake Warning at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/Instal
lRequiredSystemLibraries.cmake:343 (message):
system runtime library file does not exist:
'MSVC10_REDIST_DIR-NOTFOUND/x86/Microsoft.VC100.CRT/msvcr100.dll'
Call Stack (most recent call first):
cmake/CPack.cmake:1 (include)
CMakeLists.txt:81 (include)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Projects/colourramp/build
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC10 redistributable issue
How can I solve this issue with cmake from command line? On Thu, May 2, 2013 at 8:51 PM, John Drescher dresche...@gmail.com wrote: On Thu, May 2, 2013 at 3:35 PM, Laszlo Papp lp...@kde.org wrote: Hi, I tried to install the following redistributable package after seeing the issue below, but it did not help, not even after a reboot. Got a clue? It looks like you were not supposed to install the redistributable but to put it somewhere and tell cmake-gui where it was then hit generate. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] Suggestion: CMAKE_TOOLCHAIN_FILE warning improvement
Hi, Just found this post from Brad: http://www.cmake.org/pipermail/cmake/2011-February/042556.html I would suggest to improve the warning message. It is not exactly clear why that happens to a user like me. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
On Mon, Mar 18, 2013 at 1:10 PM, Florian Reinhard florian.reinh...@googlemail.com wrote: In addition compilers upto 7.2 did not support anything else than coff abi. So i don't see any valid reason to add --abi=eabi. Even more you usually set your silicon for improved optimizer results with e.g set_target_properties(myTarget PROPERTIES COMPILE_FLAGS -mv6740) and i see no reason not to add --abi=eabi there if one needs it. Well, EABI will most likely be upcoming as the default in the new TI versions. It will make no sense to use such an old legacy stuff mostly incompatible with the majority of the rest. Also, 7.2 was released a quite while ago, more than 2 years. If one still uses that version, that is likely a call for troubles. Texas Instruments discourage that, at least in our case, anyhow. By the way, Qt will have the EABI by default instead of the COFFABI. Here you can see the progress for that: https://codereview.qt-project.org/#change,51173 https://codereview.qt-project.org/#change,51233 https://codereview.qt-project.org/#change,51228 https://codereview.qt-project.org/#change,51078 ... and more to come. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
On Mon, Mar 18, 2013 at 1:33 PM, Florian Reinhard florian.reinh...@googlemail.com wrote: I still don't see that this is a valid reason to break things for others. There is no any breakage. Qt has never been used with the TI toolchain. ABI will be required from the start of the support. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Please verify that it works, so I can still get it into 2.8.11 hopefully. I just realized that the cmake files use the default ABI type which is still the legacy COFF, and not EABI. That is a bit unfortunate because we cannot put --abi=eabi in there due to the fact that the user would not be able to override that when COFF is desired. This is a toolchain limitation that you cannot define both, and the latter will be applied as one would think that. The consequence is that the majority of the people will need to define that explicitly. Unfortunately, not much we can do about it, but it is worth nothing. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
On Fri, Mar 15, 2013 at 9:52 AM, Florian Reinhard florian.reinh...@googlemail.com wrote: I'm testing the next branch at the moment. Changes i noticed: setting the following options is no longer required (yay!): SET (CMAKE_C_COMPILER_WORKS 1) SET (CMAKE_CXX_COMPILER_WORKS 1) #skip ABI checks SET (CMAKE_DETERMINE_C_ABI_COMPILED 1) SET (CMAKE_DETERMINE_CXX_ABI_COMPILED 1) SET (CMAKE_DETERMINE_ASM_ABI_COMPILED 1) I personally never needed them. questions: i still have to set CMAKE_C_COMPILER etc, what do i have to set, so cmake has a hint where to search for cl6x.exe? I would guess it is not a TI specific question. You can do this for instance: https://projects.kde.org/projects/playground/mobile/wiki-reader/repository/revisions/master/entry/frontends/blackberry/cmake/Toolchain-C6X.cmake#L64 Perhaps, CMAKE_FIND_ROOT_PATH can also help, but the point is that cmake cannot guess for you where you installed the environment. We used to have a script (batch on Windows, and shell on Unix) for the Blackberry NDK that the developers would run, but I am not aware of such a script from TI. I am just setting that variable in my build script on top of cmake. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
On Thu, Mar 14, 2013 at 8:59 AM, Florian Reinhard florian.reinh...@googlemail.com wrote: If ARM and DSP toolchain are commandline compatible, there could be an option to specify the architecture, like C6000 (DSP core in OMAP processors), C2000, C6400 which map to the correct compiler/linker/archiver/strip names. 1) Of course, TI for sure shares the language parser among the toolchains, so do they with the interface. It would not make too much sense otherwise. I bet it is only a historical issue why they do not use their binaries with the same names. Note that, they already migrated from cl470.exe to armcl.exe to be more generic across ARM cores. One step ahead could be that they even merge that with the DSP toolchain binaries in the future with a relevant target option, or perhaps not. It is not a biggie after all. 2) I am not sure an option is a good idea. In fact, you need to specify the compiler executable (path) in your toolchain file, and once you specify that, the other executables match the naming schema quite well to be logical what their name would be. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: the TI_DSP_to_TI branch on cmake stage now tries to automatically detect the compiler prefix and suffix and searches ar and strip accordingly. It seems to work for me (but I can't run the binaries). Please verify that it works, so I can still get it into 2.8.11 hopefully. Great. If compiles, ship it! :) Beyond the joke. It will be a lot simpler for me to test this with a release candidate than now. I think this should be going into 2.8.11, anyway. It would be a definite improvement than what we currently have. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
On Thu, Mar 14, 2013 at 8:57 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 14 March 2013, Robert Maynard wrote: I am sorry I was incorrect. The changes made to close bug 12405 are going to be in RC1. These new changes aren't going to make RC1 but should be in RC2 if we need one. I merged TI_DSP_to_TI_2 into next. It would be great if this could still make it into 2.8.11, since it changes the name of a still unreleased toolchain. Once this has been released, the name will have to be kept for compatibility reasons. I personally agree even if I do not know where it would be visible for the end user (i.e. my using a toolchain file). IMO, TI_DSP* is wrong because it whispers that it is a separate DSP toolchain, and it is not. That is why I suggested TI_*. Hence, I would either release it with the proper term, or postpone to 2.8.12. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
On Wed, Mar 13, 2013 at 10:14 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi, it would be great if you could give the branch TI_DSP_to_TI on cmake stage ( http://cmake.org/gitweb?p=stage/cmake.git ) a try. It renames TI_DSP to TI, and searches for ar6x and strip6x. The binaries are called different for the ARM toolchain. As for less than v5, it is called cl470.exe, strip470.exe and so forth. As for greater than v4, it is called armcl.exe, armar.exe, armstrip.exe and so forth. Also, I will only be able try with the release candidate. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] Modules/Compiler: TI DSP/ARM
Hi, I would like to note that the TI-DSP-ASM/C/CXX.cmake files would look like exactly the same for TI-ARM-ASM/C/CXX.cmake. The interface is the same for both toolchains. I presume you can just remove the DSP in there from the file name (or in worse case, add an arm overload)? http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules/Compiler;h=34a0ad1a5694082dc8ffc62c2ebeaa446ea09274;hb=master Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modules/Compiler: TI DSP/ARM
On Tue, Mar 12, 2013 at 7:43 PM, Alexander Neundorf neund...@kde.orgwrote: oh, this is working for you too ? Cool :-) I have not tried yet, but I know both toolchains now. They use the same interface. They only have different backend implementations as far as I can tell. Do you know for which other processors TI has a similar toolchain ? Simply naming it TI is quite general, so I'd like to be sure. As far as I know there are also the PRU assembler and loader, but that can be called toolchain only in a limited sense. For instance, TI does not plan [1] to provide a C compiler for that due to the overhead. If you see that crash Florian mentions, please let me know, so we can fix it. I will try once the release candidate is out. Laszlo [1] http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/39385.aspx -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
Anyone knowing something about this? Issue still not solved. :-) Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
Shall I force the compiler? This is all I can find on the CMake Cross Compiling wiki: If your compiler is not able to build a simple program by default without special flags or files (e.g. linker scripts or memory layout files), the toolchain file as shown above doesn't work. Then you have to *force* the compiler: It would be nice to have a bit more thorough documentation. This is not yet clear to me if it applies against my scenario or I can avoid forcing. Anyone knowing something about this? On Sun, Feb 24, 2013 at 10:28 PM, Laszlo Papp lp...@kde.org wrote: Here you can find the toolchain file I created: https://projects.kde.org/projects/playground/mobile/wiki-reader/repository/revisions/master/entry/frontends/blackberry/cmake/Toolchain-C6X.cmake I think the issue boils down to this: root /home/lpapp/Projects/qt/skeleton/build # /opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi --run_linker ../main.c Linking ../main.c, line 1: error: cannot find file int ../main.c, line 1: error: cannot find file main ../main.c, line 1: error: expecting filename, option, MEMORY, or SECTIONS instead of ( ../main.c, line 4: error: expecting filename, option, MEMORY, or SECTIONS instead of } fatal error: no input files Compilation failure root /home/lpapp/Projects/qt/skeleton/build # /opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi ../main.c --run_linker Linking warning: automatic library build: using library /opt/ti/C6000CGT7.4.2/lib/rts6200_elf.lib for the first time, so it must be built. This may take a few minutes. Do you have any ideas how to solve this issue? It seems to me that, I would need to pass the source files before the linker option. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
Here you can find the toolchain file I created: https://projects.kde.org/projects/playground/mobile/wiki-reader/repository/revisions/master/entry/frontends/blackberry/cmake/Toolchain-C6X.cmake I think the issue boils down to this: root /home/lpapp/Projects/qt/skeleton/build # /opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi --run_linker ../main.c Linking ../main.c, line 1: error: cannot find file int ../main.c, line 1: error: cannot find file main ../main.c, line 1: error: expecting filename, option, MEMORY, or SECTIONS instead of ( ../main.c, line 4: error: expecting filename, option, MEMORY, or SECTIONS instead of } fatal error: no input files Compilation failure root /home/lpapp/Projects/qt/skeleton/build # /opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi ../main.c --run_linker Linking warning: automatic library build: using library /opt/ti/C6000CGT7.4.2/lib/rts6200_elf.lib for the first time, so it must be built. This may take a few minutes. Do you have any ideas how to solve this issue? It seems to me that, I would need to pass the source files before the linker option. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
Oh, I might need to use the --run_linker (or --compile_only tentatively at
least) argument for the compiler. I will try that with
CMAKE_C(XX)_COMPILER_ARG1. Apologize for the noise.
On Fri, Feb 22, 2013 at 8:35 PM, Laszlo Papp lp...@kde.org wrote:
Hi,
I am now trying to put a toolchain file together for the aforementioned
embedded environment on my Windows 7 workstation. You can see the file
contents I have, and the errors I get below. When I just use the compiler
against the one liner main.c, it works off hand. I also tried to force the
C/C++ compilers, but even though the cmake ran fine, jom failed pretty much
with the same error.
Any help is much appreciated!
Laszlo
-
*
main.c*
int main() {return 0;}
*CMakeLists.txt*
add_executable(skeleton main.c)
*ToolchainFile-C6000*
# include(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Sysbios)
set(CMAKE_SYSTEM_VERSION 1.0)
set(CMAKE_SYSTEM_PROCESSOR C6000)
set(CMAKE_FIND_ROOT_PATH${CMAKE_FIND_ROOT_PATH}
C:/ti/C6000 Code Generation Tools 7.3.0B3/bin
C:/ti/C6000 Code Generation Tools 7.3.0B3/include
C:/ti/C6000 Code Generation Tools 7.3.0B3/lib)
# CMAKE_FORCE_C_COMPILER(C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe TI)
# CMAKE_FORCE_CXX_COMPILER(C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe TI)
SET(CMAKE_C_COMPILER C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe)
SET(CMAKE_CXX_COMPILER C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAMBOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDEBOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARYONLY)
*ERROR
*
cmake -G NMake Makefiles JOM -DCMAKE_TOOLCHAIN_FILE=../toolchain-cl6x.cmake
..
-- The C compiler identification is TI_DSP 7.3.0
-- The CXX compiler identification is TI_DSP 7.3.0
-- Check for working C compiler: C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/c
l6x.exe
-- Check for working C compiler: C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/c
l6x.exe -- broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCCompiler.cmake:61 (message):
The C compiler C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/cl6x.exe is
not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Projects/share/skeleton/build/CMakeFiles/CMakeTmp
Run Build Command:jom cmTryCompileExec2474985119\fast
jom 1.0.13 - empower your cores
C:\Program Files (x86)\jom\jom.exe -f
CMakeFiles\cmTryCompileExec2474985119.dir\build.make /nologo -
CMakeFiles\cmTryCompileExec2474985119.dir\build
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E
cmake_progress_repor
t
C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles 1
Building C object
CMakeFiles/cmTryCompileExec2474985119.dir/testCCompiler.c.obj
C:\ti\C6000C~1.0B3\bin\cl6x.exe -o
CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj -c
C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\testCCompiler.c
[testCCompiler.c]
WARNING: object file specified, but linking not enabled
Linking C executable cmTryCompileExec2474985119
C:\ti\C6000C~1.0B3\bin\cl6x.exe
CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj -o
cmTryCompileExec2474985119
[cmTryCompileExec2474985119.]
WARNING: object file specified, but linking not enabled
Fatal error: could not open source file cmTryCompileExec2474985119
1 fatal error detected in the compilation of cmTryCompileExec2474985119.
Compilation terminated.
jom:
C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles\cmTryCompileEx
ec2474985119.dir\build.make
[cmTryCompileExec2474985119] Error 1
Compilation failure
jom: C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\Makefile
[cmTryCompileExec2474985119\fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
-- Configuring incomplete, errors occurred!
C:\Projects\share\skeleton\build
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools
Hi,
I am now trying to put a toolchain file together for the aforementioned
embedded environment on my Windows 7 workstation. You can see the file
contents I have, and the errors I get below. When I just use the compiler
against the one liner main.c, it works off hand. I also tried to force the
C/C++ compilers, but even though the cmake ran fine, jom failed pretty much
with the same error.
Any help is much appreciated!
Laszlo
-
*
main.c*
int main() {return 0;}
*CMakeLists.txt*
add_executable(skeleton main.c)
*ToolchainFile-C6000*
# include(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Sysbios)
set(CMAKE_SYSTEM_VERSION 1.0)
set(CMAKE_SYSTEM_PROCESSOR C6000)
set(CMAKE_FIND_ROOT_PATH${CMAKE_FIND_ROOT_PATH}
C:/ti/C6000 Code Generation Tools 7.3.0B3/bin
C:/ti/C6000 Code Generation Tools 7.3.0B3/include
C:/ti/C6000 Code Generation Tools 7.3.0B3/lib)
# CMAKE_FORCE_C_COMPILER(C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe TI)
# CMAKE_FORCE_CXX_COMPILER(C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe TI)
SET(CMAKE_C_COMPILER C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe)
SET(CMAKE_CXX_COMPILER C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAMBOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDEBOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARYONLY)
*ERROR
*
cmake -G NMake Makefiles JOM -DCMAKE_TOOLCHAIN_FILE=../toolchain-cl6x.cmake ..
-- The C compiler identification is TI_DSP 7.3.0
-- The CXX compiler identification is TI_DSP 7.3.0
-- Check for working C compiler: C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/c
l6x.exe
-- Check for working C compiler: C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/c
l6x.exe -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTes
tCCompiler.cmake:61 (message):
The C compiler C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/cl6x.exe is
not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Projects/share/skeleton/build/CMakeFiles/CMakeTmp
Run Build Command:jom cmTryCompileExec2474985119\fast
jom 1.0.13 - empower your cores
C:\Program Files (x86)\jom\jom.exe -f
CMakeFiles\cmTryCompileExec2474985119.dir\build.make /nologo -
CMakeFiles\cmTryCompileExec2474985119.dir\build
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_progress_repor
t
C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles 1
Building C object
CMakeFiles/cmTryCompileExec2474985119.dir/testCCompiler.c.obj
C:\ti\C6000C~1.0B3\bin\cl6x.exe -o
CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj -c
C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\testCCompiler.c
[testCCompiler.c]
WARNING: object file specified, but linking not enabled
Linking C executable cmTryCompileExec2474985119
C:\ti\C6000C~1.0B3\bin\cl6x.exe
CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj -o
cmTryCompileExec2474985119
[cmTryCompileExec2474985119.]
WARNING: object file specified, but linking not enabled
Fatal error: could not open source file cmTryCompileExec2474985119
1 fatal error detected in the compilation of cmTryCompileExec2474985119.
Compilation terminated.
jom:
C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles\cmTryCompileEx
ec2474985119.dir\build.make
[cmTryCompileExec2474985119] Error 1
Compilation failure
jom: C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\Makefile
[cmTryCompileExec2474985119\fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
-- Configuring incomplete, errors occurred!
C:\Projects\share\skeleton\build
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Qt5 with cmake
What is wrong about Stephen's post? It has been working for me in several projects. On Fri, Jan 18, 2013 at 3:19 PM, Bogdan Cristea crist...@gmail.com wrote: Hi Qt5 provides configuration files for cmake, but I haven't yet found a way to detect Qt5 as recommended in this post (I am using qt5 on Windows with Visual Studio 2010): http://www.kdab.com/using-cmake-with-qt-5/ As far as I understand cmake does not yet provide support for qt5 (at least not in 2.8.10.2). How can I add support for qt 5 in cmake ? Are there some examples of CMakeFiles for using Qt5 ? thanks Bogdan -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using Qt5 with cmake
There is also this: http://qt-project.org/doc/qt-5.0/qtdoc/cmake-manual.html Either way, check if your Qt installation ships the cmake files. Qt5 has builtin support for third-party projects from cmake point of view. On Fri, Jan 18, 2013 at 3:29 PM, Bogdan Cristea crist...@gmail.com wrote: Le vendredi 18 janvier 2013 à 15:22 +, Laszlo Papp a écrit : What is wrong about Stephen's post? It has been working for me in several projects. A line like this find_package(Qt5Declarative) generates a warning about missing FindQt5Declarative.cmake which is not provided by Qt5 nor cmake. Maybe I am missing something, but I am not able to use Qt5 with cmake following that post. Bogdan -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Implicit toolchain file usage
On Thu, Jan 17, 2013 at 8:43 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 17 January 2013, Laszlo Papp wrote: On Thu, Jan 17, 2013 at 8:31 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: do you mean using -DCMAKE_SYSTEM_NAME=qnx should trigger something ? Don't know, my experience is that cross compiling environments usually vary a lot in their setup. *Current* cmake -DCMAKE_TOOLCHAIN_FILE=../frontends/blackberry/cmake/Toolchain-QNX-8.0.0.c make -DBUILD_WIKIREADER_BLACKBERRY=ON .. == *Proposed* cmake -DBUILD_WIKIREADER_BLACKBERRY=ON .. and ../CMakeListst.txt: set_toolchain_file(../frontends/blackberry/cmake/Toolchain-QNX-8.0.0.cmake ) This is pseudo code, but you get my point, don't you? It would be shorter for the developer, packager or user to use cmake. Can you attach your toolchain file here so we can have a look ? http://quickgit.kde.org/?p=scratch%2Flpapp%2Fwikireader.gita=blobh=2e3e19 7590bfdce77ae282be840d7b167afafb94hb=7bf46fccfa4c087500a12116588e071b1183b 4e7f=frontends%2Fblackberry%2Fcmake%2FToolchain-QNX-8.0.0.cmake oh, this is definitely more than what should be necessary. Why do you have to set all the suffixes and prefixes ? I will clean it up later once the project works for an initial release. This should go into Platforms/QNX.cmake. Manually setting CMAKE_AR etc. should also not be necessary, this should also go into QNX.cmake or QNX-qcc.cmake or somewhere like this. Feel free to get anything upstreamed from my file. The specific build flags are your choice. I see. It means I can avoid the -DCMAKE_TOOLCHAIN_FILE in the end of the day. Thank you for your reply. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Segfault for the Blackberry 10 build (devalpha device)
On Thu, Jan 17, 2013 at 3:19 AM, Bill Hoffman bill.hoff...@kitware.comwrote: On 1/16/2013 6:57 PM, Laszlo Papp wrote: This is my latest toolchain file version: http://quickgit.kde.org/?p=**scratch%2Flpapp%2Fwikireader.**gita=blobh= **5c6c4dbda324a8285f99115c3de7d4**5e441d47cahb=** f296afed1993d7c28edd5f9adcfd41**465667d823f=frontends%** 2Fblackberry%2Fcmake%**2FToolchain-QNX-8.0.0.cmakehttp://quickgit.kde.org/?p=scratch%2Flpapp%2Fwikireader.gita=blobh=5c6c4dbda324a8285f99115c3de7d45e441d47cahb=f296afed1993d7c28edd5f9adcfd41465667d823f=frontends%2Fblackberry%2Fcmake%2FToolchain-QNX-8.0.0.cmake At least, it is clear now what I should achieve, but the CMAKE_C(XX)_FLAGS* do not seem to work as I would expect them to. Try this: SET(CMAKE_CXX_COMPILER_ARG1 -Vgcc_ntoarmv7le) Thank you; that helped! :) I will try to write a blog post soon how to deal with all these for Blackberry. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Implicit toolchain file usage
Hi, I have been pondering for a while if it was possible (theoritically, and then practically) to get the toolchain fine defined inside one (main?) of the cmake files? I have been using the -DCMAKE_TOOLCHAIN_FILE=my-toolchain-file.cmake option, but I think this can become duplicated easily. That is because most of the time the developers, packagers, or users may have to define the platform to build for on the command line anyway. Hence, the toolchain file detection and usage could be implicit. I have also imported my toolchain file into the project because it is a very short file, and really not a big burden. I understand that the toolchain files are specified by this file, so this should be put into an early stage of the build procedure for sure. Otherwise, everyone has to deal with it separately, which is undesirable, I believe. Sometimes, it may make sense to customize this on your own, but there could be a fallback provided by the project developers implicitly inside the build system of the given project. I think, this would be a great thing to have. Is it already available now like just simple define (implicit equivalence of the -D) or so? Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Implicit toolchain file usage
On Thu, Jan 17, 2013 at 8:31 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: do you mean using -DCMAKE_SYSTEM_NAME=qnx should trigger something ? Don't know, my experience is that cross compiling environments usually vary a lot in their setup. *Current* cmake -DCMAKE_TOOLCHAIN_FILE=../frontends/blackberry/cmake/Toolchain-QNX-8.0.0.cmake -DBUILD_WIKIREADER_BLACKBERRY=ON .. == *Proposed* cmake -DBUILD_WIKIREADER_BLACKBERRY=ON .. and ../CMakeListst.txt: set_toolchain_file(../frontends/blackberry/cmake/Toolchain-QNX-8.0.0.cmake) This is pseudo code, but you get my point, don't you? It would be shorter for the developer, packager or user to use cmake. Can you attach your toolchain file here so we can have a look ? http://quickgit.kde.org/?p=scratch%2Flpapp%2Fwikireader.gita=blobh=2e3e197590bfdce77ae282be840d7b167afafb94hb=7bf46fccfa4c087500a12116588e071b1183b4e7f=frontends%2Fblackberry%2Fcmake%2FToolchain-QNX-8.0.0.cmake Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Segfault for the Blackberry 10 build (devalpha device)
Hi all,
As I have a few days left for the submission of the limited edition device
program, I thought I would be asking for help to see if it is something
simple to fix with joint effort as I like cmake. :-)
Otherwise I may need to switch away from cmake, and it will also be a
showstopper to start porting KDE to QNX. So, I have the following structure
for my buildsystem:
http://quickgit.kde.org/?p=scratch%2Flpapp%2Fwikireader.gita=blobh=6698cbdac3768199b0198c7388e22e145127b102hb=1823d473b97c3259c475c92594ed2b452261fa80f=frontends%2Fblackberry%2FCMakeLists.txt
The problem is that, the build finishes without any errors, but when I run
the generated binary on the phone, it gets a segfault which does not happen
when using qmake from the IDE.
Here you can find the build with qmake: http://paste.kde.org/~lpapp/648440/
Here you can find the build with cmake: http://paste.kde.org/~lpapp/648434/
This is the segfault with the binary built by cmake:
Process 14692534 (wikireader) terminated SIGSEGV code=1 fltno=11
ip=7843bf7c(/base/lib/libcpp.so.4@_ZNKSt6locale9_GetfacetEj+0x27)
mapaddr=0002bf7c. ref=0010
Here you can find the pro files generated by the IDE for qmake:
WikiReader.pro:
APP_NAME = WikiReader
CONFIG += qt warn_on cascades10
INCLUDEPATH += ../src ${QNX_TARGET}/usr/include/qt4/QtNetwork
DEPENDPATH += ../src ${QNX_TARGET}/usr/include/qt4/QtNetwork
QT += network
INCLUDEPATH += ../src ${QNX_TARGET}/usr/include/qt4/QtXml
DEPENDPATH += ../src ${QNX_TARGET}/usr/include/qt4/QtXml
QT += xml
include(config.pri)
config.pri:
cat WikiReader/config.pri
# Auto-generated by IDE. All changes by user will be lost!
# Created at 16/01/13 2:53 AM
BASEDIR = $$_PRO_FILE_PWD_
INCLUDEPATH += \
$$BASEDIR/src
SOURCES += \
$$BASEDIR/src/main.cpp \
$$BASEDIR/src/wikimodel.cpp
HEADERS += \
$$BASEDIR/src/wikimodel.h
CONFIG += precompile_header
PRECOMPILED_HEADER = $$BASEDIR/precompiled.h
lupdate_inclusion {
SOURCES += \
$$BASEDIR/../assets/*.qml
}
TRANSLATIONS = \
$${TARGET}.ts
Laszlo
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Segfault for the Blackberry 10 build (devalpha device)
On Wed, Jan 16, 2013 at 9:54 AM, Laszlo Papp lp...@kde.org wrote: Here you can find the build with qmake: http://paste.kde.org/~lpapp/648440/ Sorry, I sent a wrong link for that. This is the correct: http://pastebin.com/h4HjDFzU Here you can also find my cmake toolchain file: http://quickgit.kde.org/?p=scratch%2Flpapp%2Fwikireader.gita=blobh=8a44fdf1eb39f91d48aabd2fd43b5884ffe13c5chb=1823d473b97c3259c475c92594ed2b452261fa80f=frontends%2Fblackberry%2Fcmake%2FToolchain-QNX-8.0.0.cmake This is the FindBBCascades.cmake find module I wrote: http://quickgit.kde.org/?p=scratch%2Flpapp%2Fwikireader.gita=blobh=0ba28a68c8bf73c29703bb85878ef4f53d954a68hb=1823d473b97c3259c475c92594ed2b452261fa80f=frontends%2Fblackberry%2Fcmake%2FFindBBCascades.cmake Any help appreciated! Thank you in advance. :-) Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Segfault for the Blackberry 10 build (devalpha device)
Interesting finding! It happened to PySide as well on this platform which may help with proceeding: http://www.engcorp.com/pipermail/blackberry-python/2013/16.html On Wed, Jan 16, 2013 at 10:31 AM, Laszlo Papp lp...@kde.org wrote: I have just tried to add the following libraries to the linkage even if they seem unnecessary: -lz -lsocket -lm -lbps, but it is still crashing. :'( I have also tried to save out the wikireader.core file of mine, and run through an arm gdb on the host, but it did not provide too much information sadly even with a debug build: (gdb) core wikireader.core [New LWP 1] Program terminated with signal 11, Segmentation fault. #0 0x01d27380 in ?? () (gdb) thread apply all bt Thread 1 (LWP 1): #0 0x01d27380 in ?? () #1 0x in ?? () (gdb) How can we proceed? Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Segfault for the Blackberry 10 build (devalpha device)
At least I cannot reproduce the crash with the following skeleton:
cat ../../cmake-test/main.cpp
int main() {return 0;}
cat ../../cmake-test/CMakeLists.txt
add_executable(cmake-test main.cpp)
I am running out of the quick ideas soon. Anything else to try?
On Wed, Jan 16, 2013 at 2:12 PM, Laszlo Papp lp...@kde.org wrote:
Interesting finding! It happened to PySide as well on this platform which
may help with proceeding:
http://www.engcorp.com/pipermail/blackberry-python/2013/16.html
On Wed, Jan 16, 2013 at 10:31 AM, Laszlo Papp lp...@kde.org wrote:
I have just tried to add the following libraries to the linkage even if
they seem unnecessary: -lz -lsocket -lm -lbps, but it is still crashing. :'(
I have also tried to save out the wikireader.core file of mine, and run
through an arm gdb on the host, but it did not provide too much information
sadly even with a debug build:
(gdb) core wikireader.core
[New LWP 1]
Program terminated with signal 11, Segmentation fault.
#0 0x01d27380 in ?? ()
(gdb) thread apply all bt
Thread 1 (LWP 1):
#0 0x01d27380 in ?? ()
#1 0x in ?? ()
(gdb)
How can we proceed?
Laszlo
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Segfault for the Blackberry 10 build (devalpha device)
Hi Bill!
This works: echo int main() { return 0; } main.cpp qcc
-Vgcc_ntoarmv7le main.cpp -l QtCore -L
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/ -o cmake-test
This does not work: echo int main() { return 0; } main.cpp
ntoarmv7-g++ main.cpp -lQtCore
-L/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/ -o cmake-test
This is the qcc documentation which is just a wrapper around the
preprocessor, compiler, linker, and assembler:
http://developer.blackberry.com/native/reference/bb10/com.qnx.doc.neutrino.utilities/topic/q/qcc.html
Now I am getting this:
cd /home/lpapp/Projects/qt/wikireader/build/frontends/blackberry
/usr/bin/cmake -E cmake_link_script CMakeFiles/wikireader.dir/link.txt
--verbose=1
/opt/bbndk/host_10_0_9_404/linux/x86/usr/bin/qcc -Wall -fPIC
CMakeFiles/wikireader.dir/main.cpp.o
CMakeFiles/wikireader.dir/wikimodel.cpp.o
CMakeFiles/wikireader.dir/qrc_wikireader.cxx.o
CMakeFiles/wikireader.dir/wikireader_automoc.cpp.o -o wikireader
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtCore.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtNetwork.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtXml.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtGui.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtDeclarative.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libbbcascades.so
-Wl,-rpath,/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib:/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtCore.so:
could not read symbols: File in wrong format
cc: /opt/bbndk/host_10_0_9_404/linux/x86/usr/bin/ntox86-ld error 1
make[2]: *** [frontends/blackberry/wikireader] Error 1
make[2]: Leaving directory `/home/lpapp/Projects/qt/wikireader/build'
make[1]: *** [frontends/blackberry/CMakeFiles/wikireader.dir/all] Error 2
make[1]: Leaving directory `/home/lpapp/Projects/qt/wikireader/build'
make: *** [all] Error 2
For some reason, -Vgcc_ntoarmv7le does not take any effect in the
toolchain file. Do you have an idea why that could happen? Should I use
CMAKE_EXE_LINKER_FLAGS or something else? -Wl would be the linker for
qcc, and ntox86-ld is the wrong one, not the arm variant.
Laszlo
On Wed, Jan 16, 2013 at 9:40 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
On 1/16/2013 4:05 PM, Laszlo Papp wrote:
At least I cannot reproduce the crash with the following skeleton:
You should look at the compile/link lines. First I would look at the
link lines:
This is the qmake one:
qcc -Vgcc_ntoarmv7le -lang-c++ -Wl,-rpath-link,/home/taylor/**
Development/bbndk/target_10_0_**9_2318/qnx6/armle-v7/lib
-Wl,-rpath-link,/home/taylor/**Development/bbndk/target_10_0_**9_2318/qnx6/armle-v7/usr/lib
-Wl,-rpath-link,/home/taylor/**Development/bbndk/target_10_0_**
9_2318/qnx6/armle-v7/usr/lib/**qt4/lib -o o.le-v7-g/WikiReader
o.le-v7-g/.obj/main.o o.le-v7-g/.obj/wikimodel.o
o.le-v7-g/.obj/moc_wikimodel.o -L/home/taylor/Development/**
bbndk/target_10_0_9_2318/qnx6/**armle-v7/lib -L/home/taylor/Development/**
bbndk/target_10_0_9_2318/qnx6/**armle-v7/usr/lib
-L/home/taylor/Development/**bbndk/target_10_0_9_2318/qnx6/**armle-v7/usr/lib/qt4/lib
-L/home/taylor/Development/**bbndk/target_10_0_9_2318/qnx6/**/usr/lib/qt4/lib
-lbbcascades -lQtDeclarative -lQtScript -lQtSvg -lQtSql -lsqlite3 -lz
-lQtXmlPatterns -lQtGui -lQtXml -lQtNetwork -lsocket -lQtCore -lm -lbps
This is the cmake one:
/opt/bbndk/host_10_0_9_404/**linux/x86/usr/bin/ntoarmv7-c++ -Wall -fPIC
-Wall -fPIC -g3 -ggdb -O0CMakeFiles/wikireader.dir/**main.cpp.o
CMakeFiles/wikireader.dir/**wikimodel.cpp.o CMakeFiles/wikireader.dir/qrc_
**wikireader.cxx.o CMakeFiles/wikireader.dir/**wikireader_automoc.cpp.o
-o wikireader /opt/bbndk/target_10_0_9_1673/**
qnx6/armle-v7/usr/lib/qt4/lib/**libQtCore.so
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtNetwork.so
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtXml.so
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtGui.so
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtDeclarative.so
-lbbcascades -Wl,-rpath,/opt/bbndk/target_**10_0_9_1673/qnx6/armle-v7/usr/
**lib/qt4/lib
Right off the bat they are using different compilers to link. I would
try to get the CMake one to match the qmake one by hand and see if you can
fix the problem. Once you figure out the magic command line that makes it
work, then we can figure out how to get CMake to produce the same command
line.
BTW, same thing with the compile lines. CMake does c++ and qmake does gcc
-lang-c++.
cat ../../cmake-test/main.cpp
int main() {return 0;}
cat ../../cmake-test/CMakeLists.**txt
add_executable(cmake-test main.cpp)
I am running out of the quick ideas soon. Anything else to try?
On Wed, Jan 16, 2013 at 2:12 PM, Laszlo Papp lp...@kde.org
Re: [CMake] Segfault for the Blackberry 10 build (devalpha device)
This is my latest toolchain file version:
http://quickgit.kde.org/?p=scratch%2Flpapp%2Fwikireader.gita=blobh=5c6c4dbda324a8285f99115c3de7d45e441d47cahb=f296afed1993d7c28edd5f9adcfd41465667d823f=frontends%2Fblackberry%2Fcmake%2FToolchain-QNX-8.0.0.cmake
At least, it is clear now what I should achieve, but the CMAKE_C(XX)_FLAGS*
do not seem to work as I would expect them to.
On Wed, Jan 16, 2013 at 11:20 PM, Laszlo Papp lp...@kde.org wrote:
Hi Bill!
This works: echo int main() { return 0; } main.cpp qcc
-Vgcc_ntoarmv7le main.cpp -l QtCore -L
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/ -o cmake-test
This does not work: echo int main() { return 0; } main.cpp
ntoarmv7-g++ main.cpp -lQtCore
-L/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/ -o cmake-test
This is the qcc documentation which is just a wrapper around the
preprocessor, compiler, linker, and assembler:
http://developer.blackberry.com/native/reference/bb10/com.qnx.doc.neutrino.utilities/topic/q/qcc.html
Now I am getting this:
cd /home/lpapp/Projects/qt/wikireader/build/frontends/blackberry
/usr/bin/cmake -E cmake_link_script CMakeFiles/wikireader.dir/link.txt
--verbose=1
/opt/bbndk/host_10_0_9_404/linux/x86/usr/bin/qcc -Wall -fPIC
CMakeFiles/wikireader.dir/main.cpp.o
CMakeFiles/wikireader.dir/wikimodel.cpp.o
CMakeFiles/wikireader.dir/qrc_wikireader.cxx.o
CMakeFiles/wikireader.dir/wikireader_automoc.cpp.o -o wikireader
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtCore.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtNetwork.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtXml.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtGui.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtDeclarative.so
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libbbcascades.so
-Wl,-rpath,/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib:/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib
/opt/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/qt4/lib/libQtCore.so:
could not read symbols: File in wrong format
cc: /opt/bbndk/host_10_0_9_404/linux/x86/usr/bin/ntox86-ld error 1
make[2]: *** [frontends/blackberry/wikireader] Error 1
make[2]: Leaving directory `/home/lpapp/Projects/qt/wikireader/build'
make[1]: *** [frontends/blackberry/CMakeFiles/wikireader.dir/all] Error 2
make[1]: Leaving directory `/home/lpapp/Projects/qt/wikireader/build'
make: *** [all] Error 2
For some reason, -Vgcc_ntoarmv7le does not take any effect in the
toolchain file. Do you have an idea why that could happen? Should I use
CMAKE_EXE_LINKER_FLAGS or something else? -Wl would be the linker for
qcc, and ntox86-ld is the wrong one, not the arm variant.
Laszlo
On Wed, Jan 16, 2013 at 9:40 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
On 1/16/2013 4:05 PM, Laszlo Papp wrote:
At least I cannot reproduce the crash with the following skeleton:
You should look at the compile/link lines. First I would look at the
link lines:
This is the qmake one:
qcc -Vgcc_ntoarmv7le -lang-c++ -Wl,-rpath-link,/home/taylor/**
Development/bbndk/target_10_0_**9_2318/qnx6/armle-v7/lib
-Wl,-rpath-link,/home/taylor/**Development/bbndk/target_10_0_**9_2318/qnx6/armle-v7/usr/lib
-Wl,-rpath-link,/home/taylor/**Development/bbndk/target_10_0_**
9_2318/qnx6/armle-v7/usr/lib/**qt4/lib -o o.le-v7-g/WikiReader
o.le-v7-g/.obj/main.o o.le-v7-g/.obj/wikimodel.o
o.le-v7-g/.obj/moc_wikimodel.o -L/home/taylor/Development/**
bbndk/target_10_0_9_2318/qnx6/**armle-v7/lib -L/home/taylor/Development/*
*bbndk/target_10_0_9_2318/qnx6/**armle-v7/usr/lib
-L/home/taylor/Development/**bbndk/target_10_0_9_2318/qnx6/**armle-v7/usr/lib/qt4/lib
-L/home/taylor/Development/**bbndk/target_10_0_9_2318/qnx6/**/usr/lib/qt4/lib
-lbbcascades -lQtDeclarative -lQtScript -lQtSvg -lQtSql -lsqlite3 -lz
-lQtXmlPatterns -lQtGui -lQtXml -lQtNetwork -lsocket -lQtCore -lm -lbps
This is the cmake one:
/opt/bbndk/host_10_0_9_404/**linux/x86/usr/bin/ntoarmv7-c++ -Wall
-fPIC -Wall -fPIC -g3 -ggdb -O0CMakeFiles/wikireader.dir/**main.cpp.o
CMakeFiles/wikireader.dir/**wikimodel.cpp.o
CMakeFiles/wikireader.dir/qrc_**wikireader.cxx.o
CMakeFiles/wikireader.dir/**wikireader_automoc.cpp.o -o wikireader
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtCore.so
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtNetwork.so
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtXml.so
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtGui.so
/opt/bbndk/target_10_0_9_1673/**qnx6/armle-v7/usr/lib/qt4/lib/**libQtDeclarative.so
-lbbcascades -Wl,-rpath,/opt/bbndk/target_**
10_0_9_1673/qnx6/armle-v7/usr/**lib/qt4/lib
Right off the bat they are using different compilers to link. I would
try to get the CMake one to match the qmake one by hand and see if you can
fix the problem. Once
[cmake-developers] FindOpenGLES.cmake upstreaming?
Hi, Does anyone feel like grabbing one of the module codes out there, and put into an upcoming cmake release? It is nowadays somewhat a standard to provide opengles support as well for the project if that otherwise supports OpenGL. They become to be going hand in hand lately more and more in my opinion. Thank you in advance. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Automoc4 issue when using cmake (2.8.9)
The issue still persists! I wonder if anybody had an idea? Laszlo On Mon, Oct 1, 2012 at 4:12 PM, Laszlo Papp lp...@kde.org wrote: Any ideas? Laszlo On Thu, Sep 27, 2012 at 9:22 PM, Laszlo Papp lp...@kde.org wrote: Seems those variables are empty: -- Looking for _POSIX_TIMERS - found CMAKE_PREFIX_PATH: CMAKE_MODULE_PATH: CMake Error at /usr/share/apps/cmake/modules/FindPackageHandleStandardArgs.cmake:198 (MESSAGE): Did not find automoc4 (Automoc4Config.cmake, install git://anongit.kde.org/automoc). (missing: AUTOMOC4_EXECUTABLE) Call Stack (most recent call first): /usr/share/apps/cmake/modules/FindAutomoc4.cmake:49 (find_package_handle_standard_args) /usr/share/apps/cmake/modules/FindKDE4Internal.cmake:426 (find_package) /usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (FIND_PACKAGE) CMakeLists.txt:31 (find_package) -- Configuring incomplete, errors occurred! Laszlo On Thu, Sep 27, 2012 at 7:05 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Wednesday 26 September 2012, Laszlo Papp wrote: do you know what changed couple dof days ago ? Did you use an older version of cmake before ? No, I have always used 2.8.9 pretty much since it was released because of the KDE Frameworks effort and other things. kdelibs may have been updated. Anything special to debug or print out? Hmm, maybe add some debug output ? In FindKDELibs4Internal.cmake there is a find_package() call for automoc. Print something there, e.g. CMAKE_PREFIX_PATH, CMAKE_MODULE_PATH and also the environment variable CMAKE_PREFIX_PATH. This should help. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] JOM Makefile generation issue
This is the python statement I am trying to execute on my Windows box just in case: subprocess.call([cmake, -GNMake Makefiles JOM, -DCMAKE_MODULE_PATH= + os.environ[CMAKE_MODULE_PATH].replace(\\, /), os.path.pardir if len(sys.argv) == 1 else sys.argv[1]]) Laszlo On Tue, Oct 30, 2012 at 4:31 PM, Laszlo Papp lp...@kde.org wrote: It seems I was the culsprit with writing my python script as I essentially used -G\foo bar\. Having dropped the inner quotes, it worked. However, I am now getting strange errors that I have not seen before. :) -- Detecting C compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Projects/share/foo/bar/hello/world/build_i386_win_vc_debug/CMakeFiles/CMakeDetermineCompilerABI_C.bin' Unable to find executable for try_compile: tried C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeTmp/cmTryCompileExec.exe and C:/Projects/share/foo/bar/hello/world/build /CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe and C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeTmp/Development/cm TryCompileExec.exe. -- Detecting C compiler ABI info - done CMake Error at C:/Projects/share/foo/bar/tools/cmake-2.8.2-win32-x86/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE): file STRINGS file C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeDetermineCompilerABI_C.bin cannot be read. Call Stack (most recent call first): C:/Projects/share/foo/bar/tools/cmake-2.8.2-win32-x86/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:71 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:2 (project) -- Check for working CXX compiler: C:/Projects/share/foo/bar/tools/bin/cl.exe -- Check for working CXX compiler: C:/Projects/share/foo/bar/tools/bin/cl.exe -- works -- Detecting CXX compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin' ... things like that. Any ideas? Thank you in advance! Laszlo On Tue, Oct 30, 2012 at 3:55 PM, David Cole david.c...@kitware.com wrote: On Tue, Oct 30, 2012 at 11:24 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/30/2012 10:54 AM, Laszlo Papp wrote: I am trying to replace a Windows batch script with a python variant, but I am getting some issues when calling cmake as a subprocess: CMake Error: Could not create named generator NMake Makefiles JOM What cmake are you using? What do you get when you run cmake --help? Is that generator listed? -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake Maybe there's more than one CMake in your PATH. If you run where cmake in a Windows cmd prompt with the same PATH setting, it will show you all of them. The first one it shows you is the one that will be run when you do a cmake without a full path... -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] JOM Makefile generation issue
I have also tried to enable the --debug-trycompile, but did not help for me. This is the CMakeError.log: Compilation of the C compiler identification source CMakeCCompilerId.c did not produce an executable in C:/foobar/build/CMakeFiles/CompilerIdC. Compilation of the C compiler identification source CMakeCCompilerId.c did not produce an executable in C:/foobar/build/CMakeFiles/CompilerIdC. Compilation of the C compiler identification source CMakeCCompilerId.c did not produce an executable in C:/foobar/build/CMakeFiles/CompilerIdC. Compilation of the CXX compiler identification source CMakeCXXCompilerId.cpp did not produce an executable in C:/foobar/build/CMakeFiles/CompilerIdCXX. Compilation of the CXX compiler identification source CMakeCXXCompilerId.cpp did not produce an executable in C:/foobar/build/CMakeFiles/CompilerIdCXX. I am trying to use the cl.exe from the Visual Studio 2008. Any help is still welcome. :-) Laszlo On Wed, Oct 31, 2012 at 7:56 AM, Laszlo Papp lp...@kde.org wrote: This is the python statement I am trying to execute on my Windows box just in case: subprocess.call([cmake, -GNMake Makefiles JOM, -DCMAKE_MODULE_PATH= + os.environ[CMAKE_MODULE_PATH].replace(\\, /), os.path.pardir if len(sys.argv) == 1 else sys.argv[1]]) Laszlo On Tue, Oct 30, 2012 at 4:31 PM, Laszlo Papp lp...@kde.org wrote: It seems I was the culsprit with writing my python script as I essentially used -G\foo bar\. Having dropped the inner quotes, it worked. However, I am now getting strange errors that I have not seen before. :) -- Detecting C compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Projects/share/foo/bar/hello/world/build_i386_win_vc_debug/CMakeFiles/CMakeDetermineCompilerABI_C.bin' Unable to find executable for try_compile: tried C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeTmp/cmTryCompileExec.exe and C:/Projects/share/foo/bar/hello/world/build /CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe and C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeTmp/Development/cm TryCompileExec.exe. -- Detecting C compiler ABI info - done CMake Error at C:/Projects/share/foo/bar/tools/cmake-2.8.2-win32-x86/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE): file STRINGS file C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeDetermineCompilerABI_C.bin cannot be read. Call Stack (most recent call first): C:/Projects/share/foo/bar/tools/cmake-2.8.2-win32-x86/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:71 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:2 (project) -- Check for working CXX compiler: C:/Projects/share/foo/bar/tools/bin/cl.exe -- Check for working CXX compiler: C:/Projects/share/foo/bar/tools/bin/cl.exe -- works -- Detecting CXX compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin' ... things like that. Any ideas? Thank you in advance! Laszlo On Tue, Oct 30, 2012 at 3:55 PM, David Cole david.c...@kitware.com wrote: On Tue, Oct 30, 2012 at 11:24 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/30/2012 10:54 AM, Laszlo Papp wrote: I am trying to replace a Windows batch script with a python variant, but I am getting some issues when calling cmake as a subprocess: CMake Error: Could not create named generator NMake Makefiles JOM What cmake are you using? What do you get when you run cmake --help? Is that generator listed? -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake Maybe there's more than one CMake in your PATH. If you run where cmake in a Windows cmd prompt with the same PATH setting, it will show you all of them. The first one it shows you is the one that will be run when you do a cmake without a full path... -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] JOM Makefile generation issue
Does CMake work from the command line without python on a simple project? No. Does it work with nmake or any other generators? No. Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] JOM Makefile generation issue
I think it is my stupidity again as usual. :D $myrepository/tools/bin/cl.exe caused it because that was found due to a wrong PATH handling. I have inserted that before the rest instead of appending. The local cl.exe was preferred from the repository and cmake seems to have been unhappy about that (not sure why) in the the visual studio prompt. Thank you for your help and patience. Also, sorry for the bothering! Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] JOM Makefile generation issue
Hi, I am trying to replace a Windows batch script with a python variant, but I am getting some issues when calling cmake as a subprocess: CMake Error: Could not create named generator NMake Makefiles JOM I have tried to use the --debug-output and --trace options as well, but it did not get me any closer to the root cause. The command is basically what I am using from a given directory is cmake -GNMake Makefiles JOM -DCMAKE_MODULE_PATH=/path/to/the/CMakeModules .. I am just really clueless as I am not getting too much help from the verbose cmake output either. Do you have any suggestion how to proceed with this issue? I have tried to dig myself into the documentation as well, but this is all I found: NMake Makefiles JOM Like NMake Makefiles, but generates Makefiles for jom instead of nmake. jom is like nmake, but supports the -j flag. jom.zip should point to the newest release. Get jom through ftp - 0.9.4 has been confirmed to work. Make sure the containing folder is in the PATH. Jom's containing folder is indeed in the past. Help really welcome. Getting frustrated. :) Laszlo -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] JOM Makefile generation issue
It seems I was the culsprit with writing my python script as I essentially used -G\foo bar\. Having dropped the inner quotes, it worked. However, I am now getting strange errors that I have not seen before. :) -- Detecting C compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Projects/share/foo/bar/hello/world/build_i386_win_vc_debug/CMakeFiles/CMakeDetermineCompilerABI_C.bin' Unable to find executable for try_compile: tried C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeTmp/cmTryCompileExec.exe and C:/Projects/share/foo/bar/hello/world/build /CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe and C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeTmp/Development/cm TryCompileExec.exe. -- Detecting C compiler ABI info - done CMake Error at C:/Projects/share/foo/bar/tools/cmake-2.8.2-win32-x86/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE): file STRINGS file C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeDetermineCompilerABI_C.bin cannot be read. Call Stack (most recent call first): C:/Projects/share/foo/bar/tools/cmake-2.8.2-win32-x86/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:71 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:2 (project) -- Check for working CXX compiler: C:/Projects/share/foo/bar/tools/bin/cl.exe -- Check for working CXX compiler: C:/Projects/share/foo/bar/tools/bin/cl.exe -- works -- Detecting CXX compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'C:/Projects/share/foo/bar/hello/world/build/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin' ... things like that. Any ideas? Thank you in advance! Laszlo On Tue, Oct 30, 2012 at 3:55 PM, David Cole david.c...@kitware.com wrote: On Tue, Oct 30, 2012 at 11:24 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/30/2012 10:54 AM, Laszlo Papp wrote: I am trying to replace a Windows batch script with a python variant, but I am getting some issues when calling cmake as a subprocess: CMake Error: Could not create named generator NMake Makefiles JOM What cmake are you using? What do you get when you run cmake --help? Is that generator listed? -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake Maybe there's more than one CMake in your PATH. If you run where cmake in a Windows cmd prompt with the same PATH setting, it will show you all of them. The first one it shows you is the one that will be run when you do a cmake without a full path... -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automoc4 issue when using cmake (2.8.9)
Any ideas? Laszlo On Thu, Sep 27, 2012 at 9:22 PM, Laszlo Papp lp...@kde.org wrote: Seems those variables are empty: -- Looking for _POSIX_TIMERS - found CMAKE_PREFIX_PATH: CMAKE_MODULE_PATH: CMake Error at /usr/share/apps/cmake/modules/FindPackageHandleStandardArgs.cmake:198 (MESSAGE): Did not find automoc4 (Automoc4Config.cmake, install git://anongit.kde.org/automoc). (missing: AUTOMOC4_EXECUTABLE) Call Stack (most recent call first): /usr/share/apps/cmake/modules/FindAutomoc4.cmake:49 (find_package_handle_standard_args) /usr/share/apps/cmake/modules/FindKDE4Internal.cmake:426 (find_package) /usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (FIND_PACKAGE) CMakeLists.txt:31 (find_package) -- Configuring incomplete, errors occurred! Laszlo On Thu, Sep 27, 2012 at 7:05 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Wednesday 26 September 2012, Laszlo Papp wrote: do you know what changed couple dof days ago ? Did you use an older version of cmake before ? No, I have always used 2.8.9 pretty much since it was released because of the KDE Frameworks effort and other things. kdelibs may have been updated. Anything special to debug or print out? Hmm, maybe add some debug output ? In FindKDELibs4Internal.cmake there is a find_package() call for automoc. Print something there, e.g. CMAKE_PREFIX_PATH, CMAKE_MODULE_PATH and also the environment variable CMAKE_PREFIX_PATH. This should help. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automoc4 issue when using cmake (2.8.9)
Seems those variables are empty: -- Looking for _POSIX_TIMERS - found CMAKE_PREFIX_PATH: CMAKE_MODULE_PATH: CMake Error at /usr/share/apps/cmake/modules/FindPackageHandleStandardArgs.cmake:198 (MESSAGE): Did not find automoc4 (Automoc4Config.cmake, install git://anongit.kde.org/automoc). (missing: AUTOMOC4_EXECUTABLE) Call Stack (most recent call first): /usr/share/apps/cmake/modules/FindAutomoc4.cmake:49 (find_package_handle_standard_args) /usr/share/apps/cmake/modules/FindKDE4Internal.cmake:426 (find_package) /usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (FIND_PACKAGE) CMakeLists.txt:31 (find_package) -- Configuring incomplete, errors occurred! Laszlo On Thu, Sep 27, 2012 at 7:05 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Wednesday 26 September 2012, Laszlo Papp wrote: do you know what changed couple dof days ago ? Did you use an older version of cmake before ? No, I have always used 2.8.9 pretty much since it was released because of the KDE Frameworks effort and other things. kdelibs may have been updated. Anything special to debug or print out? Hmm, maybe add some debug output ? In FindKDELibs4Internal.cmake there is a find_package() call for automoc. Print something there, e.g. CMAKE_PREFIX_PATH, CMAKE_MODULE_PATH and also the environment variable CMAKE_PREFIX_PATH. This should help. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automoc4 issue when using cmake (2.8.9)
CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(test)
add_executable(test main.cpp)
#find_package(Automoc4 REQUIRED)
find_package(KDE4 REQUIRED)
main.cpp
int main() {return 0;}
Command to execute:
cmake ../ (in the build directory)
cmake version: 2.8.9
automoc4: 0.9.88
Laszlo
On Tue, Sep 25, 2012 at 7:33 PM, Alexander Neundorf a.neundorf-w...@gmx.net
wrote:
On Tuesday 25 September 2012, Laszlo Papp wrote:
Hi,
Worked couple of days ago. Help welcome.
Laszlo
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib/libssl.so
-- Looking for _POSIX_TIMERS
-- Looking for _POSIX_TIMERS - found
CMake Error at
/usr/share/apps/cmake/modules/FindPackageHandleStandardArgs.cmake:198
(MESSAGE):
Did not find automoc4 (Automoc4Config.cmake, install
git://anongit.kde.org/automoc). (missing: AUTOMOC4_EXECUTABLE)
Call Stack (most recent call first):
/usr/share/apps/cmake/modules/FindAutomoc4.cmake:49
(find_package_handle_standard_args)
/usr/share/apps/cmake/modules/FindKDE4Internal.cmake:423 (find_package)
/usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (FIND_PACKAGE)
CMakeLists.txt:27 (find_package)
Can you please describe the setup a bit more ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automoc4 issue when using cmake (2.8.9)
Forgot to mention that, but the problem happens when the find KDE4 is in
action. If I comment that line, and I try to find the automoc4 directly,
there are no such issues.
Further information:
pacman -Qo /usr/share/cmake-2.8/Modules/FindKDE4.cmake
/usr/share/cmake-2.8/Modules/FindKDE4.cmake is owned by cmake 2.8.9-1
pacman -Qo /usr/share/apps/cmake/modules/FindKDE4Internal.cmake
/usr/share/apps/cmake/modules/FindKDE4Internal.cmake is owned by kdelibs
4.9.1-1
pacman -Qo /usr/share/apps/cmake/modules/FindAutomoc4.cmake
/usr/share/apps/cmake/modules/FindAutomoc4.cmake is owned by kdelibs 4.9.1-1
Laszlo
On Tue, Sep 25, 2012 at 11:29 PM, Laszlo Papp lp...@kde.org wrote:
CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(test)
add_executable(test main.cpp)
#find_package(Automoc4 REQUIRED)
find_package(KDE4 REQUIRED)
main.cpp
int main() {return 0;}
Command to execute:
cmake ../ (in the build directory)
cmake version: 2.8.9
automoc4: 0.9.88
Laszlo
On Tue, Sep 25, 2012 at 7:33 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Tuesday 25 September 2012, Laszlo Papp wrote:
Hi,
Worked couple of days ago. Help welcome.
Laszlo
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib/libssl.so
-- Looking for _POSIX_TIMERS
-- Looking for _POSIX_TIMERS - found
CMake Error at
/usr/share/apps/cmake/modules/FindPackageHandleStandardArgs.cmake:198
(MESSAGE):
Did not find automoc4 (Automoc4Config.cmake, install
git://anongit.kde.org/automoc). (missing: AUTOMOC4_EXECUTABLE)
Call Stack (most recent call first):
/usr/share/apps/cmake/modules/FindAutomoc4.cmake:49
(find_package_handle_standard_args)
/usr/share/apps/cmake/modules/FindKDE4Internal.cmake:423
(find_package)
/usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (FIND_PACKAGE)
CMakeLists.txt:27 (find_package)
Can you please describe the setup a bit more ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Automoc4 issue when using cmake (2.8.9)
Hi, Worked couple of days ago. Help welcome. Laszlo -- Found Threads: TRUE -- Found OpenSSL: /usr/lib/libssl.so -- Looking for _POSIX_TIMERS -- Looking for _POSIX_TIMERS - found CMake Error at /usr/share/apps/cmake/modules/FindPackageHandleStandardArgs.cmake:198 (MESSAGE): Did not find automoc4 (Automoc4Config.cmake, install git://anongit.kde.org/automoc). (missing: AUTOMOC4_EXECUTABLE) Call Stack (most recent call first): /usr/share/apps/cmake/modules/FindAutomoc4.cmake:49 (find_package_handle_standard_args) /usr/share/apps/cmake/modules/FindKDE4Internal.cmake:423 (find_package) /usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (FIND_PACKAGE) CMakeLists.txt:27 (find_package) -- Configuring incomplete, errors occurred! pacman -Ql automoc4 automoc4 /usr/ automoc4 /usr/bin/ automoc4 /usr/bin/automoc4 automoc4 /usr/lib/ automoc4 /usr/lib/automoc4/ automoc4 /usr/lib/automoc4/Automoc4Config.cmake automoc4 /usr/lib/automoc4/Automoc4Version.cmake automoc4 /usr/lib/automoc4/automoc4.files.in automoc4 /usr/share/ automoc4 /usr/share/licenses/ automoc4 /usr/share/licenses/automoc4/ automoc4 /usr/share/licenses/automoc4/LICENSE -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[cmake-developers] Find module for Python3
Hey,
I am now really wondering why Python3 has never been supported so far.
At least, I cannot make that version of python work at the moment. We
have switched to Python3 in the KDE Windows project, and some projects
are not building because of the FindPythonInterpreter.cmake file.
It has hard coded versions, like:
set(_Python_VERSIONS
${Python_ADDITIONAL_VERSIONS}
2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5)
At least on Windows, it works like this:
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]
This is valid regedit entry also for the Python3 series.
It would not be too much of an effort to add the versions 3.1 and 3.2
as well, or just provide a new find module. Whatever fits better; I am
a newbie after all. We have now a GSoC project in KDE built on top of
Telepathy and it would be really cool if my student can finally
deliver the project also on Windows. I know we could use a local hack,
but I am now also proposing to have that feature supported in upstream
(cmake project) as well.
What do you think ?
Best Regards,
Laszlo Papp
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Find module for Python3
This is already fixed for the upcoming CMake 2.8.8. Please download the current rc and check if it works for you. Thanks for sharing this information. When do you plan to have this version finally released ? I can only find this with google: http://www.cmake.org/Bug/roadmap_page.php That date is behind us. I would probably initiate the cmake update then in the KDE Windows project. Thank you in advance! Best Regards, Laszlo Papp -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Platform Finding modules
Hi,
Are there any modules to realize the fact what platform I build on top
of ? I could imagine something like
Find{Harmattan,Fremantle,Maemo,MeeGo,Tizen,AnyPlatform}.cmake in wider
usage.
An example for using such a feature:
I would like to set something according to the actual platform, like
which compilation unit to build (like the relevant standalone only for
that given platform) and so on.
Thank you in advance!
Best Regards,
Laszlo Papp
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issues with finding raptor in the soprano build
I mentioned this in my first email: I think this is a bit closer to the issue: -- [TEST-BEGIN] - FIND_PACKAGE RAPTOR2.0.4 -- VERSION_VAR (missing: REQUIRED_VARS) -- [TEST-END] - FIND_PACKAGE RAPTOR2.0.4 for this debugging lines in the CMakeLists.txt file: message(STATUS [TEST-BEGIN] - FIND_PACKAGE RAPTOR2.0.4) find_package(Raptor 2.0.4) message(STATUS [TEST-END] - FIND_PACKAGE RAPTOR2.0.4) find_package(Raptor 2.0.4) should not generate -- VERSION_VAR (missing: REQUIRED_VARS) output. It should be like this: -- Found Raptor: /usr/lib/libraptor2.so (found suitable version 2.0.4, required is 2.0.4) Best Regards, Laszlo Papp -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issues with finding raptor in the soprano build
What version of CMake are you using? The extended signature of find_package_handle_standard_args() you use in FindRaptor.cmake became only available in CMake 2.8.4. Sadly 2.8.2 is the available version: http://harmattan-dev.nokia.com/pool/harmattan-beta3/free/c/cmake/ I was claiming a lot internally we should update it on Harmattan, but I have not found anybody really supporting this idea. :/ What would be the workaround for our environment ? Patch the FindRaptor.cmake file ? If yes, can someone give a hint, how ? Best Regards, Laszlo Papp -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issues with finding raptor in the soprano build
The soprano author seems to keep a local copy of that macro:
https://projects.kde.org/projects/kdesupport/soprano/repository/revisions/master/entry/cmake/modules/FindPackageHandleStandardArgs.cmake
It is probably outdated since vimdiff
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake
../cmake/modules/FindPackageHandleStandardArgs.cmake gives a lot of
differences.
Would it be possible to just update that file from upstream cmake, and
be done ? What is the general approach suggested for developers to
invoke cmake in such situations where it needs to run with old and new
cmake versions, too ?
1. Using the compatible old version everywhere, if possible ?
2. Keep local copies of such modules
3. Something else ?
Best Regards,
Laszlo Papp
On Wed, Nov 16, 2011 at 11:39 AM, Michael Wild them...@gmail.com wrote:
On 11/16/2011 09:35 AM, Laszlo Papp wrote:
What version of CMake are you using? The extended signature of
find_package_handle_standard_args() you use in FindRaptor.cmake became
only available in CMake 2.8.4.
Sadly 2.8.2 is the available version:
http://harmattan-dev.nokia.com/pool/harmattan-beta3/free/c/cmake/
I was claiming a lot internally we should update it on Harmattan, but
I have not found anybody really supporting this idea. :/
What would be the workaround for our environment ? Patch the
FindRaptor.cmake file ? If yes, can someone give a hint, how ?
Best Regards,
Laszlo Papp
You could handle version detection manually. Something like this should do:
set(RAPTOR_VERSION_IS_OK TRUE)
if(Raptor_FIND_VERSION)
if(Raptor_FIND_VERSION_EXACT AND
NOT ${RAPTOR_VERSION} VERSION_EQUAL ${Raptor_FIND_VERSION})
set(RAPTOR_VERSION_IS_OK FALSE)
elseif(${RAPTOR_VERSION} VERSION_LESS ${Raptor_FIND_VERSION})
set(RAPTOR_VERSION_IS_OK FALSE)
endif()
endif()
And then use RAPTOR_VERSION_IS_OK in the
find_package_handle_standard_args() call.
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issues with finding raptor in the soprano build
if(EXISTS ${CMAKE_ROOT}/Modules/Foo.cmake)
include(${CMAKE_ROOT}/Modules/Foo.cmake)
else()
...
endif()
If I have 2.8.2 installed on the host, but my software has 2.8.6
module imported, the version 2.8.2 will be selected. Therefore, it
will break. I think it needs more restricted check.
Best Regards,
Laszlo Papp
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Issues with finding raptor in the soprano build
Hi, I am now having issues with finding the raptor software for the build of the soprano project on Harmattan (N9 OS and distribution). It works on desktop and in scratchbox. It does not work in qemu though. It looks weird because redland was found properly, and the those find_package lines are residing after each other: http://quickgit.kde.org/?p=soprano.gita=blobh=61aa37db11b2091f4d9dbb822bbe8eecf56e543ehb=1f6789719c53d964e2c8e705330e043dc04f2806f=CMakeLists.txt#143 You can find the FindRaptor.cmake module here: http://quickgit.kde.org/?p=soprano.gita=blobh=c5043c8bef5306d847dae3bc511d18b2230ee453hb=1f6789719c53d964e2c8e705330e043dc04f2806f=cmake/modules/FindRaptor.cmake I think this is a bit closer to the issue: -- [TEST-BEGIN] - FIND_PACKAGE RAPTOR2.0.4 -- VERSION_VAR (missing: REQUIRED_VARS) -- [TEST-END] - FIND_PACKAGE RAPTOR2.0.4 for this debugging lines in the CMakeLists.txt file: message(STATUS [TEST-BEGIN] - FIND_PACKAGE RAPTOR2.0.4) find_package(Raptor 2.0.4) message(STATUS [TEST-END] - FIND_PACKAGE RAPTOR2.0.4) Also: I debugged it further on, and it enters this if condition, too: http://quickgit.kde.org/?p=soprano.gita=blobh=c5043c8bef5306d847dae3bc511d18b2230ee453hb=1f6789719c53d964e2c8e705330e043dc04f2806f=cmake/modules/FindRaptor.cmake#154 Also: I have this file on my system: /usr/include/raptor2/raptor.h (That is the one the FindRaptor.cmake module is looking for iirc). Thank you in advance! I am now really stuck here. Best Regards, Laszlo Papp -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issues with finding raptor in the soprano build
I have tried to grab more debug outputs, and here are my relevant printouts: statusPC_RAPTOR2_LIBDIR: /usr/lib statusPC_RAPTOR2_LIBRARY_DIRS: statusPC_RAPTOR2_INCLUDEDIR: /usr/include/raptor2 statusPC_RAPTOR2_INCLUDE_DIRS: /usr/include/raptor2 It seems okay to me, thus I am now even more lost.. :) Best Regards, Laszlo Papp -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issues with finding raptor in the soprano build
-- RAPTOR_LIBRARIES: /usr/lib/libraptor2.so -- RAPTOR_INCLUDE_DIR: /usr/include/raptor2 and root@Kaname:/usr/src/packages/BUILD/Build# dpkg -S /usr/lib/libraptor2.so libraptor2-dev: /usr/lib/libraptor2.so root@Kaname:/usr/src/packages/BUILD/Build# dpkg -S /usr/include/raptor2/raptor.h libraptor2-dev: /usr/include/raptor2/raptor.h root@Kaname:/usr/src/packages/BUILD/Build# dpkg -s libraptor2-dev | grep Version Version: 2.0.4-1 root@Kaname:/usr/src/packages/BUILD/Build# grep find_package ../CMakeLists.txt | grep Raptor find_package(Raptor 2.0.4) root@Kaname:/usr/src/packages/BUILD/Build# Best Regards, Laszlo Papp -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a main.cpp containing a QObject subclass
Thank you for your help Andreas. I have tried your approach. Please
see the attached logs. The moc files are now somehow not generated. I
might need to use qt4_wrap_cpp after all ?
Best Regards,
Laszlo Papp
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/colorgcc
-- Check for working C compiler: /usr/bin/colorgcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt4: /usr/bin/qmake (found version 4.7.4)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/lpapp/Projects/kde/test/build
/usr/bin/cmake -H/home/lpapp/Projects/kde/test -B/home/lpapp/Projects/kde/test/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/lpapp/Projects/kde/test/build/CMakeFiles /home/lpapp/Projects/kde/test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/depend
make[2]: Entering directory `/home/lpapp/Projects/kde/test/build'
cd /home/lpapp/Projects/kde/test/build /usr/bin/cmake -E cmake_depends Unix Makefiles /home/lpapp/Projects/kde/test /home/lpapp/Projects/kde/test /home/lpapp/Projects/kde/test/build /home/lpapp/Projects/kde/test/build /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/DependInfo.cmake --color=
Dependee /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/DependInfo.cmake is newer than depender /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/depend.internal.
Dependee /home/lpapp/Projects/kde/test/build/CMakeFiles/CMakeDirectoryInformation.cmake is newer than depender /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/depend.internal.
Scanning dependencies of target test
make[2]: Leaving directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/build
make[2]: Entering directory `/home/lpapp/Projects/kde/test/build'
/usr/bin/cmake -E cmake_progress_report /home/lpapp/Projects/kde/test/build/CMakeFiles 1
[100%] Building CXX object CMakeFiles/test.dir/main.cpp.o
/usr/lib/colorgcc/bin/c++-g -I/home/lpapp/Projects/kde/test -I/home/lpapp/Projects/kde/test/build-o CMakeFiles/test.dir/main.cpp.o -c /home/lpapp/Projects/kde/test/main.cpp
/home/lpapp/Projects/kde/test/main.cpp:8:24: fatal error: moc_main.cpp: No such file or directory
compilation terminated.
make[2]: *** [CMakeFiles/test.dir/main.cpp.o] Error 1
make[2]: Leaving directory `/home/lpapp/Projects/kde/test/build'
make[1]: *** [CMakeFiles/test.dir/all] Error 2
make[1]: Leaving directory `/home/lpapp/Projects/kde/test/build'
make: *** [all] Error 2
root /home/lpapp/Projects/kde/test/build # cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
set(test_SRCS
main.cpp
)
qt4_automoc(${test_SRCS})
add_executable(test ${test_SRCS})
root /home/lpapp/Projects/kde/test/build # cat ../main.cpp
#include QtCore/QObject
class MyClass : public QObject
{
Q_OBJECT
};
#include moc_main.cpp
int main( int argc, char** argv )
{
return 0;
}
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/colorgcc
-- Check for working C compiler: /usr/bin/colorgcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt4: /usr/bin/qmake (found version 4.7.4)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/lpapp/Projects/kde/test/build
/usr/bin/cmake -H/home/lpapp/Projects/kde/test -B/home/lpapp/Projects/kde/test/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/lpapp/Projects/kde/test/build/CMakeFiles /home/lpapp/Projects/kde/test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make
Re: [CMake] Building a main.cpp containing a QObject subclass
I am now attaching the log about the following files:
1) CMakeLists.txt file
2) main.cpp
3) build log
4) moc_main.cxx
Q_MOC_OUTPUT_REVISION is somehow not defined, but not sure why.
Best Regards,
Laszlo Papp
On Mon, Oct 31, 2011 at 1:31 PM, Andreas Pakulat ap...@gmx.de wrote:
On 31.10.11 13:10:28, Laszlo Papp wrote:
Thank you for your help Andreas. I have tried your approach. Please
see the attached logs. The moc files are now somehow not generated. I
might need to use qt4_wrap_cpp after all ?
Sorry, seems like my local experiments led to wrong conclusions here. At
least CMake 2.8.5-rc2 ships with a Qt4Macros.cmake file in which
QT4_AUTOMOC can only QObject subclasses in header files (i.e. the
foo.moc form). Don't know about the cmake-builtin automoc support since
I don't have 2.8.6 at hand here.
So yes, at least with the macro's you'll have to go with qt4_wrap_cpp or
write your own automoc macro, which shouldn't be too hard if you look at
the existing one.
Andreas
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
cmake_minimum_required(VERSION 2.8)
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
include_directories(
${QT_INCLUDES}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
)
set(test_SRCS
main.cpp
)
qt4_wrap_cpp(test_MOC_FILES ${test_SRCS})
#qt4_automoc(${test_SRCS})
add_executable(test ${test_SRCS} ${test_MOC_FILES})
target_link_libraries(test ${QT_QTCORE_LIBRARY})
#include QtCore/QObject
class MyClass : public QObject
{
Q_OBJECT
};
#include moc_main.cxx
int main( int argc, char** argv )
{
return 0;
}
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/colorgcc
-- Check for working C compiler: /usr/bin/colorgcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++
-- Check for working CXX compiler: /usr/lib/colorgcc/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found.
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found.
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found.
-- Found Qt4: /usr/bin/qmake (found version 4.7.4)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/lpapp/Projects/kde/test/build
/usr/bin/cmake -H/home/lpapp/Projects/kde/test -B/home/lpapp/Projects/kde/test/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/lpapp/Projects/kde/test/build/CMakeFiles /home/lpapp/Projects/kde/test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/depend
make[2]: Entering directory `/home/lpapp/Projects/kde/test/build'
/usr/bin/cmake -E cmake_progress_report /home/lpapp/Projects/kde/test/build/CMakeFiles 3
[ 33%] Generating moc_main.cxx
/usr/bin/moc -I/home/lpapp/Projects/kde/test -I/home/lpapp/Projects/kde/test/build -I/usr/include/QtDesigner -I/usr/include/QtDeclarative -I/usr/include/QtScriptTools -I/usr/include/QtDBus -I/usr/include/QtXml -I/usr/include/QtSql -I/usr/include/QtOpenGL -I/usr/include/QtMultimedia -I/usr/include/QtNetwork -I/usr/include/phonon -I/usr/include/QtXmlPatterns -I/usr/include/QtWebKit -I/usr/include/QtHelp -I/usr/include/QtUiTools -I/usr/include/QtTest -I/usr/include/QtScript -I/usr/include/QtSvg -I/usr/include/Qt3Support -I/usr/include/QtGui -I/usr/include/QtCore -I/usr/share/qt/mkspecs/default -I/usr/include -o /home/lpapp/Projects/kde/test/build/moc_main.cxx /home/lpapp/Projects/kde/test/main.cpp
cd /home/lpapp/Projects/kde/test/build /usr/bin/cmake -E cmake_depends Unix Makefiles /home/lpapp/Projects/kde/test /home/lpapp/Projects/kde/test /home/lpapp/Projects/kde/test/build /home/lpapp/Projects/kde/test/build /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/DependInfo.cmake --color=
Dependee /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/DependInfo.cmake is newer than depender /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/depend.internal.
Dependee /home/lpapp/Projects/kde/test/build/CMakeFiles/CMakeDirectoryInformation.cmake is newer than depender /home/lpapp/Projects/kde/test/build/CMakeFiles/test.dir/depend.internal.
Scanning dependencies of target test
make[2]: Leaving directory `/home/lpapp/Projects/kde/test/build'
make -f CMakeFiles/test.dir/build.make CMakeFiles/test.dir/build
make[2]: Entering directory `/home
Re: [CMake] Building a main.cpp containing a QObject subclass
You're not supposed to add the mocfiles variable contents you receive
from qt4_wrap_cpp to the list of sources. In particular not because you
already #include that same file in the main.cpp. If you look at the
generated file you'll notice that it requires all the declarations from
the main.cpp, i.e. its not a standalone C++ source and cannot be
compiled on its own.
You are right. That sounds logical. Unfortunately, the moc file is not
generated if I do it that way. If I generate it manually, the build
works. Is there a way, similar to add_dependencies, to tell moc in the
CMakeLists.txt file to generate the moc_main.cxx before the main.cpp ?
I think those macros are not enough alone since
qt4_generate_moc(main.cpp moc_main.cxx) did not work either. I would
expect that qt4_generate_moc can work for source files. Apparently,
qt4_wrap_cpp can work only for header files ...
Something like this might work by using automoc, but is this really
that hard by using cmake ? Please do not take it an offense, but it is
pretty simple by using qmake ;)
[code]
cmake_minimum_required(VERSION 2.8)
find_package(Automoc4 REQUIRED)
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
include_directories(
${QT_INCLUDES}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
)
set(test_SRCS
main.cpp
)
automoc4_add_executable(test ${test_SRCS})
target_link_libraries(test ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY})
[/code]
Also,set(CMAKE_AUTOMOC ON) aborts the build:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid
Aborted
I have cmake version 2.8.6. installed.
Best Regards,
Laszlo Papp
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a main.cpp containing a QObject subclass
Okay: I got it working by using qt4_generate_moc :) I am not sure it
is the cleanest way. Fixing the set(CMAKE_AUTOMOC ON) abort will
probably the cleanest.. Thank you for your help again! :)
Best Regards,
Laszlo Papp
cmake_minimum_required(VERSION 2.8)
include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
find_package(Qt4)
include_directories(
${QT_INCLUDES}
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
)
qt4_generate_moc(main.cpp ${CMAKE_CURRENT_BINARY_DIR}/main.moc)
set(test_SRCS
main.cpp
main.moc
)
add_executable(test ${test_SRCS})
target_link_libraries(test ${QT_QTCORE_LIBRARY})
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a main.cpp containing a QObject subclass
Please add a bug in the cmake bug tracker for that: http://public.kitware.com/Bug/ David Faure has fixed it today, and the patch is probably in your inbox somewhere. :P Best Regards, Laszlo Papp -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_ROOT issue in scratchbox, N9(50)
Hi Alex,
Which version of cmake is this ?
Is this 2.8.5rcX or trunk ?
Then it might be the new multiarch support feature maybe.
2.8.4 and it will probably not even change on Harmattan
Uh.
The part where you install *.cmake files into ${CMAKE_ROOT}/Modules/ is really
bad. Remove it. You should never ever do that.
The user may simply use another version of cmake, then they won't be found, so
you can't rely on them at all in any way.
Not sure what you mean by this, but the proposed alternative way seems
to also be a cmake version dependent deal. From the documentation:
...CMake 2.6 introduced support for exporting targets from one
project and importing them into another However I think it is
achievable...Not sure about the version difference aforementioned.
FindGluon.cmake is supposed to be there, so you can rely on it and it will
tell you where Gluon is installed or if it's not installed.
It's like putting a treasure map just next to the treasure.
Once you find the map (or FindGluon.cmake), you already found the treaure
(Gluon) itself, no need to search for it anymore.
Instead Gluon should install a GluonConfig.cmake file.
Mmm, so it seems a bit controversial to me. You mentioned that above
it is bad if the map is nearby the treasure. However, it seems to
still be the situation since Gluon will install it. I thought that the
only way is that if it is independently installed from Gluon since
that way, it exists anytime. This is still a bit confusing to me.
Could you please clarify ? Thank you!
Best Regards,
Laszlo Papp
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: CPACK/NSIS: Subfolders/components related generation issue
Hi, Thanks for you guys, it helped a lot. :) We now have a good installer for testing purposes. Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: CPACK/NSIS: Subfolders/components related generation issue
Hi,
I am trying to make our cpack setup work for an NSIS installer. I
would like to make a very first step towards a component based
installer on Windows.
For the time being, the basic idea is that: I have some subfolders
(different libraries) inside the project, and I would like to make
every subfolder a separate component as a very first, test stage (I
can later fine-tune the whole setup according to our purposes, if it
works). Hence the subfolders (components) would be for instance:
core/audio/input/graphics/engine/player/creator and so forth.
In the current situation, the generated installer contains and
installs only the creator folder, but with DLLs of some other
folders, like core/audio/input/graphics/engine/player and so forth. I
am not sure what I am doing wrong, but this is the relevant CPack NSIS
entry in the ${CMAKE_SOURCE_DIR}/CMakeLists.txt:
https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/CMakeLists.txt#L224
As a matter of the fact, I am not getting any separate core
component either. Here is the relevant install line from the
${CMAKE_SOURCE_DIR}/core/CMakeLists.txt file:
https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/core/CMakeLists.txt#L106
My idea was that: I should at least get a core component inside the
NSIS installer with this simple case. What am I doing wrong ? I would
also attach my generated project.nsi, if there was no 40 KB limitation
on this list.
Hence please ask for specific information from that file, if you need anything.
Thank for your help in advance!
Best Regards,
Laszlo Papp
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: CPACK/NSIS: Subfolders/components related generation issue
Hi Eric,
So the solution begins with DOT NOT USE ABSOLUTE INSTALL PATH,
give it a try and tell us how it goes.
Thanks a lot for your answer. It has been very useful. The components
seem much better for now after this change you were proposing:
https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/core/CMakeLists.txt#L19
The bin/share/include directories are generated properly inside each
component, but there is still some issue with the library part. There
are no DLLs generated inside the components and I do not know why. It
seems to me, like ${LIB_INSTALL_DIR} is properly used in the install
lines.
Any thought ?
Best Regards,
Laszlo Papp
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Pass an array type argument to a macro
Hi,
Is there a way of passing array arguments to a macro with cmake ?
I would like to write a generic test generation macro, like this:
MACRO(UNIT_TESTS modulename libraries)
FOREACH(testname ${ARGN})
qt4_automoc(${testname}.cpp)
add_executable(${modulename}-${testname} ${testname}.cpp)
target_link_libraries(${modulename}-${testname}
${libraries} ${QT_QTTEST_LIBRARY})
add_test(${modulename}-${testname} ${modulename}-${testname})
if(WINCE)
target_link_libraries(${modulename}-${testname}
${WCECOMPAT_LIBRARIES})
endif(WINCE)
ENDFOREACH(testname)
ENDMACRO(UNIT_TESTS)
The problem is that when I would like to use the aforementioned macro
like this:
UNIT_TESTS(
${CORE_LIBS}# libraries argument
core # modulename argument
objecttest
)
The libraries argument contains only the first part of the
${CORE_LIBS}. For instance there is this inside the ${CORE_LIBS}:
/usr/lib/libQtCore.so;/usr/lib/libQtGui.so;/usr/lib/libQtScript.so
The libraries will contain: /usr/lib/libQtCore.so
The problem is that if I would like to use such a test generation
macro from each submodule of a really huge project, I would duplicate,
triplicate and so forth this macro in each submodule instead of having
it nicely just inside the main CMakeLists.txt or at least inside some
core CMakeLists.txt. Continous copy paste of this macro with hard
coded submodule specific values do not seem to be a good solution
or/and approach.
The workaround can be that I determine an internal variable that can
be filled out with the proper content and use that internally inside
the macro, but I do not consider that nice solution. The best would be
if we can somehow pass array type arguments to the cmake macro. Is
that possible ? Does it already somehow work like that ?
Thank you in advance!
Best Regards,
Laszlo Papp
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Pass an array type argument to a macro
Thanks a lot, Eric and David ! Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple install section from the same base folder
Hi, On Tue, Jul 12, 2011 at 9:03 AM, Andreas Naumann andreas-naum...@gmx.net wrote: You could use file(GLOB_RECURSE files *.h) The problem is a bit slightly different. It is not a problem for me to find the files on my own. :) The problem is that I would like to install foo/bar.h into the destination as foo/bar.h and not just bar.h. I guess that would cover the issues. Even if I ever need some recursive search, it will hold the files without the subfolder, so they will be installed into the destination as bar.h and not foo/bar.h. Did I miss something ? or install the main directory with install(DIRECTORY ... ) and exclude every non-header file (and possibly svn..) We have source, header, data, icon, et cetera files inside the given library folder, so this would cause more issues than benefit in our case. Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple install section from the same base folder
Hi, Not sure whether if it's better than your current solution. May be it's a little less painless to write. Would it make sense to add an option to these install sections so that it grabs the files as they are (with subfolders, if any), if you set that option or something like that ? That would result the easiest and cleanest way in my novice opinion. Is it possible to ask for such a feature ? Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple install section from the same base folder
Hi Eric,
Honestly I do not see any benefit in this, but may be I did not
understand what you meant?
Here is an example then:
Original version:
install(FILES
atticamanager.h
authentication.h
DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib
COMPONENT Devel
)
install(FILES
archive/archive.h
DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib/archive
COMPONENT Devel
)
install(FILES
models/commentitemsmodel.h
models/gameitemsmodel.h
models/highscoresmodel.h
DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib/models
COMPONENT Devel
)
Here is what I would advise (of course by setting some option if you
want two have it also the original way):
install(FILES
atticamanager.h
authentication.h
archive/archive.h
models/commentitemsmodel.h
models/gameitemsmodel.h
models/highscoresmodel.h
DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib
COMPONENT Devel
)
This way, it would be much cleaner and shorter to me.
Best Regards,
Laszlo Papp
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
Hi,
Can you try this with a newer CMake version? Perhaps the 2.8.5 that just came
out?
Same results. How I think I found some interesting thing. It works
just fine in this order:
find_package(Qt4)
if(QT_QTDECLARATIVE_FOUND)
add_subdirectory(touch)
else(QT_QTDECLARATIVE_FOUND)
message(WARNING Qt installation lacks Qt Declarative -
disabling touch based player)
endif(QT_QTDECLARATIVE_FOUND)
if(WITH_KDE)
find_package(KDE4)
if(KDE4_FOUND)
include_directories(${KDE4_INCLUDES})
add_subdirectory(kde)
add_subdirectory(kdeext)
if(BUILD_PLASMOID)
add_subdirectory(plasmoid)
endif(BUILD_PLASMOID)
else(KDE4_FOUND)
message(STATUS WITH_KDE is enabled but KDE libraries are
not found - not building the KDE players or the Plasmoid)
endif(KDE4_FOUND)
endif(WITH_KDE)
However, if I change the order for this, it stops working:
if(WITH_KDE)
find_package(KDE4)
if(KDE4_FOUND)
include_directories(${KDE4_INCLUDES})
add_subdirectory(kde)
add_subdirectory(kdeext)
if(BUILD_PLASMOID)
add_subdirectory(plasmoid)
endif(BUILD_PLASMOID)
else(KDE4_FOUND)
message(STATUS WITH_KDE is enabled but KDE libraries are
not found - not building the KDE players or the Plasmoid)
endif(KDE4_FOUND)
endif(WITH_KDE)
find_package(Qt4)
if(QT_QTDECLARATIVE_FOUND)
add_subdirectory(touch)
else(QT_QTDECLARATIVE_FOUND)
message(WARNING Qt installation lacks Qt Declarative -
disabling touch based player)
endif(QT_QTDECLARATIVE_FOUND)
If I put the find_package(Qt4) macro before the find_package(KDE4)
macro, it works as expected. If I put that after, it does not. I guess
this is the key here. I do not know those macros actually and I do not
have time right now to look into their internal source, but that is
the culsprit somehow.
Best Regards,
Laszlo Papp
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Multiple install section from the same base folder
Hi,
I have just realized this snippet in my CMakeLists.txt file:
install(FILES
atticamanager.h
authentication.h
DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib
COMPONENT Devel
)
install(FILES
archive/archive.h
DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib/archive
COMPONENT Devel
)
install(FILES
models/commentitemsmodel.h
models/gameitemsmodel.h
models/highscoresmodel.h
DESTINATION ${INCLUDE_INSTALL_DIR}/gluon/player/lib/models
COMPONENT Devel
)
I wonder whether it could be done smarter. In the example above, there
are subfolders like archive, models. It could also contain 5-10
subfolders (even more) and we install the headers this way: one
separate install section for each subfolder even if we explicitely
write the subfolders all the time, like archive/archive.h,
models/commentitemsmodel.h, et cetera.
Are we doing it wrong and there is already a smarter cmake option for
this ? I find it useful if there is just one section for those things,
but if it is technically not possible or against the design, please
let me know.
Best Regards,
Laszlo Papp
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
Hi,
I made some experiment with this issue and I tried two ideas out:
1) I made a cmake_test project folder with two subfolders: foo and
bar. From the main CMakeLists.txt:
add_subdirectory(foo)
add_subdirectory(bar)
Then:
cat ../foo/CMakeLists.txt
find_package(Qt4)
if(QT_QTDECLARATIVE_FOUND)
message(found it)
endif()
cat ../bar/CMakeLists.txt
find_package(Qt4)
if(QT_QTDECLARATIVE_FOUND)
message(found it again)
endif()
The result was that I got both messages. It might well mean that
something is messed in my project build environment, but this is
something which I would like to ask for help with from you.
2) If I try to find the Qt4 package twice the FOUND variable is set
properly. It might help with troubleshooting the issue, but I do not
know the internal cmake operation.
find_package(Qt4)
find_package(Qt4)
message(STATUS QT_QTDECLARATIVE_FOUND: ${QT_QTDECLARATIVE_FOUND})
if(QT_QTDECLARATIVE_FOUND)
add_subdirectory(touch)
else(QT_QTDECLARATIVE_FOUND)
message(WARNING Qt installation lacks Qt Declarative -
disabling touch based player)
endif(QT_QTDECLARATIVE_FOUND)
Best Regards,
Laszlo Papp
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
find_package(Qt4) if(QT_QTDECLARATIVE_FOUND) message(found it) endif() find_package(Qt4) if(QT_QTDECLARATIVE_FOUND) message(found it again) endif() Result: found it found it again I guess this simple example does not represent the issue well since it is not provide any information about passing values among CMakeLists.txt files. Funky thing is that if I put the same conditions for the declarative after this line: https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/core/CMakeLists.txt#L9 It works just fine. However I guess it is because the first occurence in the build order. Does cmake have some issue about using something like that more times on this platform ? Could you please investigate ? Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
I have just tried to update the cmake version manually from 2.8.2 to 2.8.4, but it did not help either. It really seems to be a weird bug on this platform. It works just find to use the macro and found line more times but N9. I am not sure what else I could try out... Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
Hi, I would like to build our KDE project for the Maemo6/Harmattan distribution, but this macro, aforementioned, does not seem to work properly. I have the following snippet in my CMakeLists.txt file: [snippet] find_package(Qt4) if(QT_QTDECLARATIVE_FOUND) add_subdirectory(touch) else(QT_QTDECLARATIVE_FOUND) message(WARNING Qt installation lacks Qt Declarative - disabling touch based player) endif(QT_QTDECLARATIVE_FOUND) [/snippet] I have all the available libqt4-declarative packages installed (from the dpkg -l *declarative* output): ii libqt4-declarative 4.7.4~git20110517-0maemo8+0m6 Qt 4 declarative module ii libqt4-declarative-dev 4.7.4~git20110517-0maemo8+0m6 Qt 4 Declarative development files ii qt4-declarative-qmlviewer 4.7.4~git20110517-0maemo8+0m6 Qt 4 declarative module My application even builds fine if I remove the check, thus it can build my QML Gluon player meaning that there is no real issues with the headers, libraries on my system, but with the macro. cmake --version cmake version 2.8.2 Also: grep -rn QT_QTDECLARATIVE_FOUND /usr/share/cmake-2.8/ /usr/share/cmake-2.8/Modules/FindQt4.cmake:190:# QT_QTDECLARATIVE_FOUND True if QtDeclarative was found. This macro worked just fine previously everywhere we used, windows, mac, linux, meego. This is the first environment for me, where it causes trouble. For the time being, I commented this check out, but I would like to find the root cause of the issue. Any help is welcome and thank you in advance! Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
Hi Clinton, What is the value of QT_QTDECLARATIVE_LIBRARY ? The QT_QTDECLARATIVE_FOUND depends on that value. /usr/lib/libQtDeclarative.so That file exists in scratchbox properly: ls -lda /usr/lib/libQtDeclarative.so lrwxrwxrwx 1 lpapp lpapp 25 Jul 5 13:49 /usr/lib/libQtDeclarative.so - libQtDeclarative.so.4.7.4 Even the file where this /usr/lib/libQtDeclarative.so points to: ls -lda /usr/lib/libQtDeclarative.so.4.7.4 -rw-r--r-- 1 lpapp lpapp 3406200 Jun 23 03:41 /usr/lib/libQtDeclarative.so.4.7.4 Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
Hi again :) Hmm... OK. I'm not able to reproduce this problem. Do you know if the other *_FOUND variables are set? Yes, check this line out: https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/player/CMakeLists.txt#L19 The macro in question can be found below. Is it also a problem if you run cmake on a CMakeLists.txt file with just the following: find_package(Qt4) if(QT_QTDECLARATIVE_FOUND) message(found it) endif() Mmm, it is getting really weird because I get the found it message this way. Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
Hi, That may be messing up subsequent if logic in an unexpected way... (If so, it seems like it's still a bug, but that would be a different issue...) Thanks for pointing out about my buggyness (I pushed the fix) :) However, this did not solve the issue: -elseif(KDE4_FOUND) +else(KDE4_FOUND) Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QT_QTDECLARATIVE_FOUND issue on N9(50)
Hi, Back to the simple CMakeLists.txt: find_package(Qt4) if(QT_QTDECLARATIVE_FOUND) message(found it) endif() find_package(Qt4) if(QT_QTDECLARATIVE_FOUND) message(found it again) endif() Result: found it found it again Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE_ROOT issue in scratchbox, N9(50)
Hi, I am trying to build a package in scratchbox on Harmattan, but I am having a small issue in the installation step (The compilation and build went just fine). Everything worked just fine previously on MeeGo and desktop system. This is the first place where I have such an issue. We have some our own internal cmake module files that we would like to install. This is the relevant CMakeLists.txt entry of our build system: https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/CMakeLists.txt#L172 When I am trying to find the the FindOpenGLES2.cmake file for instance in our debian folder, it is like /debian/tmp/targets/maemo6-armv7/usr/share/cmake-2.8/Modules/FindOpenGLES2.cmake instead of /debian/tmp/usr/share/cmake-2.8/Modules/FindOpenGLES2.cmake. It somehow picks up the target. I am not sure whether or not it is expected, but the other file installations do not pick this targets/maemo6-armv7 folder up. Am I doing something wrong in our CMakeLists.txt file or is it the expected location and for non cmake files the expected location is /debian/tmp/usr/... ? As a simple and novice user, I would expect it should be the same in all case. Any help is welcome, thank you in advance! =) Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
My familiar did a package as an interim solution and let us see whether or not this version can be integrated into the 1.2 MeeGo release or just later. http://forum.meego.com/showthread.php?p=18810#post18810 Best Regards, Laszlo Papp On Tue, Mar 8, 2011 at 7:59 AM, Laszlo Papp djsz...@archlinux.us wrote: I could not still build cmake.. But I did this modification locally you suggested and that is the output: CPack: Create package using RPM CPack: Install projects CPack: - Run preinstall target for: Gluon CPack: - Install project: Gluon CPack: Create package CPackRPM: Will use GENERATED spec file: /home/meego/gluon/build/_CPack_Packages/Linux/RPM/SPECS/gluon.spec CPack: - package: /home/meego/gluon/build/Gluon-0.71.0.rpm.rpm generated. It was a quite slow process after the spec file generation, but it seems to work. I do really hope someone can fix the arm - qemu - cmake thread hanging issues otherwise no idea how to get this functionality working officially... Best Regards, Laszlo PApp On Tue, Mar 8, 2011 at 12:53 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. No idea whether or not that will be the solution, but It is hilarious, I cannot run the cmake ../ properly on the version 2.8.4... I mean it always enters an endless loop at random point, but all the time. I heard qemu+cmake is scary, but still I did never use such combination, I let other comment on that one. How can I build the newest version of the cmake ? Cmake freezes all the time from the shadow build directory It is more than quite /pesky/. Concerning CPackRPM main issue, would try to 1) backup the CMake 2.8.3 , CPackRPM.cmake file 2) Edit CPackRPM.cmake file and change: %install if [ -e $RPM_BUILD_ROOT ]; then mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot/*\ $RPM_BUILD_ROOT else mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT fi to %install if [ -e $RPM_BUILD_ROOT ]; then rm -rf $RPM_BUILD_ROOT fi mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT then rerun cpack. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake hanging when run inside QEmu
Was discussed on #meego-arm. Nokia and other professionals are heavily working on this issue as far as it a qemu emulation issue, let us see. Best Regards, Laszlo Papp On Tue, Mar 8, 2011 at 2:25 AM, Laszlo Papp djsz...@archlinux.us wrote: 1) What is the hackaround to install the newest version on arm ? 2) What is the final solution ? I think there are severe thread issues debug output contains almost the same information as the normal, not much addition... Should I open a bugreport instead with critical priority ? Put it mildly, it is completely useless on this arm. Best Regards, Laszlo Papp On Tue, Mar 8, 2011 at 12:55 AM, Eric Noulard eric.noul...@gmail.com wrote: Hi, I am starting a separate thread on this hanging issue. -- Forwarded message -- From: Laszlo Papp xx Date: 2011/3/8 Subject: Re: [CMake] CPack and RPM packages To: Eric Noulard eric.noul...@gmail.com Cc : CMake ML cmake@cmake.org 1st run: ca -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits Deadlock-like feeling on the user side except that I can kill the process - 2nd run: -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream Endless loop feeling again here. - 3rd run: cmake -DCMAKE_INSTALL_PREFIX=/usr .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking
Re: [CMake] CPack and RPM packages
Any progress on it ? One more information, this n900-devel image uses internally qemu and I am not sure that can cause any issue for the build system. That is also interesting why the debian packaging worked just fine in the scratchbox using also qemu internally. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 5:27 AM, Laszlo Papp djsz...@archlinux.us wrote: By the way, you can find here the gluon-*.rpm packages built by the OBS: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ (unpack it with rpm2cpio src.rpm | cpio -idmv) Those spec files are done by a packager (human), thus not automated by a generator. I am not sure it helps with anything after all, but I try to provide as much as I can. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 2:33 AM, Laszlo Papp djsz...@archlinux.us wrote: On Sun, Mar 6, 2011 at 11:27 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/6 Laszlo Papp djsz...@archlinux.us: Mmh, my previous mail is blocked because the cpack.log is too big. http://djszapi.homelinux.net/rpmbuild.out http://djszapi.homelinux.net/rpmbuild.err http://djszapi.homelinux.net/cpack.log I do not quite understand what makes rpmbuild fail. Could you send me [a link to] the generated gluon.spec file. And could you show what are the INSTALL rules you use in the CMakeLists.txt for gluon_qtplayer and template.qml and Invaders_Assets_Material.gml http://djszapi.homelinux.net/gluon.spec http://djszapi.homelinux.net/template.qml.install http://djszapi.homelinux.net/qtplayer.install http://djszapi.homelinux.net/invaders_assets_material.gml.install = /usr/share/gluon/games/invaders.gluon/Assets/Invaders_Assets_Material.gml = under the invaders.gluon Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
On Mon, Mar 7, 2011 at 9:11 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/7 Laszlo Papp djsz...@archlinux.us: Any progress on it ? Nope. I won't be very responsive this week. That does not sound too good.. ! One more information, this n900-devel image uses internally qemu and I am not sure that can cause any issue for the build system. I don't like I said I'm not that experienced with cross-compiling env. Nobody told you are, I have been just trying to provide as much information as I can ... That is also interesting why the debian packaging worked just fine in the scratchbox using also qemu internally. Does the pb you are facing for RPM occur in the same scractchbox env? No, maemo/debian system (scratchbox) is a different story compared to the meego/rpm way. If this repo corresponds to the same gluon: http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt No, it does not, and it is also mentioned on the main site by the kde-sysadmins so that do not use it because it is quite obsolete. It is a gitorious tragedy we cannot remove that from there. This is the current repository: https://projects.kde.org/projects/playground/games/gluon/repository Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
As said, the working OBS spec files can be found here: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ http://djszapi.homelinux.net/gluon.spec - this is the cpack/cmake generated one. Well, the cpack one doesn't really do anything, it only moves files around (and apparently requires some external calling code to move them into place). I don't know anything about cpack, just that the spec file you have there doesn't do anything except moving files around (and maybe package them if they happen to end up in the right place), but certianly not build anything. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 9:16 PM, Laszlo Papp djsz...@archlinux.us wrote: On Mon, Mar 7, 2011 at 9:11 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/7 Laszlo Papp djsz...@archlinux.us: Any progress on it ? Nope. I won't be very responsive this week. That does not sound too good.. ! One more information, this n900-devel image uses internally qemu and I am not sure that can cause any issue for the build system. I don't like I said I'm not that experienced with cross-compiling env. Nobody told you are, I have been just trying to provide as much information as I can ... That is also interesting why the debian packaging worked just fine in the scratchbox using also qemu internally. Does the pb you are facing for RPM occur in the same scractchbox env? No, maemo/debian system (scratchbox) is a different story compared to the meego/rpm way. If this repo corresponds to the same gluon: http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt No, it does not, and it is also mentioned on the main site by the kde-sysadmins so that do not use it because it is quite obsolete. It is a gitorious tragedy we cannot remove that from there. This is the current repository: https://projects.kde.org/projects/playground/games/gluon/repository Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
Further news, I have just tried the rpm generation on my host system out and it worked like a charm, here are the logs: http://djszapi.homelinux.net/cpack_host.log http://djszapi.homelinux.net/gluon_host.spec I hope it helps with something... Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 9:29 PM, Laszlo Papp djsz...@archlinux.us wrote: As said, the working OBS spec files can be found here: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ http://djszapi.homelinux.net/gluon.spec - this is the cpack/cmake generated one. Well, the cpack one doesn't really do anything, it only moves files around (and apparently requires some external calling code to move them into place). I don't know anything about cpack, just that the spec file you have there doesn't do anything except moving files around (and maybe package them if they happen to end up in the right place), but certianly not build anything. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 9:16 PM, Laszlo Papp djsz...@archlinux.us wrote: On Mon, Mar 7, 2011 at 9:11 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/7 Laszlo Papp djsz...@archlinux.us: Any progress on it ? Nope. I won't be very responsive this week. That does not sound too good.. ! One more information, this n900-devel image uses internally qemu and I am not sure that can cause any issue for the build system. I don't like I said I'm not that experienced with cross-compiling env. Nobody told you are, I have been just trying to provide as much information as I can ... That is also interesting why the debian packaging worked just fine in the scratchbox using also qemu internally. Does the pb you are facing for RPM occur in the same scractchbox env? No, maemo/debian system (scratchbox) is a different story compared to the meego/rpm way. If this repo corresponds to the same gluon: http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt No, it does not, and it is also mentioned on the main site by the kde-sysadmins so that do not use it because it is quite obsolete. It is a gitorious tragedy we cannot remove that from there. This is the current repository: https://projects.kde.org/projects/playground/games/gluon/repository Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? Best Regards, Laszlo Papp On Tue, Mar 8, 2011 at 12:31 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/7 Laszlo Papp djsz...@archlinux.us: As said, the working OBS spec files can be found here: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ Not really, since binary RPMs do not contains the spec file, but I did find the spec file in src: http://repo.pub.meego.com/home:/sandst1/standard/src/ (within the src.rpm) http://djszapi.homelinux.net/gluon.spec - this is the cpack/cmake generated one. I have seen that one, and as I said many files seems to be installed with ABSOLUTE DESTINATION and end-up with a %config attribute. If they were installed with relative PATH this wouldn't be the case. Well, the cpack one doesn't really do anything, it only moves files around (and apparently requires some external calling code to move them into place). CPackRPM supposed CMake+build has already been run so CPackRPM generated spec file is a shortcutted one. I don't know anything about cpack, just that the spec file you have there doesn't do anything except moving files around (and maybe package them if they happen to end up in the right place), but certianly not build anything. Yes that's the expected behavior. You cannot (in your case) call CPack without calling CMake first. CMake + make will do the build before CPack get a chance to run. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. No idea whether or not that will be the solution, but It is hilarious, I cannot run the cmake ../ properly on the version 2.8.4... I mean it always enters an endless loop at random point, but all the time. I heard qemu+cmake is scary, but still How can I build the newest version of the cmake ? Cmake freezes all the time from the shadow build directory It is more than quite /pesky/. Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
for member template support -- Checking for member template support - yes -- Checking for standard template specialization syntax -- Checking for standard template specialization syntax - yes -- Checking whether argument dependent lookup is supported -- Checking whether argument dependent lookup is supported - yes -- Checking whether struct stat has st_mtim member -- Checking whether struct stat has st_mtim member - yes -- Checking for C type size macros -- Checking for C type size macros - compiled -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of char -- Check size of char - done -- Check size of __int64 -- Check size of __int64 - failed -- Checking whether char is signed -- Checking whether char is signed - no -- Checking whether C++ compiler has 'long long' -- Checking whether C++ compiler has 'long long' - yes -- Checking if istream supports long long -- Checking if istream supports long long - yes -- Checking if ostream supports long long -- Checking if ostream supports long long - yes -- Checking whether C compiler has ptrdiff_t in stddef.h -- Checking whether C compiler has ptrdiff_t in stddef.h - yes -- Checking whether C compiler has ssize_t in unistd.h -- Checking whether C compiler has ssize_t in unistd.h - yes -- Looking for connect in socket;dl -- Looking for connect in socket;dl - not found -- Looking for gethostbyname in c -- Looking for gethostbyname in c - found -- Looking for recv in network;dl -- Looking for recv in network;dl - not found -- Looking for getch in ws2_32;dl -- Looking for getch in ws2_32;dl - not found -- Looking for getch in winmm;dl -- Looking for getch in winmm;dl - not found -- Looking for idna_to_ascii_lz in idn;dl -- Looking for idna_to_ascii_lz in idn;dl - not found -- Looking for dlopen in dl -- Looking for dlopen in dl - found -- Looking for process.h Nice, nice nothing, but stall here again... I would say it is a critical cmake BUG... Best Regards, Laszlo Papp On Tue, Mar 8, 2011 at 12:47 AM, Laszlo Papp djsz...@archlinux.us wrote: On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. No idea whether or not that will be the solution, but It is hilarious, I cannot run the cmake ../ properly on the version 2.8.4... I mean it always enters an endless loop at random point, but all the time. I heard qemu+cmake is scary, but still How can I build the newest version of the cmake ? Cmake freezes all the time from the shadow build directory It is more than quite /pesky/. Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake hanging when run inside QEmu
1) What is the hackaround to install the newest version on arm ? 2) What is the final solution ? I think there are severe thread issues debug output contains almost the same information as the normal, not much addition... Should I open a bugreport instead with critical priority ? Put it mildly, it is completely useless on this arm. Best Regards, Laszlo Papp On Tue, Mar 8, 2011 at 12:55 AM, Eric Noulard eric.noul...@gmail.com wrote: Hi, I am starting a separate thread on this hanging issue. -- Forwarded message -- From: Laszlo Papp xx Date: 2011/3/8 Subject: Re: [CMake] CPack and RPM packages To: Eric Noulard eric.noul...@gmail.com Cc : CMake ML cmake@cmake.org 1st run: ca -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits Deadlock-like feeling on the user side except that I can kill the process - 2nd run: -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream Endless loop feeling again here. - 3rd run: cmake -DCMAKE_INSTALL_PREFIX=/usr .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator
Re: [CMake] CPack and RPM packages
I could not still build cmake.. But I did this modification locally you suggested and that is the output: CPack: Create package using RPM CPack: Install projects CPack: - Run preinstall target for: Gluon CPack: - Install project: Gluon CPack: Create package CPackRPM: Will use GENERATED spec file: /home/meego/gluon/build/_CPack_Packages/Linux/RPM/SPECS/gluon.spec CPack: - package: /home/meego/gluon/build/Gluon-0.71.0.rpm.rpm generated. It was a quite slow process after the spec file generation, but it seems to work. I do really hope someone can fix the arm - qemu - cmake thread hanging issues otherwise no idea how to get this functionality working officially... Best Regards, Laszlo PApp On Tue, Mar 8, 2011 at 12:53 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. No idea whether or not that will be the solution, but It is hilarious, I cannot run the cmake ../ properly on the version 2.8.4... I mean it always enters an endless loop at random point, but all the time. I heard qemu+cmake is scary, but still I did never use such combination, I let other comment on that one. How can I build the newest version of the cmake ? Cmake freezes all the time from the shadow build directory It is more than quite /pesky/. Concerning CPackRPM main issue, would try to 1) backup the CMake 2.8.3 , CPackRPM.cmake file 2) Edit CPackRPM.cmake file and change: %install if [ -e $RPM_BUILD_ROOT ]; then mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot/*\ $RPM_BUILD_ROOT else mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT fi to %install if [ -e $RPM_BUILD_ROOT ]; then rm -rf $RPM_BUILD_ROOT fi mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT then rerun cpack. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
On Sun, Mar 6, 2011 at 11:27 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/6 Laszlo Papp djsz...@archlinux.us: Mmh, my previous mail is blocked because the cpack.log is too big. http://djszapi.homelinux.net/rpmbuild.out http://djszapi.homelinux.net/rpmbuild.err http://djszapi.homelinux.net/cpack.log I do not quite understand what makes rpmbuild fail. Could you send me [a link to] the generated gluon.spec file. And could you show what are the INSTALL rules you use in the CMakeLists.txt for gluon_qtplayer and template.qml and Invaders_Assets_Material.gml http://djszapi.homelinux.net/gluon.spec http://djszapi.homelinux.net/template.qml.install http://djszapi.homelinux.net/qtplayer.install http://djszapi.homelinux.net/invaders_assets_material.gml.install = /usr/share/gluon/games/invaders.gluon/Assets/Invaders_Assets_Material.gml = under the invaders.gluon Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
By the way, you can find here the gluon-*.rpm packages built by the OBS: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ (unpack it with rpm2cpio src.rpm | cpio -idmv) Those spec files are done by a packager (human), thus not automated by a generator. I am not sure it helps with anything after all, but I try to provide as much as I can. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 2:33 AM, Laszlo Papp djsz...@archlinux.us wrote: On Sun, Mar 6, 2011 at 11:27 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/6 Laszlo Papp djsz...@archlinux.us: Mmh, my previous mail is blocked because the cpack.log is too big. http://djszapi.homelinux.net/rpmbuild.out http://djszapi.homelinux.net/rpmbuild.err http://djszapi.homelinux.net/cpack.log I do not quite understand what makes rpmbuild fail. Could you send me [a link to] the generated gluon.spec file. And could you show what are the INSTALL rules you use in the CMakeLists.txt for gluon_qtplayer and template.qml and Invaders_Assets_Material.gml http://djszapi.homelinux.net/gluon.spec http://djszapi.homelinux.net/template.qml.install http://djszapi.homelinux.net/qtplayer.install http://djszapi.homelinux.net/invaders_assets_material.gml.install = /usr/share/gluon/games/invaders.gluon/Assets/Invaders_Assets_Material.gml = under the invaders.gluon Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack and RPM packages
Restore the mailing list !
Well, first I cannot build :)
cd /home/meego/gluon/build/core /usr/bin/c++
-DMAKE_GLUON_CORE_LIB -Wall -Wno-psabi -Wall -g3 -ggdb -O0 -Wno-psabi
-fPIC -I/home/meego/gluon -I/home/meego/gluon/build
-I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtDeclarative
-I/usr/include/qt4/QtScriptTools -I/usr/include/qt4/QtDBus
-I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSql
-I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtNetwork
-I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtHelp
-I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest
-I/usr/include/qt4/QtScript -I/usr/include/qt4/QtSvg
-I/usr/include/qt4/QtGui -I/usr/share/qt4/mkspecs/default
-I/usr/include/qt4 -I/usr/include/qt4/QtCore
-I/home/meego/gluon/build/core -I/home/meego/gluon/core -o
CMakeFiles/GluonCore.dir/debughelper.cpp.o -c
/home/meego/gluon/core/debughelper.cpp
/tmp/cc9jVmy7.s: Assembler messages:
/tmp/cc9jVmy7.s:8659: Error: selected processor does not support `ldrex r4,[r3]'
/tmp/cc9jVmy7.s:8661: Error: selected processor does not support
`strex r5,r4,[r3]'
/tmp/cc9jVmy7.s:8711: Error: selected processor does not support `ldrex r4,[r3]'
/tmp/cc9jVmy7.s:8713: Error: selected processor does not support
`strex r5,r4,[r3]'
make[2]: *** [core/CMakeFiles/GluonCore.dir/debughelper.cpp.o] Error 1
make[2]: Leaving directory `/home/meego/gluon/build'
make[1]: *** [core/CMakeFiles/GluonCore.dir/all] Error 2
make[1]: Leaving directory `/home/meego/gluon/build'
make: *** [all] Error 2
I have been said by Thiago, it is because of the missing
-march=armv7-a option. It should be handled internally by cmake, can
you fix this bug, please and tell me the hackaround that I can use
until the release ?
Thank you in advance!
Best Regards,
Laszlo Papp
On Fri, Mar 4, 2011 at 9:50 PM, Eric Noulard eric.noul...@gmail.com wrote:
2011/3/4 Laszlo Papp djsz...@archlinux.us:
On Fri, Mar 4, 2011 at 3:05 PM, Eric Noulard eric.noul...@gmail.com wrote:
2011/3/4 Laszlo Papp djsz...@archlinux.us:
Hi,
Can I create an rpm package with cpack in order to not deal with spec
files ?
Yes you can CPackRPM is meant to do that:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29
The fastest path is to try:
$ cd /path/to/builddir
$ cpack -G RPM
Right, so you are saying it will create the rpm package with no spec
file reuqested.
Yes.
CPackRPM required some CPACK_RPM_ var def,
however most of them have default values.
The following command will give you the list:
$ cmake --help-module CPackRPM | grep -B 1 -A 1 Mandatory : YES
We did not need to put any debian/{changelog,rules,control} files
related implementation into the project so that to build a debian
package for arm with cpack.
However are you cross-compiling to arm or do you package natively on
arm-linux ?
Well not. I am developing on x86_64 in a cross-compilation way for
arm, N900, MeeGo.
http://wiki.meego.com/Developing_in_a_MeeGo_Environment
I do not know that setup and AFAIK CPackRPM has never been used
in a cross-compiling env. so like I said before give it a try and
tell me what happen.
CPack seems an easier way than OBS if one does not know how to write
spec files. That is why I started this whole thread whether or not
cpack is an easy way to generate rpm package for the N900 mobile -
like previously debian packages with cpack for the same mobile, but
Maemo5/Fremantle platform - or I need to make some other further
hackery.
Again CPackRPM has been tested in native environnement,
I don't know how it will behave in a chroot ARM Meego image.
Try it, and tell me what happen.
PS: I am not on the list, so please drop me into the 'CC' field.
This is usually a bad habitI am even surprised that you can post
without being on list.
You could subscribe to the list for the duration of your discussion
and then un-subscribe afterwards.
I subscribed only for the posting and unsubscribe then immediately
since I am not interested in other mails.
Seems awkward to me but OK, that's your choice :-]
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
On Sat, Mar 5, 2011 at 5:32 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/5 Laszlo Papp djsz...@archlinux.us: Well, first I cannot build :) I thought you were already using CPack for Deb package? If you never used a cross-compiling setup with CMake then read this first: http://www.cmake.org/Wiki/CMake_Cross_Compiling Meanwhile it can solves the problem, I think there should a developer awareless solution. Can you solve it in a smarter way in the future, please ? We have just discussed it on the #meego channel: 19:05 thiago djszapi: tell cmake to pass the -march=armv7-a flag to the compiler 19:05 thiago that's your answer 19:05 djszapi carstenek: also it was not fair sometimes on #meego.fi either. 19:05 -!- JPohlmann [~jannis@xfce/core-developer/JPohlmann] has joined #meego 19:05 -!- seg [~r...@75-63-28-213.lightspeed.irvnca.sbcglobal.net] has quit [Quit: Leaving] 19:05 djszapi thiago: yeah, toolchain file... 19:05 djszapi but the problem is that all the developers should aware of that. 19:05 thiago yes 19:05 thiago which means it's a toolchain problem 19:06 djszapi still not handy like in case sb :p 19:06 thiago or, more to the point: Qt has hardcoded instructions to use ARMv6 instructions 19:06 thiago qmake is configured to know to pass the flag 19:06 thiago everything else that uses Qt needs to know that too 19:07 djszapi yes, but I would be more glad about hiding it from the developer :o 19:07 thiago so teach cmake to extract the info from qmake and use it 19:08 djszapi so propose something to the cmake developers. 19:08 thiago yes, you should propose something to them Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
On Sat, Mar 5, 2011 at 5:32 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/5 Laszlo Papp djsz...@archlinux.us: Well, first I cannot build :) I thought you were already using CPack for Deb package? Yes, but from scratchbox and scratchbox passed the corrent toolchain arguments... By the way, I solved it with export CXXFLAGS in my ~/.bashrc file for now, thus I do not need this toolchain file right now. Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack and RPM packages
Hi,
Can I create an rpm package with cpack in order to not deal with spec files ?
We did not need to put any debian/{changelog,rules,control} files
related implementation into the project so that to build a debian
package for arm with cpack.
https://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/CMakeLists.txt#L162
Can it be done in a similar way to avoid the rpm spec file writing ?
Best Regards,
Laszlo Papp
PS: I am not on the list, so please drop me into the 'CC' field.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] config dependent defines
SET(CMAKE_CXX_FLAGS -Wall) SET(CMAKE_CXX_FLAGS_RELWITHDEBINFO -Wall -O2 -g) SET(CMAKE_CXX_FLAGS_RELEASE -Wall -O2) SET(CMAKE_CXX_FLAGS_DEBUG -Wall -g3 -ggdb -O0 CACHE STRING Debug options. FORCE) An example from my configuration. Best Regards, Laszlo Papp On Sat, Oct 16, 2010 at 9:38 AM, Jochen Wilhelmy j.wilhe...@arcor.de wrote: Hi! how do I define a macro (e.g. _DEBUG) only for the debug configuration? Thanks, -Jochen ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] QT4 and MOC
Hi, I wrote a helloworld class, source and header file for instance which is basically moc related class with Q_OBJECT macro. I do not know why I must use qt4_wrap_cpp(helloworld.h) beside qt4_automoc(helloworld.cpp). I always thought that qt4_automoc can recognize it. I would like to avoid the moc file include at the end of my source line. I would like to link that generated moc at linkage time, mostly. Thank you in advance. Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Environment Variable - /var
Hi, Is there such an environment variable, like in case autoconf: --localstatedir=DIR modifiable single-machine data [PREFIX/var] There are options like CMAKE_INSTALL_PREFIX, SYSCONF_INSTALL_DIR, but not this one. I can make an own one, I am just out of the curiosity whether there is an internal solution. Best Regards, Laszlo Papp ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Environment Variable - /var
It is not a KDE project ... Best Regards, Laszlo Papp On Tue, Sep 28, 2010 at 11:29 AM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Tuesday 28 September 2010, Laszlo Papp wrote: Hi, Is there such an environment variable, like in case autoconf: --localstatedir=DIR modifiable single-machine data [PREFIX/var] There are options like CMAKE_INSTALL_PREFIX, SYSCONF_INSTALL_DIR, but not this one. I can make an own one, I am just out of the curiosity whether there is an internal solution. SYSCONF_INSTALL_DIR is also not provided by cmake. In KDE we define a whole bunch of installation directories: http://api.kde.org/cmake/modules.html#module_FindKDE4Internal (the ones without KDE4_ prefix) Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Environment Variable - /var
The short answer is then: there is no such an option. Oki doki, thank you. Best Regards, Laszlo Papp On Tue, Sep 28, 2010 at 12:25 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Tuesday 28 September 2010, Laszlo Papp wrote: It is not a KDE project ... It was just meant as inspiration. And if you want you can of course use the code for the install dirs from FindKDE4Internal.cmake, it's BSD licensed. Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
