[CMake] SDL troubles on Mac OS X
Hi,
I'm building an application on Mac OS X and link the SDL libraries into
the app. Basically it all works fine (app runs, etc.), but if I want to
use the BundleUtilities to fix/include the SDL framework into the app
bundle I encounter errors. Problem is, that the references to the SDL
libraries in the executable already point to
@executable_path/../Frameworks/ although the SDL Frameworks are
not there (see below). BundleUtilities is then not able to find the SDL
Frameworks. In my opinion the references should point to
~/Library/Frameworks. I wonder why this app runs, but maybe Mac OS X
looks for other standard locations if it doesn't find the library. I
googled around but could only find one other post:
http://avidemux.org/admForum/viewtopic.php?id=5802
where it is mentioned that: However, cmake thinks that the
SDL.framework is already inside the bundle (and therefore doesn't copy
it), but cmake can't find it in the next step.
Is this a cmake bug, a FindSDL.cmake bug or is it just me :)
Thanks for any help,
Werner
More information. Here is what I do:
1) Download the SDL and SDL-Mixer Frameworks and copy them to
~/Library/Frameworks
2) Try to find them with
find_package(SDL REQUIRED)
include_directories(${SDL_INCLUDE_DIR})
find_package(SDL_mixer REQUIRED)
include_directories(${SDLMIXER_INCLUDE_DIR})
which also works ok:
SDL_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL.framework/Headers
SDL_LIBRARY =
/Users/smekal/Library/Frameworks/SDL.framework;-framework Cocoa
SDLMIXER_INCLUDE_DIR =
/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers
SDLMIXER_LIBRARY = /Users/smekal/Library/Frameworks/SDL_mixer.framework
3) Link them to my target:
target_link_libraries(
zct
${SDL_LIBRARY}
${SDLMIXER_LIBRARY}
${OPENGL_LIBRARIES}
)
4) Verbose compile (example):
[ 7%] Building CXX object CMakeFiles/zct.dir/src/game/app.cpp.o
/usr/bin/c++-mmacosx-version-min=10.5
-I/Users/smekal/Library/Frameworks/SDL.framework/Headers
-I/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers -Wall
-F/Users/smekal/Library/Frameworks -o
CMakeFiles/zct.dir/src/game/app.cpp.o -c
/Users/smekal/Development/zct/src/game/app.cpp
/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake -E
cmake_progress_report /Users/smekal/Development/zct/build/CMakeFiles 2
5) Verbose Link:
Linking CXX executable zct.app/Contents/MacOS/zct
/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake -E
cmake_link_script CMakeFiles/zct.dir/link.txt --verbose=1
/usr/bin/c++-mmacosx-version-min=10.5 -Wl,-search_paths_first
-headerpad_max_install_names CMakeFiles/zct.dir/src/game/app.cpp.o
CMakeFiles/zct.dir/src/game/being.cpp.o
CMakeFiles/zct.dir/src/game/controller.cpp.o
CMakeFiles/zct.dir/src/game/display.cpp.o
CMakeFiles/zct.dir/src/game/main.cpp.o
CMakeFiles/zct.dir/src/game/map.cpp.o
CMakeFiles/zct.dir/src/game/organizer.cpp.o
CMakeFiles/zct.dir/src/game/error.cpp.o
CMakeFiles/zct.dir/src/game/location.cpp.o
CMakeFiles/zct.dir/src/game/pathnode.cpp.o
CMakeFiles/zct.dir/src/game/point.cpp.o
CMakeFiles/zct.dir/src/game/tile.cpp.o
CMakeFiles/zct.dir/src/game/SDLMain.m.o -o zct.app/Contents/MacOS/zct
-F/Users/smekal/Library/Frameworks -framework SDL -framework Cocoa
-framework SDL_mixer -framework AGL -framework OpenGL
6) and if I look at the references with otool:
pico:build smekal$ otool -L zct.app/Contents/MacOS/zct
zct.app/Contents/MacOS/zct:
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 12.0.0)
@executable_path/../Frameworks/SDL_mixer.framework/Versions/A/SDL_mixer
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 111.1.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility
version 1.0.0, current version 32.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 476.19.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 949.54.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
(compatibility
Re: [CMake] How can I add gprof profiler to my CMakeLists.txt?
On Tue, 2009-12-15 at 12:08 +0800, Water Lin wrote: I want to use gprof to analyze my code. So I try to embed the -pg paramter for g++ in my CMakeLists.txt file. But after I embeded the -pg to my CMakeLists.txt like this: - add_definitions(-pg -march=pentium4 -msse3 -g) - and I recompile my code. There is no gprof output file. But when I use command like: $ g++ -pg to compile my code, gprof will generate a output file gmon.out. So, how can I enable gprof profiler in my CMakeLists.txt? Thanks Water Lin Hi Water Lin, From the g++ info files: `-pg' Generate extra code to write profile information suitable for the analysis program `gprof'. You must use this option when compiling the source files you want data about, and you must also use it when linking. So, you should use `-pg' both when compiling and linking. The command add_definitions() will only add this option during compilation. You should also add `-pg' to CMAKE_EXE_LINKER_FLAGS or to CMAKE_EXE_LINKER_FLAGS_[CMAKE_BUILD_TYPE], where CMAKE_BUILD_TYPE could be, e.g., `DEBUG'. HTH, Marcel Loose. ___ 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 tests only for make test
Hi Stefan, You found a typo. I'll fix that right away. Thanks. I've never tried to use the 'check' target with ctest, so I'm not sure whether it should work or not. Maybe someone else can comment on this. Best regards, Marcel Loose. On Mon, 2009-12-14 at 12:49 +0100, Dr. Stefan Sablatnög wrote: Hi Marcel, Thanks for the hint, the wiki states it should be CMAKE_TEST_COMMAND, I think this should be CMAKE_CTEST_COMMMAND? By the way is there a way to make ctest use this new check target instead of the default all in a continous testing configuration? (I tried ctest.exe --build-target check -D ContinuousStart -D ContinuousUpdate -D ContinuousConfigure -D ContinuousBuild -D ContinuousTest -D ContinuousSubmit And it didn't work as expected, but maybe I made a mistake) Thanks Stefan -Original Message- From: Marcel Loose [mailto:lo...@astron.nl] Sent: Freitag, 11. Dezember 2009 18:17 To: stefan.sablatn...@svox.com Cc: cmake@cmake.org Subject: Re: [CMake] Building tests only for make test Hi Stefan, I once dug into this issue, because I wanted to (more or less) emulate the GNU Autotools 'make check' feature. Have a look at http://www.cmake.org/Wiki/CMakeEmulateMakeCheck and see if that answers you question. Best regards, Marcel Loose. On Fri, 2009-12-11 at 15:53 +0100, Dr. Stefan Sablatnög wrote: Hi all, I face a (probably simple) problem: I want to build a project, that includes tests, but these should not be build on default, so I added EXCLUDE_FROM_ALL to the add_executable command. How can I force them to be built when testing ? (we test through make test and continuously via a ctest script) Is there a simple solution? Thanks in advance Stefan -- best regards Dr. Stefan Sablatnög email: stefan.sablatn...@svox.com phone: ++49 731 15239474 address: SVOX Ulm Magirus Deutz-Straße 16 89077 Ulm ___ 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] SDL troubles on Mac OS X
Hi
What is the install-name of SDL.framewor/SDL? What does
otool -L ~/Library/Frameworks/SDL.framework/SDL
tell you? I suspect it is something like
/Users/smekal/Library/Frameworks/SDL.framework/SDL:
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL
(compatibility version 1.0.0, current version 1.0.0)
right? The second line is the one the linker uses to embed as a reference into
your executable. The linker doesn't use it's actual location, but the library's
install name.
Not sure what's going wrong in the CMake part, though...
IMHO FindSDL.cmake is buggy. The variable SDL_LIBRARY (and all its siblings)
should only contain the framework, not Cocoa. Another variable, SDL_LIBRARIES
(which should be uncached) should then contain the value of SDL_LIBRARY and all
other required supporting libraries, such as Cocoa on OS X.
For now, what you can do is manually install the SDL framework using
install(DIRECTORY ...) and the first list element of SDL_LIBRARY.
HTH
Michael
On 15. Dec, 2009, at 8:51 , Werner Smekal wrote:
Hi,
I'm building an application on Mac OS X and link the SDL libraries into the
app. Basically it all works fine (app runs, etc.), but if I want to use the
BundleUtilities to fix/include the SDL framework into the app bundle I
encounter errors. Problem is, that the references to the SDL libraries in the
executable already point to @executable_path/../Frameworks/ although
the SDL Frameworks are not there (see below). BundleUtilities is then not
able to find the SDL Frameworks. In my opinion the references should point to
~/Library/Frameworks. I wonder why this app runs, but maybe Mac OS X looks
for other standard locations if it doesn't find the library. I googled around
but could only find one other post:
http://avidemux.org/admForum/viewtopic.php?id=5802
where it is mentioned that: However, cmake thinks that the SDL.framework
is already inside the bundle (and therefore doesn't copy it), but cmake can't
find it in the next step.
Is this a cmake bug, a FindSDL.cmake bug or is it just me :)
Thanks for any help,
Werner
More information. Here is what I do:
1) Download the SDL and SDL-Mixer Frameworks and copy them to
~/Library/Frameworks
2) Try to find them with
find_package(SDL REQUIRED)
include_directories(${SDL_INCLUDE_DIR})
find_package(SDL_mixer REQUIRED)
include_directories(${SDLMIXER_INCLUDE_DIR})
which also works ok:
SDL_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL.framework/Headers
SDL_LIBRARY = /Users/smekal/Library/Frameworks/SDL.framework;-framework Cocoa
SDLMIXER_INCLUDE_DIR =
/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers
SDLMIXER_LIBRARY = /Users/smekal/Library/Frameworks/SDL_mixer.framework
3) Link them to my target:
target_link_libraries(
zct
${SDL_LIBRARY}
${SDLMIXER_LIBRARY}
${OPENGL_LIBRARIES}
)
4) Verbose compile (example):
[ 7%] Building CXX object CMakeFiles/zct.dir/src/game/app.cpp.o
/usr/bin/c++-mmacosx-version-min=10.5
-I/Users/smekal/Library/Frameworks/SDL.framework/Headers
-I/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers -Wall
-F/Users/smekal/Library/Frameworks -o CMakeFiles/zct.dir/src/game/app.cpp.o
-c /Users/smekal/Development/zct/src/game/app.cpp
/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake -E
cmake_progress_report /Users/smekal/Development/zct/build/CMakeFiles 2
5) Verbose Link:
Linking CXX executable zct.app/Contents/MacOS/zct
/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake -E
cmake_link_script CMakeFiles/zct.dir/link.txt --verbose=1
/usr/bin/c++-mmacosx-version-min=10.5 -Wl,-search_paths_first
-headerpad_max_install_names CMakeFiles/zct.dir/src/game/app.cpp.o
CMakeFiles/zct.dir/src/game/being.cpp.o
CMakeFiles/zct.dir/src/game/controller.cpp.o
CMakeFiles/zct.dir/src/game/display.cpp.o
CMakeFiles/zct.dir/src/game/main.cpp.o CMakeFiles/zct.dir/src/game/map.cpp.o
CMakeFiles/zct.dir/src/game/organizer.cpp.o
CMakeFiles/zct.dir/src/game/error.cpp.o
CMakeFiles/zct.dir/src/game/location.cpp.o
CMakeFiles/zct.dir/src/game/pathnode.cpp.o
CMakeFiles/zct.dir/src/game/point.cpp.o
CMakeFiles/zct.dir/src/game/tile.cpp.o
CMakeFiles/zct.dir/src/game/SDLMain.m.o -o zct.app/Contents/MacOS/zct
-F/Users/smekal/Library/Frameworks -framework SDL -framework Cocoa -framework
SDL_mixer -framework AGL -framework OpenGL
6) and if I look at the references with otool:
pico:build smekal$ otool -L zct.app/Contents/MacOS/zct
zct.app/Contents/MacOS/zct:
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 12.0.0)
@executable_path/../Frameworks/SDL_mixer.framework/Versions/A/SDL_mixer
(compatibility
Re: [CMake] Embedding up-to-date version info in built library
Hi, add_custom_target(update_version COMMAND echo updating) add_library(mylib version.c) add_dependencies(mylib update_version) We had exactly this configuration for months and the lib was rebuilt always... but now that you affirm that it /should/ work better, I had a deeper look again. The actual cause for the rebuild is the compile time embedded in version.c. The updater script doesn't check dependencies. It just computes a new version.c and that new version.c will always be different from the previous one because the time changes. Unless we decide to omit that time info, we need to make updates of version.c dependent on whether the library should be rebuild for other reasons. So, we really need to reconsider whether the time info in that file makes much sense... Thanks for your help! Kolja ___ 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] (no subject)
Hi! What is the status of scripts enabling precompiled headers for gcc/visual studio? I've tried out PCHSupport_26 from http://www.cmake.org/Bug/view.php?id=1260 but I couldn't get it to work. Does anyone have any up to date script that works with 2.8? Johan __ Ta semester! - sök efter resor hos Kelkoo. Jämför pris på flygbiljetter och hotellrum här: http://www.kelkoo.se/c-169901-resor-biljetter.html?partnerId=96914052___ 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] SDL troubles on Mac OS X
Hi Michael,
On 12/15/09 9:58 AM, Michael Wild wrote:
Hi
What is the install-name of SDL.framewor/SDL? What does
otool -L ~/Library/Frameworks/SDL.framework/SDL
tell you? I suspect it is something like
/Users/smekal/Library/Frameworks/SDL.framework/SDL:
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL
(compatibility version 1.0.0, current version 1.0.0)
right? The second line is the one the linker uses to embed as a reference into
your executable. The linker doesn't use it's actual location, but the library's
install name.
Yes that's right. It was actually 5 minutes after I wrote my email, that
I remembered somewhere back in my head, that the library itself has this
reference, so this explains, why the executable also has this reference.
Not sure what's going wrong in the CMake part, though...
I assume BundleUtilties uses this reference to copy the libraries into
the app - if the library itself has a wrong reference it's not able to
find the library, or?
IMHO FindSDL.cmake is buggy. The variable SDL_LIBRARY (and all its siblings)
should only contain the framework, not Cocoa. Another variable, SDL_LIBRARIES
(which should be uncached) should then contain the value of SDL_LIBRARY and all
other required supporting libraries, such as Cocoa on OS X.
For now, what you can do is manually install the SDL framework using
install(DIRECTORY ...) and the first list element of SDL_LIBRARY.
Thanks, that is what I'm doing right now and this works perfectly. Also
the default XCode project provided by the SDL people does the same -
copying the framework directly into the bundle (without otooling and
install_name_tooling around).
HTH
Definitely!
Thanks,
Werner
Michael
On 15. Dec, 2009, at 8:51 , Werner Smekal wrote:
Hi,
I'm building an application on Mac OS X and link the SDL libraries into the app.
Basically it all works fine (app runs, etc.), but if I want to use the BundleUtilities to
fix/include the SDL framework into the app bundle I encounter errors. Problem is, that
the references to the SDL libraries in the executable already point to
@executable_path/../Frameworks/ although the SDL Frameworks are not there
(see below). BundleUtilities is then not able to find the SDL Frameworks. In my opinion
the references should point to ~/Library/Frameworks. I wonder why this app runs, but
maybe Mac OS X looks for other standard locations if it doesn't find the library. I
googled around but could only find one other post:
http://avidemux.org/admForum/viewtopic.php?id=5802
where it is mentioned that: However, cmake thinks that the SDL.framework is
already inside the bundle (and therefore doesn't copy it), but cmake can't find it in the next
step.
Is this a cmake bug, a FindSDL.cmake bug or is it just me :)
Thanks for any help,
Werner
More information. Here is what I do:
1) Download the SDL and SDL-Mixer Frameworks and copy them to
~/Library/Frameworks
2) Try to find them with
find_package(SDL REQUIRED)
include_directories(${SDL_INCLUDE_DIR})
find_package(SDL_mixer REQUIRED)
include_directories(${SDLMIXER_INCLUDE_DIR})
which also works ok:
SDL_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL.framework/Headers
SDL_LIBRARY = /Users/smekal/Library/Frameworks/SDL.framework;-framework Cocoa
SDLMIXER_INCLUDE_DIR =
/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers
SDLMIXER_LIBRARY = /Users/smekal/Library/Frameworks/SDL_mixer.framework
3) Link them to my target:
target_link_libraries(
zct
${SDL_LIBRARY}
${SDLMIXER_LIBRARY}
${OPENGL_LIBRARIES}
)
4) Verbose compile (example):
[ 7%] Building CXX object CMakeFiles/zct.dir/src/game/app.cpp.o
/usr/bin/c++-mmacosx-version-min=10.5
-I/Users/smekal/Library/Frameworks/SDL.framework/Headers
-I/Users/smekal/Library/Frameworks/SDL_mixer.framework/Headers -Wall
-F/Users/smekal/Library/Frameworks -o CMakeFiles/zct.dir/src/game/app.cpp.o -c
/Users/smekal/Development/zct/src/game/app.cpp
/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake -E
cmake_progress_report /Users/smekal/Development/zct/build/CMakeFiles 2
5) Verbose Link:
Linking CXX executable zct.app/Contents/MacOS/zct
/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake -E
cmake_link_script CMakeFiles/zct.dir/link.txt --verbose=1
/usr/bin/c++-mmacosx-version-min=10.5 -Wl,-search_paths_first
-headerpad_max_install_names CMakeFiles/zct.dir/src/game/app.cpp.o
CMakeFiles/zct.dir/src/game/being.cpp.o
CMakeFiles/zct.dir/src/game/controller.cpp.o
CMakeFiles/zct.dir/src/game/display.cpp.o
CMakeFiles/zct.dir/src/game/main.cpp.o CMakeFiles/zct.dir/src/game/map.cpp.o
CMakeFiles/zct.dir/src/game/organizer.cpp.o
CMakeFiles/zct.dir/src/game/error.cpp.o
CMakeFiles/zct.dir/src/game/location.cpp.o
CMakeFiles/zct.dir/src/game/pathnode.cpp.o
CMakeFiles/zct.dir/src/game/point.cpp.o CMakeFiles/zct.dir/src/game/tile.cpp.o
Re: [CMake] CPack DragNDrop generator documentation
Bump On 27. Oct, 2009, at 14:28 , Michael Wild wrote: Hi all The CPack DragNDrop generator is completely undocumented. I created http://www.cmake.org/Bug/view.php?id=9782 to report this and attached a patch which adds some documentation for the variables used in the generator. I hope I didn't misunderstand the meaning of the variables. 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
[CMake] CMake ParaView parallel testing on windows
Whilst setting up a dashboard for ParaView using windows + MPI, I noticed that
a number of tests always fail because the executable is not found. I find that
CMake code such as this
ADD_TEST(ParallelIso-image
${VTK_MPIRUN_EXE} ${VTK_MPI_PRENUMPROC_FLAGS} ${VTK_MPI_NUMPROC_FLAG} 2
${VTK_MPI_PREFLAGS}
${CXX_TEST_PATH}/${RelWithDebInfo}/ParallelIsoTest
-D ${VTK_DATA_ROOT}
-T ${VTK_BINARY_DIR}/Testing/Temporary
-V Baseline/Parallel/ParallelIso.cxx.png
${VTK_MPI_POSTFLAGS}
)
does not get the executable path for the actual test set correctly to
build/bin/RelWithDebInfo/ParallelIsoTest but only to build/bin/ParallelIsoTest
I tried adding ${CMAKE_CFG_INTDIR}
${CXX_TEST_PATH}/${CMAKE_CFG_INTDIR}/ParallelIsoTest
and then running
ctest -C RelWithDebInfo -V -R ParallelIso
but the output is
270: Test command: C:\Program Files\MPICH2\bin\mpiexec.exe -np 2 -localonly
-channel mt D:/cmakebuild/pv-shared/bin/$(OutDir)/ParallelIsoT
est -D H:/VTKData -T D:/cmakebuild/pv-shared/VTK/Testing/Temporary -V
Baseline/Parallel/ParallelIso.cxx.png
where we have $(OutDir) rather than RelWithDebInfo.
Is there a correct way to do this? I had a look at previous dashboards and see
that there is no regular windows + Mpi + Parallel testing done for paraview
(and now I know why!)
Thanks for any pointers (My guess is that the ADD_TEST() command is internally
substituting the bin dir for the first executable, but this is not applicable
for the mpirun version)
JB
--
John Biddiscombe, email:biddisco @ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
___
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 ParaView parallel testing on windows
Erratum : I pasted the wrong version in to my earlier message, the offending
CMake line is
(the existing code) ${CXX_TEST_PATH}/ParallelIsoTest
and
${CXX_TEST_PATH}/${CMAKE_INTDIR}/ParallelIsoTest
is what I tried but is replaced with $(OutDir)
-Original Message-
From: paraview-developers-boun...@paraview.org [mailto:paraview-developers-
boun...@paraview.org] On Behalf Of Biddiscombe, John A.
Sent: 15 December 2009 11:31
To: paraview-develop...@paraview.org
Cc: cmake@cmake.org
Subject: [Paraview-developers] CMake ParaView parallel testing on windows
Whilst setting up a dashboard for ParaView using windows + MPI, I noticed
that a number of tests always fail because the executable is not found. I
find that CMake code such as this
ADD_TEST(ParallelIso-image
${VTK_MPIRUN_EXE} ${VTK_MPI_PRENUMPROC_FLAGS} ${VTK_MPI_NUMPROC_FLAG} 2
${VTK_MPI_PREFLAGS}
${CXX_TEST_PATH}/${RelWithDebInfo}/ParallelIsoTest
-D ${VTK_DATA_ROOT}
-T ${VTK_BINARY_DIR}/Testing/Temporary
-V Baseline/Parallel/ParallelIso.cxx.png
${VTK_MPI_POSTFLAGS}
)
does not get the executable path for the actual test set correctly to
build/bin/RelWithDebInfo/ParallelIsoTest but only to
build/bin/ParallelIsoTest
I tried adding ${CMAKE_CFG_INTDIR}
${CXX_TEST_PATH}/${CMAKE_CFG_INTDIR}/ParallelIsoTest
and then running
ctest -C RelWithDebInfo -V -R ParallelIso
but the output is
270: Test command: C:\Program Files\MPICH2\bin\mpiexec.exe -np 2 -
localonly -channel mt D:/cmakebuild/pv-shared/bin/$(OutDir)/ParallelIsoT
est -D H:/VTKData -T D:/cmakebuild/pv-shared/VTK/Testing/Temporary -V
Baseline/Parallel/ParallelIso.cxx.png
where we have $(OutDir) rather than RelWithDebInfo.
Is there a correct way to do this? I had a look at previous dashboards and
see that there is no regular windows + Mpi + Parallel testing done for
paraview (and now I know why!)
Thanks for any pointers (My guess is that the ADD_TEST() command is
internally substituting the bin dir for the first executable, but this is
not applicable for the mpirun version)
JB
--
John Biddiscombe, email:biddisco @ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
___
Paraview-developers mailing list
paraview-develop...@paraview.org
http://public.kitware.com/mailman/listinfo/paraview-developers
___
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] Linking to .a files under AIX
Hello
I have a problem with linking to dynamic libraries on AIX:
A target (target_a) needs to link to a external dynamic library
(xerces) that I use find_library() to find. Something along these
lines:
find_library(XERCES
NAMES libxerces-c2_7_0.a
PATHS ${LIB_PATH}
)
add_executable(target_a
foo.c
)
target_link_libraries(target_a
library_b
${XERCES}
)
set_target_properties(target_a PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ../../bin/
)
(It is library_b that is the real user of xerces) The problem is that
when linking target_a the path to xerces is given in relation to the
buildspace (i.e ../../../external_libs/xexes/libxerces-c2_7_0.a )
which becomes embeded into the binary (visable when using dump) and
when the binary is moved to the target directory the relative path is
no longer valid :-( ).
I think that some of the problem is related to that .a files can be
both static and dynamic on AIX and when cmake compliles the command
line for cc it thinks that it is a static lib but cc/ld concludes that
it is a dynamic library and makes its magic to embed the path.
I have tried various ways to resolve the problem:
* I create an imported target for xerces the I linked to.
* I have made tried to link library_b to xerces (both using ${XERCES}
and using the imported target)
* Giving extra linkflags -L and -l when building the target
the last one works, but it feels like a hack.
I'm hoping someone have found a solution to the problems that don't
involves setting linkflags on all our targets and are willing to share
it :-)
thanks in advance
/jp
--
jens persson
j...@persson.cx
Mäster Olofsväg 24
S-224 66 LUND;SWEDEN
___
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] (no subject)
On Tue, Dec 15, 2009 at 4:13 AM, Johan Knutzen knutzen_joh...@yahoo.se wrote:
Hi!
What is the status of scripts enabling precompiled headers for gcc/visual
studio? I've tried out PCHSupport_26 from
http://www.cmake.org/Bug/view.php?id=1260 but I couldn't get it to work. Does
anyone have any up to date script that works with 2.8?
I have not bothered in linux since I can use ccache to speed up
builds. In windows I use the following macro:
#
macro( SM_PCH_SUPPORT ProjectName )
if (MSVC)
if (USE_MSVC_PCH)
set_source_files_properties(${ProjectName}PCH.cxx
PROPERTIES
COMPILE_FLAGS /Yc${ProjectName}PCH.h
)
foreach( src_file ${${ProjectName}_SRCS} )
set_source_files_properties(
${src_file}
PROPERTIES
COMPILE_FLAGS /Yu${ProjectName}PCH.h
)
endforeach( src_file ${${ProjectName}_SRCS} )
list(APPEND ${ProjectName}_SRCS ${ProjectName}PCH.cxx)
list(APPEND ${ProjectName}_EXT_HDRS ${ProjectName}PCH.h)
endif(USE_MSVC_PCH)
endif (MSVC)
endmacro (SM_PCH_SUPPORT)
#
And this requires me to have my source variable named ${ProjectName}_SRCS
And my header variable to be named ${ProjectName}_EXT_HDRS
and the following files to exist in the same folder as the CMakeLists.txt
${ProjectName}PCH.cxx ${ProjectName}PCH.h
I generally put this macro in the main project before my first
add_subdirectory so that all subprojects can use the macro as well.
Then to activate this in a project. I place the macro call after I
define the list variables.
SET( smDataManagement_SRCS
./src/smData.cxx
./src/smDataOperation.cxx
./src/smCounterBalanceOperation.cxx
)
SET( smDataManagement_EXT_HDRS
./Include/smData.h
./Include/smDataOperation.h
./Include/smCounterBalanceOperation.h
)
SET( smDataManagement_MOC_HDRS
)
# some .ui files
SET( smDataManagement_UIS
)
# and finally an resource file
SET( smDataManagement_RCS
)
SET( smDataManagement_INT_HDRS
)
#Add precompiled header support
SM_PCH_SUPPORT(smDataManagement)
This works in cmake-2.6 and above.
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
Re: [CMake] Linking to .a files under AIX
Hello again!
I found my error and have fixed it, documenting it here to aid the
next person encountering it.
I need to override the linker flags to remove the -bexpall flag and
doing so I had accidentaly removed the -bnoipath option to so changing
the lines:
SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS -Wl,-brtl)
SET(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS -Wl,-brtl)
to
SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS -Wl,-brtl,-bnoipath)
SET(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS -Wl,-brtl,-bnoipath)
solved the problem.
Mea culpa
/jp
2009/12/15 jens persson j...@persson.cx:
Hello
I have a problem with linking to dynamic libraries on AIX:
A target (target_a) needs to link to a external dynamic library
(xerces) that I use find_library() to find. Something along these
lines:
find_library(XERCES
NAMES libxerces-c2_7_0.a
PATHS ${LIB_PATH}
)
add_executable(target_a
foo.c
)
target_link_libraries(target_a
library_b
${XERCES}
)
set_target_properties(target_a PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ../../bin/
)
(It is library_b that is the real user of xerces) The problem is that
when linking target_a the path to xerces is given in relation to the
buildspace (i.e ../../../external_libs/xexes/libxerces-c2_7_0.a )
which becomes embeded into the binary (visable when using dump) and
when the binary is moved to the target directory the relative path is
no longer valid :-( ).
I think that some of the problem is related to that .a files can be
both static and dynamic on AIX and when cmake compliles the command
line for cc it thinks that it is a static lib but cc/ld concludes that
it is a dynamic library and makes its magic to embed the path.
I have tried various ways to resolve the problem:
* I create an imported target for xerces the I linked to.
* I have made tried to link library_b to xerces (both using ${XERCES}
and using the imported target)
* Giving extra linkflags -L and -l when building the target
the last one works, but it feels like a hack.
I'm hoping someone have found a solution to the problems that don't
involves setting linkflags on all our targets and are willing to share
it :-)
thanks in advance
/jp
--
jens persson
j...@persson.cx
Mäster Olofsväg 24
S-224 66 LUND;SWEDEN
--
jens persson
j...@persson.cx
Mäster Olofsväg 24
S-224 66 LUND;SWEDEN
___
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 ParaView parallel testing on windows
How about something like this:
${EXECUTABLE_OUTPUT_PATH}/\${CTEST_CONFIGURATION_TYPE}/
MyTestExecutable
Then CTEST_CONFIGURATION_TYPE is expanded at ctest time and the -C
flag to ctest determines which configuration to use.
Clint
On Dec 15, 2009, at 4:29 AM, Biddiscombe, John A. wrote:
Erratum : I pasted the wrong version in to my earlier message, the
offending CMake line is
(the existing code) ${CXX_TEST_PATH}/ParallelIsoTest
and
${CXX_TEST_PATH}/${CMAKE_INTDIR}/ParallelIsoTest
is what I tried but is replaced with $(OutDir)
-Original Message-
From: paraview-developers-boun...@paraview.org [mailto:paraview-
developers-
boun...@paraview.org] On Behalf Of Biddiscombe, John A.
Sent: 15 December 2009 11:31
To: paraview-develop...@paraview.org
Cc: cmake@cmake.org
Subject: [Paraview-developers] CMake ParaView parallel testing on
windows
Whilst setting up a dashboard for ParaView using windows + MPI, I
noticed
that a number of tests always fail because the executable is not
found. I
find that CMake code such as this
ADD_TEST(ParallelIso-image
${VTK_MPIRUN_EXE} ${VTK_MPI_PRENUMPROC_FLAGS} $
{VTK_MPI_NUMPROC_FLAG} 2
${VTK_MPI_PREFLAGS}
${CXX_TEST_PATH}/${RelWithDebInfo}/ParallelIsoTest
-D ${VTK_DATA_ROOT}
-T ${VTK_BINARY_DIR}/Testing/Temporary
-V Baseline/Parallel/ParallelIso.cxx.png
${VTK_MPI_POSTFLAGS}
)
does not get the executable path for the actual test set correctly to
build/bin/RelWithDebInfo/ParallelIsoTest but only to
build/bin/ParallelIsoTest
I tried adding ${CMAKE_CFG_INTDIR}
${CXX_TEST_PATH}/${CMAKE_CFG_INTDIR}/ParallelIsoTest
and then running
ctest -C RelWithDebInfo -V -R ParallelIso
but the output is
270: Test command: C:\Program Files\MPICH2\bin\mpiexec.exe -np 2 -
localonly -channel mt D:/cmakebuild/pv-shared/bin/$(OutDir)/
ParallelIsoT
est -D H:/VTKData -T D:/cmakebuild/pv-shared/VTK/Testing/Temporary -V
Baseline/Parallel/ParallelIso.cxx.png
where we have $(OutDir) rather than RelWithDebInfo.
Is there a correct way to do this? I had a look at previous
dashboards and
see that there is no regular windows + Mpi + Parallel testing done
for
paraview (and now I know why!)
Thanks for any pointers (My guess is that the ADD_TEST() command is
internally substituting the bin dir for the first executable, but
this is
not applicable for the mpirun version)
JB
--
John Biddiscombe,email:biddisco @ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91)
610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91)
610.82.82
___
Paraview-developers mailing list
paraview-develop...@paraview.org
http://public.kitware.com/mailman/listinfo/paraview-developers
___
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] SDL troubles on Mac OS X
On Dec 15, 2009, at 2:31 AM, Werner Smekal wrote:
Hi Michael,
On 12/15/09 9:58 AM, Michael Wild wrote:
Hi
What is the install-name of SDL.framewor/SDL? What does
otool -L ~/Library/Frameworks/SDL.framework/SDL
tell you? I suspect it is something like
/Users/smekal/Library/Frameworks/SDL.framework/SDL:
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL
(compatibility version 1.0.0, current version 1.0.0)
right? The second line is the one the linker uses to embed as a
reference into your executable. The linker doesn't use it's actual
location, but the library's install name.
Yes that's right. It was actually 5 minutes after I wrote my email,
that I remembered somewhere back in my head, that the library
itself has this reference, so this explains, why the executable
also has this reference.
Not sure what's going wrong in the CMake part, though...
I assume BundleUtilties uses this reference to copy the libraries
into the app - if the library itself has a wrong reference it's
not able to find the library, or?
BundleUtilities/GetPrerequisites will print a warning message if the
framework's id isn't where its really at.
But a few lines down after printing that warning message, it checks
to see if it can find it in ~/Library/Frameworks.
So I suspect its working, but the messages are misleading.
Perhaps the SDL installation shouldn't be setting framework ids like
that.
Clint
IMHO FindSDL.cmake is buggy. The variable SDL_LIBRARY (and all its
siblings) should only contain the framework, not Cocoa. Another
variable, SDL_LIBRARIES (which should be uncached) should then
contain the value of SDL_LIBRARY and all other required supporting
libraries, such as Cocoa on OS X.
For now, what you can do is manually install the SDL framework
using install(DIRECTORY ...) and the first list element of
SDL_LIBRARY.
Thanks, that is what I'm doing right now and this works perfectly.
Also the default XCode project provided by the SDL people does the
same - copying the framework directly into the bundle (without
otooling and install_name_tooling around).
HTH
Definitely!
Thanks,
Werner
Michael
On 15. Dec, 2009, at 8:51 , Werner Smekal wrote:
Hi,
I'm building an application on Mac OS X and link the SDL
libraries into the app. Basically it all works fine (app runs,
etc.), but if I want to use the BundleUtilities to fix/include
the SDL framework into the app bundle I encounter errors. Problem
is, that the references to the SDL libraries in the executable
already point to @executable_path/../Frameworks/ although
the SDL Frameworks are not there (see below). BundleUtilities is
then not able to find the SDL Frameworks. In my opinion the
references should point to ~/Library/Frameworks. I wonder why
this app runs, but maybe Mac OS X looks for other standard
locations if it doesn't find the library. I googled around but
could only find one other post:
http://avidemux.org/admForum/viewtopic.php?id=5802
where it is mentioned that: However, cmake thinks that the
SDL.framework is already inside the bundle (and therefore doesn't
copy it), but cmake can't find it in the next step.
Is this a cmake bug, a FindSDL.cmake bug or is it just me :)
Thanks for any help,
Werner
More information. Here is what I do:
1) Download the SDL and SDL-Mixer Frameworks and copy them to ~/
Library/Frameworks
2) Try to find them with
find_package(SDL REQUIRED)
include_directories(${SDL_INCLUDE_DIR})
find_package(SDL_mixer REQUIRED)
include_directories(${SDLMIXER_INCLUDE_DIR})
which also works ok:
SDL_INCLUDE_DIR = /Users/smekal/Library/Frameworks/SDL.framework/
Headers
SDL_LIBRARY = /Users/smekal/Library/Frameworks/SDL.framework;-
framework Cocoa
SDLMIXER_INCLUDE_DIR = /Users/smekal/Library/Frameworks/
SDL_mixer.framework/Headers
SDLMIXER_LIBRARY = /Users/smekal/Library/Frameworks/
SDL_mixer.framework
3) Link them to my target:
target_link_libraries(
zct
${SDL_LIBRARY}
${SDLMIXER_LIBRARY}
${OPENGL_LIBRARIES}
)
4) Verbose compile (example):
[ 7%] Building CXX object CMakeFiles/zct.dir/src/game/app.cpp.o
/usr/bin/c++-mmacosx-version-min=10.5 -I/Users/smekal/Library/
Frameworks/SDL.framework/Headers -I/Users/smekal/Library/
Frameworks/SDL_mixer.framework/Headers -Wall -F/Users/smekal/
Library/Frameworks -o CMakeFiles/zct.dir/src/game/app.cpp.o -c /
Users/smekal/Development/zct/src/game/app.cpp
/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake -
E cmake_progress_report /Users/smekal/Development/zct/build/
CMakeFiles 2
5) Verbose Link:
Linking CXX executable zct.app/Contents/MacOS/zct
/Users/smekal/Applications/CMake 2.8-0.app/Contents/bin/cmake -
E cmake_link_script CMakeFiles/zct.dir/link.txt --verbose=1
/usr/bin/c++-mmacosx-version-min=10.5 -Wl,-search_paths_first
-headerpad_max_install_names
Re: [CMake] SDL troubles on Mac OS X
On Dec 15, 2009, at 10:03 AM, Clinton Stimpson wrote: On Dec 15, 2009, at 2:31 AM, Werner Smekal wrote: Hi Michael, On 12/15/09 9:58 AM, Michael Wild wrote: Hi What is the install-name of SDL.framewor/SDL? What does otool -L ~/Library/Frameworks/SDL.framework/SDL tell you? I suspect it is something like /Users/smekal/Library/Frameworks/SDL.framework/SDL: @executable_path/../Frameworks/SDL.framework/Versions/A/SDL (compatibility version 1.0.0, current version 1.0.0) right? The second line is the one the linker uses to embed as a reference into your executable. The linker doesn't use it's actual location, but the library's install name. Yes that's right. It was actually 5 minutes after I wrote my email, that I remembered somewhere back in my head, that the library itself has this reference, so this explains, why the executable also has this reference. Not sure what's going wrong in the CMake part, though... I assume BundleUtilties uses this reference to copy the libraries into the app - if the library itself has a wrong reference it's not able to find the library, or? BundleUtilities/GetPrerequisites will print a warning message if the framework's id isn't where its really at. But a few lines down after printing that warning message, it checks to see if it can find it in ~/Library/Frameworks. So I suspect its working, but the messages are misleading. Perhaps the SDL installation shouldn't be setting framework ids like that. Clint I think the SDL developers are just being a bit too slick. They are setting up SDL for Xcode development where typically you would link to the SDL and then have a Copy Files Phase where you copy the framework into the Application Bundle that resides in the build directory. All the tutorials regarding Xcode and embedding frameworks have you do it this way). So the SDL folks made the reasonable assumption that one would be using Xcode on OS X and they could do it this way. This probably explains why OS X developers coming to CMake keep wanting to copy the framework into the App bundle at build time and not wait for Install time like CMake basically has us doing now. Just a different way of accomplishing the same thing but it does come with caveats. The OP will probably have to add a custom_command to copy the SDL framework into the .app bundle after building. Then the OP should verify that when the .app package gets copied to the install location that the entire .app package is copied, which will bring with it the SDL framework and so BundleUtilities will just basically skip past the SDL fixup/copy because it is already correct. Just my thoughts. _ Mike Jackson mike.jack...@bluequartz.net BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio ___ 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 DragNDrop generator documentation
Fixed in CVS HEAD of CMake... Thanks for your patience, David On Tue, Dec 15, 2009 at 4:50 AM, Michael Wild them...@gmail.com wrote: Bump On 27. Oct, 2009, at 14:28 , Michael Wild wrote: Hi all The CPack DragNDrop generator is completely undocumented. I created http://www.cmake.org/Bug/view.php?id=9782 to report this and attached a patch which adds some documentation for the variables used in the generator. I hope I didn't misunderstand the meaning of the variables. 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 ___ 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] Cannot find source file.
I would contend that this should be a warning vs. an error, which prevents generation. Cheers, Tim On Thu, Dec 10, 2009 at 3:18 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 10 December 2009, Tyler Roscoe wrote: On Thu, Dec 10, 2009 at 02:14:28PM -0600, Tim St. Clair wrote: Do all files *have* to be present during generation? Or is there some lazy evaluation? Look at the GENERATED property for source files. The file it is looking for is one of many gen'd files. It would be a pain if I had to update all the command outputs in order to create the deps. Having well-constructed links between command outputs and dependencies sounds like a really good idea to me. Yes, it's even necessary. If your add_custom_commands() don't list all the files they generate and if not all generated files are listed as sources for the target which needs them then the dependencies will be incomplete, and builds (or at least parallel builds) will break. Alex -- Cheers, Timothy St. Clair ___ 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] SDL troubles on Mac OS X
I think the SDL developers are just being a bit too slick. They are setting up SDL for Xcode development where typically you would link to the SDL and then have a Copy Files Phase where you copy the framework into the Application Bundle that resides in the build directory. Its a cultural difference also. Mac developers think of creating the complete application as part of the build process. A Mac app generally contains everything it needs so you can just drag it to another machine and run it. I would never want a half-baked app that is wired into my machine. Copying the libraries into the app isn't part of installation, its part of building... Copying the app somewhere else is installation i.e. a no-op as far as my build process is concerned. G ___ 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 .qrc file modifications require two builds
If I modify my .qrc file, the first build regenerates the cxx output
file, but the cxx file itself is not compiled and linked in until I
build again.
Is there a way to add an additional dependency to allow the system to
realize that the cxx file needs a rebuild on the first pass?
The CMake script in question looks more or less like:
FILE (GLOB my_RESOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} res/*.qrc )
QT4_ADD_RESOURCES( my_RESOURCES_SOURCES ${my_RESOURCES} )
...
ADD_EXECUTABLE( myApp MACOSX_BUNDLE ${mySrcs} ${my_RESOURCES_SOURCES} )
Is there something else I should be doing? Building under Xcode.
Thanks!
G
___
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 .qrc file modifications require two builds
The CMake script in question looks more or less like:
FILE (GLOB my_RESOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} res/*.qrc )
QT4_ADD_RESOURCES( my_RESOURCES_SOURCES ${my_RESOURCES} )
...
It's always best to not do any file globbing and add each file by
hand. I believe this is causing the problem.
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
Re: [CMake] qt .qrc file modifications require two builds
Really? How could it? Suppose I only have 1 qrc file, named foo.qrc:
wouldn't these two lines be equivalent?
FILE (GLOB my_RESOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} res/*.qrc )
SET( my_RESOURCES res/foo.qrc)
???
TIA
G
On Tue, Dec 15, 2009 at 7:15 PM, John Drescher dresche...@gmail.com wrote:
The CMake script in question looks more or less like:
FILE (GLOB my_RESOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} res/*.qrc )
QT4_ADD_RESOURCES( my_RESOURCES_SOURCES ${my_RESOURCES} )
...
It's always best to not do any file globbing and add each file by
hand. I believe this is causing the problem.
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
Re: [CMake] SDL troubles on Mac OS X
On 15. Dec, 2009, at 23:46 , Glenn Hughes wrote: I think the SDL developers are just being a bit too slick. They are setting up SDL for Xcode development where typically you would link to the SDL and then have a Copy Files Phase where you copy the framework into the Application Bundle that resides in the build directory. Its a cultural difference also. Mac developers think of creating the complete application as part of the build process. A Mac app generally contains everything it needs so you can just drag it to another machine and run it. I would never want a half-baked app that is wired into my machine. Copying the libraries into the app isn't part of installation, its part of building... Copying the app somewhere else is installation i.e. a no-op as far as my build process is concerned. G In the case of OS X bundles, don't think of it like installation. It's more like finishing up. How about adding some logic to target_link_libraries that writes a file, similar to depend.internal, mapping the install-name of the linked libraries to their location (if a full path has been used for linking). This file could then be used by BundleUtilities.cmake. Probably one would need to black-list certain directories (such as /System/Library/Frameworks), or is this already done? 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
