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
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 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] 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
[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] 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
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 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] 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 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] 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] 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 CMakeFiles/zc
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] 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 : > 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 > > Mäster Olofsväg 24 > S-224 66 LUND;SWEDEN > -- jens persson 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 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
[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 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
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] 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] 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
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
[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] 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
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 v
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] 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
[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 (compati