Re: [CMake] Current CVS CMake can't build Qt/Cocoa OS X bundle that doesn't crash
I tried copying it to the suggested place, but it still didn't work. My solution, since I'm not a CMake developer, was to go back to using xterm -e ccmake instead of the Qt dialog. On Tue, May 11, 2010 at 1:23 PM, Clinton Stimpson wrote: > > Just a thought: does it change anything if you make a softlink > Versions/Current/Resources -> Resources in QtGui.framework? The message says > QtGui.framework/Versions/Current/Resources/ but when I last tried it, it was > actually looking in QtGui.framework/Resources. They may have changed/fixed > that. > > Clint > > > On Tuesday, May 11, 2010 11:03:48 am kent williams wrote: >> OS X 10.5.8, Qt-4.6.2, g++-4.2 gcc-4.2 >> >> ../cmake/bootstrap --prefix=/scratch/kent/opt --qt-gui >> --qt-qmake=/opt/Qt-4.6.2/bin/qmake >> make >> make install >> >> /scratch/kent/opt/CMake\ 2.9-20100511.app/Contents/MacOS/CMake\ >> 2.9-20100511 Qt internal error: qt_menu.nib could not be loaded. The .nib >> file >> should be placed in QtGui.framework/Versions/Current/Resources/ or in >> the resources directory of your application bundle. >> Abort >> >> This looks like a different problem than the one I agonized over a >> couple weeks ago with respect to qt_menu.nib. There is a qtmenu.nib: >> >> /scratch/kent/opt/CMake >> 2.9-20100511.app/Contents/Frameworks/QtGui.framework/Resources/qt_menu.nib >> >> ls -l /scratch/kent/opt/CMake\ >> 2.9-20100511.app/Contents/Frameworks/QtGui.framework/Resources/qt_menu.nib >> total 32 >> -rw-r--r-- 1 kent user 1451 May 11 11:52 classes.nib >> -rw-r--r-- 1 kent user 471 May 11 11:52 info.nib >> -rw-r--r-- 1 kent user 5567 May 11 11:52 keyedobjects.nib >> >> What it looks like to me is that when the QtGui framework gets copied, >> something is messed up in the paths fixups during fixup_bundle. >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Current CVS CMake can't build Qt/Cocoa OS X bundle that doesn't crash
OS X 10.5.8, Qt-4.6.2, g++-4.2 gcc-4.2 ../cmake/bootstrap --prefix=/scratch/kent/opt --qt-gui --qt-qmake=/opt/Qt-4.6.2/bin/qmake make make install /scratch/kent/opt/CMake\ 2.9-20100511.app/Contents/MacOS/CMake\ 2.9-20100511 Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/ or in the resources directory of your application bundle. Abort This looks like a different problem than the one I agonized over a couple weeks ago with respect to qt_menu.nib. There is a qtmenu.nib: /scratch/kent/opt/CMake 2.9-20100511.app/Contents/Frameworks/QtGui.framework/Resources/qt_menu.nib ls -l /scratch/kent/opt/CMake\ 2.9-20100511.app/Contents/Frameworks/QtGui.framework/Resources/qt_menu.nib total 32 -rw-r--r-- 1 kent user 1451 May 11 11:52 classes.nib -rw-r--r-- 1 kent user 471 May 11 11:52 info.nib -rw-r--r-- 1 kent user 5567 May 11 11:52 keyedobjects.nib What it looks like to me is that when the QtGui framework gets copied, something is messed up in the paths fixups during fixup_bundle. ___ 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] how to (portably) change file permissions -- besides INSTALL?
Subject line says it all. I could explain what I'm trying to do but it would be a case of "Too long, didn't read" for most of you. You can change permissions with the CMake 'install' command, the 'file(COPY)' and 'file(INSTALL)' command but I can't find the command that changes the permissions of an existing file. Unless I'm missing something, which I almost always am. ___ 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] ExternalProjects: How do ExternalProject_add and ExternalProject_Add_Step interact?
I tried just listing the single step, and for some reason (probably my
fault) it didn't work.
I did get this working, but I had to add two things to keep tcl and tk
from breaking fixup_bundle -- I had to make the Tcl/Tk SO libraries
writable, and I needed to delete tclsh and wish, because fixup_bundle
didn't like their link dependencies.
set(TCL_DEPEND tcl)
set(proj tcl)
ExternalProject_Add(${proj}
CVS_REPOSITORY ":pserver:anonymous:@tcl.cvs.sourceforge.net:/cvsroot/tcl"
CVS_TAG -r core-8-5-7
CVS_MODULE "tcl"
CONFIGURE_COMMAND
sh ${CONFIG_WRAPPER}
${BRAINSTracer_BINARY_DIR}/tcl-prefix/src/tcl/unix/configure
--prefix=${BRAINSTracer_BINARY_DIR}
INSTALL_DIR ${BRAINSTracer_BINARY_DIR}
UPDATE_COMMAND ""
)
if(APPLE)
set(SHARED_LIB_EXT .dylib)
else(APPLE)
set(SHARED_LIB_EXT .so)
endif(APPLE)
ExternalProject_Add_Step(${proj} after_install
COMMAND chmod u+w ${BRAINSTracer_BINARY_DIR}/lib/libtcl8.5${SHARED_LIB_EXT}
COMMAND cmake -E remove ${BRAINSTracer_BINARY_DIR}/bin/tclsh8.5
COMMENT "--
${BRAINSTracer_BINARY_DIR}/lib/libtcl8.5 installed read-only!"
DEPENDEES mkdir update patch download configure build install
)
On Tue, Apr 27, 2010 at 10:03 AM, David Cole wrote:
> On Fri, Apr 23, 2010 at 1:11 PM, Luigi Calori wrote:
>>
>> There is some info at
>> http://www.kitware.com/products/archive/kitware_quarterly1009.pdf
>>
>> based on that I thought it was enouth do depend upon just the install in
>> your case...
>
> Luigi is correct: it should be sufficient to list "DEPENDEES install" in
> your case. Kent, why do you think you have to list all the steps as
> DEPENDEES?
>
___
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] can't remove RPATH from libtcl8.5.so (Linux) CMake Git version
Answering my own question again -- this is a logged bug here: http://public.kitware.com/Bug/view.php?id=9284 David Cole is of the opinion this error is useful in the context of fixup_bundle. Maybe so, but it's a right PITA. If you're building the library that's getting copied as part of fixup_bundle, and the permissions don't allow RPATH_REMOVE to work, you're dead in the water until you figure out how to add an install step to move the file and change the permissions. I'm dealing with it by adding a custom ExternalProject step to adjust perms after the install. Just getting that right was a whole other story... ___ 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] ExternalProjects: How do ExternalProject_add and ExternalProject_Add_Step interact?
Answering my own question -- I think. This maybe is information that
could be added to the documentation for ExternalProjects.cmake!
ExternalProject_Add creates a project, e.g.
ExternalProject_Add(tcl
CVS_REPOSITORY ":pserver:anonymous:@tcl.cvs.sourceforge.net:/cvsroot/tcl"
CVS_TAG -r core-8-5-7
CVS_MODULE "tcl"
CONFIGURE_COMMAND
${BRAINSTracer_BINARY_DIR}/tcl-prefix/src/tcl/unix/configure
--prefix=${CMAKE_BINARY_DIR}
INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}
UPDATE_COMMAND ""
)
When the generated makefiles actually build the project, there's a
directory named
${CMAKE_CURRENT_BINARY_DIR}/tcl-prefix/src/tcl-stamp
In which a 0-length file is created after each step of the external
project build is successfully finished. These files (and THIS is what
was undocumented, that I had to determine by poking around in the
build directories) are named
${proj}-mkdir ${proj}-download ${proj}-update ${proj}-patch
${proj}-configure ${proj}-build ${proj}-install ${proj}-done
Where 'proj' is the name you've given the ExternalProject. So in
order to add a step you have to list the steps your new custom step
depends on, after the DEPENDEES keyword. For example:
if(APPLE)
set(SHARED_LIB_EXT .dylib)
else(APPLE)
set(SHARED_LIB_EXT .so)
endif(APPLE)
ExternalProject_Add_Step(${proj} after_install
COMMAND chmod u+w ${BRAINSTracer_BINARY_DIR}/lib/libtcl8.5${SHARED_LIB_EXT}
COMMENT "--
${BRAINSTracer_BINARY_DIR}/lib/libtcl8.5.so installed read-only!"
DEPENDEES mkdir update patch download configure build install
)
Now it appears that you have to list ALL the prerequisite steps, not
just the one after which your step should occur.
___
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] ExternalProjects: How do ExternalProject_add and ExternalProject_Add_Step interact?
So... I have been working on my 'Holy Grail' CMakeLists.txt that builds all prerequisites to my application as ExternalProjects, and then builds my application (also as an External Project). In getting it to work on OS X and Linux I ran into an issue: If you build Tcl, and install it, it installs the shared libraries for Tcl read-only. So, if I try and use fixup_bundle (from BundleUtilities) to make a standalone build with all shared libraries it fails: -- 82/204: copying '/scratch/kent/newbuild/BT-build/lib/libtk8.5.so' CMake Error at /opt/cmake-2.9.20100421/share/cmake-2.9/Modules/BundleUtilities.cmake:431 (file): file RPATH_REMOVE could not remove RPATH from file: /scratch/kent/newbuild/BT-build/bin/libtk8.5.so Error opening file for update. Call Stack (most recent call first): /opt/cmake-2.9.20100421/share/cmake-2.9/Modules/BundleUtilities.cmake:531 (copy_resolved_item_into_bundle) cmake_install.cmake:54 (fixup_bundle) So my thought was 'brilliant! I'll add a step to the ExternalProject!' -- but it isn't clear to me if ExternalProject_Add_Step is actually set up to modify an External Project, or if you're supposed to use ExternalProject_Add_Step commands to swizzle up your own custom External Project. More specifically If I have ExternalProjectAdd(xyz ... ) ExternalProject_Add_Step(xyz fix_permissions ... ) I don't know what to put for DEPENDEES to get fix_permissions to run AFTER the install. Any ideas? ___ 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 do I set env variables with spaces in them in a CONFIGURE_COMMAND clause of ExternalProject_add?
The following seems to be working. The regular expressions to test
the build type are kinda fugly, but at least they're case-insensitive.
I don't know how to make this Windows-compatible, but then Windows
can't run configure scripts anyway.
---BuildTcl.cmake---
set(EXPORT_CFLAGS "${CMAKE_C_FLAGS}")
set(EXPORT_CXXFLAGS "${CMAKE_CXX_FLAGS}")
if(CMAKE_BUILD_TYPE MATCHES [Dd][Ee][Bb][Uu][Gg])
set(EXPORT_CFLAGS "${EXPORT_CFLAGS} ${CMAKE_C_FLAGS_DEBUG}")
set(EXPORT_CXXFLAGS "${EXPORT_CXXFLAGS} ${CMAKE_CXX_FLAGS_DEBUG}")
endif(CMAKE_BUILD_TYPE MATCHES [Dd][Ee][Bb][Uu][Gg])
if(CMAKE_BUILD_TYPE MATCHES [Rr][Ee][Ll][Ee][Aa][Ss][Ee])
set(EXPORT_CFLAGS "${EXPORT_CFLAGS} ${CMAKE_C_FLAGS_RELEASE}")
set(EXPORT_CXXFLAGS "${EXPORT_CXXFLAGS} ${CMAKE_CXX_FLAGS_RELEASE}")
endif(CMAKE_BUILD_TYPE MATCHES [Rr][Ee][Ll][Ee][Aa][Ss][Ee])
set(CONFIG_WRAPPER ${BRAINSTracer_BINARY_DIR}/runconfigure.sh )
configure_file(${BRAINSTracer_SOURCE_DIR}/runconfigure.sh.in
${CONFIG_WRAPPER} @ONLY)
set(TCL_DEPEND tcl)
set(proj tcl)
ExternalProject_Add(${proj}
CVS_REPOSITORY ":pserver:anonymous:@tcl.cvs.sourceforge.net:/cvsroot/tcl"
CVS_TAG -r core-8-5-7
CVS_MODULE "tcl"
CONFIGURE_COMMAND
sh ${CONFIG_WRAPPER}
${CMAKE_CURRENT_BINARY_DIR}/tcl-prefix/src/tcl/unix/configure
--prefix=${CMAKE_CURRENT_BINARY_DIR}
INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}
UPDATE_COMMAND ""
)
---runconfigure.sh---
#!/bin/sh
export CFLAGS="@EXPORT_CFLAGS@"
export CXXFLAGS="@EXPORT_CXXFLAGS@"
export c...@cmake_c_compiler@
export c...@cmake_cxx_compiler@
exec $*
___
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] How do I set env variables with spaces in them in a CONFIGURE_COMMAND clause of ExternalProject_add?
I need to build TCL & TK with CFLAGS and CXXFLAGS matching what's
being used in the rest of my ExternalProjects.
The following doesn't work:
set(COMPILER_STUFF
CC=${CMAKE_C_COMPILER} C
XX=${CMAKE_CXX_COMPILER}
CFLAGS="${CMAKE_C_FLAGS} ${CMAKE_C_FLAGS_RELEASE}"
CXXFLAGS="${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE}")
set(TCL_DEPEND tcl)
set(proj tcl)
ExternalProject_Add(${proj}
CVS_REPOSITORY ":pserver:anonymous:@tcl.cvs.sourceforge.net:/cvsroot/tcl"
CVS_TAG -r core-8-5-7
CVS_MODULE "tcl"
CONFIGURE_COMMAND
${COMPILER_STUFF}
${BRAINSTracer_BINARY_DIR}/tcl-prefix/src/tcl/unix/configure
--prefix=${BRAINSTracer_BINARY_DIR}
INSTALL_DIR ${BRAINSTracer_BINARY_DIR}
UPDATE_COMMAND ""
)
You get this error message:
cd /scratch/kent/newbuild/BT-build/
make -j1
/opt/cmake-2.9.20100421/bin/cmake
-H/scratch/kent/newbuild/BRAINSTracerQT
-B/scratch/kent/newbuild/BT-build --check-build-system
CMakeFiles/Makefile.cmake 0
-- Configuring done
-- Generating done
-- Build files have been written to: /scratch/kent/newbuild/BT-build
/opt/cmake-2.9.20100421/bin/cmake -E cmake_progress_start
/scratch/kent/newbuild/BT-build/CMakeFiles
/scratch/kent/newbuild/BT-build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/scratch/kent/newbuild/BT-build'
make -f CMakeFiles/tcl.dir/build.make CMakeFiles/tcl.dir/depend
make[2]: Entering directory `/scratch/kent/newbuild/BT-build'
cd /scratch/kent/newbuild/BT-build &&
/opt/cmake-2.9.20100421/bin/cmake -E cmake_depends "Unix Makefiles"
/scratch/kent/newbuild/BRAINSTracerQT
/scratch/kent/newbuild/BRAINSTracerQT /scratch/kent/newbuild/BT-build
/scratch/kent/newbuild/BT-build
/scratch/kent/newbuild/BT-build/CMakeFiles/tcl.dir/DependInfo.cmake
--color=
make[2]: Leaving directory `/scratch/kent/newbuild/BT-build'
make -f CMakeFiles/tcl.dir/build.make CMakeFiles/tcl.dir/build
make[2]: Entering directory `/scratch/kent/newbuild/BT-build'
/opt/cmake-2.9.20100421/bin/cmake -E cmake_progress_report
/scratch/kent/newbuild/BT-build/CMakeFiles
[ 0%] Performing configure step for 'tcl'
cd /scratch/kent/newbuild/BT-build/tcl-prefix/src/tcl-build &&
CC=/usr/bin/gcc4 XX=/usr/bin/g++4 "CFLAGS=\"-m64 -O3 -DNDEBUG\""
"CXXFLAGS=\"-m64 -O3 -DNDEBUG\""
/scratch/kent/newbuild/BT-build/tcl-prefix/src/tcl/unix/configure
--prefix=/scratch/kent/newbuild/BT-build
/bin/sh: CFLAGS="-m64 -O3 -DNDEBUG": command not found
make[2]: *** [tcl-prefix/src/tcl-stamp/tcl-configure] Error 127
make[2]: Leaving directory `/scratch/kent/newbuild/BT-build'
make[1]: *** [CMakeFiles/tcl.dir/all] Error 2
make[1]: Leaving directory `/scratch/kent/newbuild/BT-build'
make: *** [all] Error 2
Compilation exited abnormally with code 2 at Thu Apr 22 11:43:43
___
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] can't remove RPATH from libtcl8.5.so (Linux) CMake Git version
I noticed that for some inscrutable reason, the Tcl install makes the
library read-only, so I use this to fix the permissions, but it didn't
make the error go away:
ExternalProject_Add_Step(${proj} after_install
COMMAND chmod u+w ${BRAINSTracer_BINARY_DIR}/lib/libtcl8.5.so
COMMENT "--
${BRAINSTracer_BINARY_DIR}/lib/libtcl8.5.so installed read-only!
"
DEPENDS ${BRAINSTracer_BINARY_DIR}/lib/libtcl8.5.so
WORKING_DIRECTORY ${BRAINSTracer_BINARY_DIR}/lib
ALWAYS 1
)
And file(RPATH_REMOVE) a new command? It isn't in the on-line CMake
man page for 2.8!
On Wed, Apr 21, 2010 at 2:38 PM, kent williams
wrote:
> I downloaded the current Git version of CMake, and it solved that problem.
>
> Now I'm running into a new problem. As it happens, we build our own
> TCL 8.5.7, and so a Linux fixup_bundle
> needs to/wants to remove the RPATH from the library. But for some
> reason it can't open libtcl8.5.so to fiddle with the RPATH. Any ideas
> what the heck is going on?
>
>
> -- 81/204: copying '/scratch/kent/newbuild/BT-build/lib/libtcl8.5.so'
> CMake Error at
> /opt/cmake-2.9.20100421/share/cmake-2.9/Modules/BundleUtilities.cmake:431
> (file):
> file RPATH_REMOVE could not remove RPATH from file:
>
> /scratch/kent/newbuild/BT-build/bin/libtcl8.5.so
>
> Error opening file for update.
> Call Stack (most recent call first):
> /opt/cmake-2.9.20100421/share/cmake-2.9/Modules/BundleUtilities.cmake:531
> (copy_resolved_item_into_bundle)
> cmake_install.cmake:54 (fixup_bundle)
>
>
> On Tue, Apr 20, 2010 at 3:08 PM, Clinton Stimpson
> wrote:
>>
>> To clarify, the patch I submitted saves you from debugging and figuring out
>> what the real problem is.
>>
>> The actual solution is to use the last parameter of fixup_bundle() and pass
>> in
>> "${QT_BINARY_DIR};${QT_LIBRARY_DIR}"
>>
>> Clint
>>
>> On Tuesday 20 April 2010 01:46:25 pm Clinton Stimpson wrote:
>>> I've already made a patch to fix this problem and put it in the bug tracker
>>> (along with a couple other patches).
>>>
>>> Clint
>>>
>>> On Tuesday 20 April 2010 01:42:50 pm kent williams wrote:
>>> > Well I found the magic incantation on OS X to get fixup_bundle work.
>>> > Now I'd like it to work on Linux.
>>> >
>>> > What's happening is I get many of these messages:
>>> >
>>> > warning: cannot resolve item 'not'
>>> >
>>> > The problem comes, as near as I can figure out, from when ldd is run
>>> > to discover the library prerequisites. Running ldd generates a lot of
>>> > lines like this:
>>> > libQVTK.so.5.4 => not found
>>> > libQtGui.so.4 => not found
>>> >
>>> > So the solution seems pretty clear -- if you're on linux, use the
>>> > directory list passed into fixup_bundle in order to set
>>> > LD_LIBRARY_PATH before running ldd. Otherwise fixup_bundle seems to
>>> > want to fix up all sorts of libraries named 'not' and fails.
>>> >
>>> > I'd just fix it myself but my CMake-fu isn't strong enough to hack
>>> > BundleUtilities.cmake
>>> >
>>> > For now I think I'll just turn off fixup_bundle on Linux...
>>> >
>>> > compute22 106% ldd BRAINSTracerQT
>>> > libQVTK.so.5.4 => not found
>>> > libQtGui.so.4 => not found
>>> > libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x003a22d0)
>>> > libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x003a1f20)
>>> > libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x003a1f00)
>>> > libXrender.so.1 => /usr/X11R6/lib64/libXrender.so.1
>>> > (0x003a1fc0)
>>> > libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x003a1f40)
>>> > libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1
>>> > (0x003a1fa0)
>>> > libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x003a1ee0)
>>> > libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x003a1ea0)
>>> > libQtCore.so.4 => not found
>>> > libz.so.1 => /usr/lib64/libz.so.1 (0x003a1e80)
>>> > libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0
>>> > (0x003a24c0) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0
>>> > (0x003a20a0) libgobject-2.0.so.0 =>
>>> > /usr/lib64/libgobject-2.0.so
Re: [CMake] BundleUtilities Question on Linux: Libraries Not Found during fixup?
I downloaded the current Git version of CMake, and it solved that problem.
Now I'm running into a new problem. As it happens, we build our own
TCL 8.5.7, and so a Linux fixup_bundle
needs to/wants to remove the RPATH from the library. But for some
reason it can't open libtcl8.5.so to fiddle with the RPATH. Any ideas
what the heck is going on?
-- 81/204: copying '/scratch/kent/newbuild/BT-build/lib/libtcl8.5.so'
CMake Error at
/opt/cmake-2.9.20100421/share/cmake-2.9/Modules/BundleUtilities.cmake:431
(file):
file RPATH_REMOVE could not remove RPATH from file:
/scratch/kent/newbuild/BT-build/bin/libtcl8.5.so
Error opening file for update.
Call Stack (most recent call first):
/opt/cmake-2.9.20100421/share/cmake-2.9/Modules/BundleUtilities.cmake:531
(copy_resolved_item_into_bundle)
cmake_install.cmake:54 (fixup_bundle)
On Tue, Apr 20, 2010 at 3:08 PM, Clinton Stimpson wrote:
>
> To clarify, the patch I submitted saves you from debugging and figuring out
> what the real problem is.
>
> The actual solution is to use the last parameter of fixup_bundle() and pass in
> "${QT_BINARY_DIR};${QT_LIBRARY_DIR}"
>
> Clint
>
> On Tuesday 20 April 2010 01:46:25 pm Clinton Stimpson wrote:
>> I've already made a patch to fix this problem and put it in the bug tracker
>> (along with a couple other patches).
>>
>> Clint
>>
>> On Tuesday 20 April 2010 01:42:50 pm kent williams wrote:
>> > Well I found the magic incantation on OS X to get fixup_bundle work.
>> > Now I'd like it to work on Linux.
>> >
>> > What's happening is I get many of these messages:
>> >
>> > warning: cannot resolve item 'not'
>> >
>> > The problem comes, as near as I can figure out, from when ldd is run
>> > to discover the library prerequisites. Running ldd generates a lot of
>> > lines like this:
>> > libQVTK.so.5.4 => not found
>> > libQtGui.so.4 => not found
>> >
>> > So the solution seems pretty clear -- if you're on linux, use the
>> > directory list passed into fixup_bundle in order to set
>> > LD_LIBRARY_PATH before running ldd. Otherwise fixup_bundle seems to
>> > want to fix up all sorts of libraries named 'not' and fails.
>> >
>> > I'd just fix it myself but my CMake-fu isn't strong enough to hack
>> > BundleUtilities.cmake
>> >
>> > For now I think I'll just turn off fixup_bundle on Linux...
>> >
>> > compute22 106% ldd BRAINSTracerQT
>> > libQVTK.so.5.4 => not found
>> > libQtGui.so.4 => not found
>> > libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x003a22d0)
>> > libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x003a1f20)
>> > libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x003a1f00)
>> > libXrender.so.1 => /usr/X11R6/lib64/libXrender.so.1
>> > (0x003a1fc0)
>> > libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x003a1f40)
>> > libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1
>> > (0x003a1fa0)
>> > libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x003a1ee0)
>> > libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x003a1ea0)
>> > libQtCore.so.4 => not found
>> > libz.so.1 => /usr/lib64/libz.so.1 (0x003a1e80)
>> > libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0
>> > (0x003a24c0) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0
>> > (0x003a20a0) libgobject-2.0.so.0 =>
>> > /usr/lib64/libgobject-2.0.so.0 (0x003a20e0) librt.so.1 =>
>> > /lib64/tls/librt.so.1 (0x003a2360)
>> > libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x003a1ec0)
>> > libdl.so.2 => /lib64/libdl.so.2 (0x003a1e60)
>> > libITKAlgorithms.so.3.18 => not found
>> > libITKStatistics.so.3.18 => not found
>> > libITKFEM.so.3.18 => not found
>> > libitkNetlibSlatec.so.3.18 => not found
>> > libitkv3p_lsqr.so.3.18 => not found
>> > libITKEXPAT.so.3.18 => not found
>> > libitksys.so.3.18 => not found
>> > libvtkRenderingAddOn.so => not found
>> > libvtkRendering.so.5.4 => not found
>> > libvtkFiltering.so.5.4 => not found
>> > libvtkVolumeRendering.so.5.4 => not found
>> > libtcl8.4.so => /usr/lib64/libtcl8.4.so (0x002a95594000)
>> > libModuleDescriptionParser.so
[CMake] BundleUtilities Question on Linux: Libraries Not Found during fixup?
Well I found the magic incantation on OS X to get fixup_bundle work. Now I'd like it to work on Linux. What's happening is I get many of these messages: warning: cannot resolve item 'not' The problem comes, as near as I can figure out, from when ldd is run to discover the library prerequisites. Running ldd generates a lot of lines like this: libQVTK.so.5.4 => not found libQtGui.so.4 => not found So the solution seems pretty clear -- if you're on linux, use the directory list passed into fixup_bundle in order to set LD_LIBRARY_PATH before running ldd. Otherwise fixup_bundle seems to want to fix up all sorts of libraries named 'not' and fails. I'd just fix it myself but my CMake-fu isn't strong enough to hack BundleUtilities.cmake For now I think I'll just turn off fixup_bundle on Linux... compute22 106% ldd BRAINSTracerQT libQVTK.so.5.4 => not found libQtGui.so.4 => not found libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x003a22d0) libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x003a1f20) libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x003a1f00) libXrender.so.1 => /usr/X11R6/lib64/libXrender.so.1 (0x003a1fc0) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x003a1f40) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x003a1fa0) libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x003a1ee0) libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x003a1ea0) libQtCore.so.4 => not found libz.so.1 => /usr/lib64/libz.so.1 (0x003a1e80) libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x003a24c0) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x003a20a0) libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x003a20e0) librt.so.1 => /lib64/tls/librt.so.1 (0x003a2360) libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x003a1ec0) libdl.so.2 => /lib64/libdl.so.2 (0x003a1e60) libITKAlgorithms.so.3.18 => not found libITKStatistics.so.3.18 => not found libITKFEM.so.3.18 => not found libitkNetlibSlatec.so.3.18 => not found libitkv3p_lsqr.so.3.18 => not found libITKEXPAT.so.3.18 => not found libitksys.so.3.18 => not found libvtkRenderingAddOn.so => not found libvtkRendering.so.5.4 => not found libvtkFiltering.so.5.4 => not found libvtkVolumeRendering.so.5.4 => not found libtcl8.4.so => /usr/lib64/libtcl8.4.so (0x002a95594000) libModuleDescriptionParser.so => not found libvtkQtChart.so.5.4 => not found libQtOpenGL.so.4 => not found libGLU.so.1 => /usr/X11R6/lib64/libGLU.so.1 (0x003a2180) libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x003a2140) libm.so.6 => /lib64/tls/libm.so.6 (0x003a1e40) libQtSql.so.4 => not found libvtkViews.so.5.4 => not found libvtkInfovis.so.5.4 => not found libvtklibxml2.so.5.4 => not found libvtkalglib.so.5.4 => not found libITKNumerics.so.3.18 => not found libITKBasicFilters.so.3.18 => not found libITKIO.so.3.18 => not found libITKNrrdIO.so.3.18 => not found libitkgdcm.so.3.18 => not found libitkjpeg12.so.3.18 => not found libitkjpeg16.so.3.18 => not found libitkopenjpeg.so.3.18 => not found libuuid.so.1 => /lib64/tls/libuuid.so.1 (0x002a95758000) libitkpng.so.3.18 => not found libitktiff.so.3.18 => not found libitkjpeg8.so.3.18 => not found libITKSpatialObject.so.3.18 => not found libITKCommon.so.3.18 => not found libitkvnl_inst.so.3.18 => not found libitkvnl_algo.so.3.18 => not found libitkv3p_netlib.so.3.18 => not found libitkvnl.so.3.18 => not found libitkvcl.so.3.18 => not found libITKMetaIO.so.3.18 => not found libITKDICOMParser.so.3.18 => not found libITKniftiio.so.3.18 => not found libITKznz.so.3.18 => not found libitkzlib.so.3.18 => not found libvtkWidgets.so.5.4 => not found libvtkHybrid.so.5.4 => not found libvtkGraphics.so.5.4 => not found libvtkverdict.so.5.4 => not found libvtkImaging.so.5.4 => not found libvtkftgl.so.5.4 => not found libvtkfreetype.so.5.4 => not found libXt.so.6 => /usr/X11R6/lib64/libXt.so.6 (0x003a23e0) libXss.so.1 => /usr/X11R6/lib64/libXss.so.1 (0x003a2690) libXft.so.2 => /usr/X11R6/lib64/libXft.so.2 (0x003a2040) libvtkIO.so.5.4 => not found libvtkCommon.so.5.4 => not found libvtkDICOMParser.so.5.4 => not found libvtkmetaio.so.5.4 => not found libvtksqlite.so.5.4 => not found libvtkpng.so.5.4 => not found libvtktiff.so.5.4 => not fo
Re: [CMake] CMake 2.8.1 + Qt/Cocoa + OS X Problem -- qt_menu.nib not getting copied
If you have the URL of this example, I'd love to look at it. I have
been poring over the CMake wiki without finding anything.
But that's not what I was concerned about. What bothers me is that:
1, If you build against Qt-Carbon, this isn't a problem.
2. if qtmenu.nib is needed, and it isn't being fixed by
BundleUtilities::fixup_bundle, then fixup_bundle isn't actually fixing
up the bundle.
The bug 1 I found in the CMake bug tracker actually is
specifically about working around this problem in the specific case of
building the Qt CMake client.
My broader philosophical concern is that actually making a proper OS X
bundle with CMake is a process with too many moving parts. The whole
point of CMake is to eliminate boilerplate by dealing with the build
process at a higher level, and this strikes me as definitely something
that has to happen every time you build a bundle for OSX
On Thu, Apr 15, 2010 at 9:07 PM, Mike Jackson
wrote:
> I do not see any where in your code commands to actually copy the nib
> file from the qtgui framework into your app bundle. I know thatbthe
> way I set up my installation code I explicitly put a command to copy
> the nib file. I believe there is a qt example on the cmake wiki that
> shows how to do that.
>
> -
> Mike Jackson www.bluequartz.net
> Principal Software Engineer mike.jack...@bluequartz.net
> BlueQuartz Software Dayton, Ohio
>
>
> On Apr 15, 2010, at 17:06, kent williams
> wrote:
>
>> I'll include my CMakeLists.txt at the end of this message, but the
>> long and the short of it is this: My ApplicationBundle crashes when I
>> try and open it with this classic error message:
>>
>> Qt internal error: qt_menu.nib could not be loaded. The .nib file
>> should be placed in QtGui.framework/Versions/Current/Resources/ or in
>> the resources directory of your application bundle.
>>
>> This is supposed to be fixed, as documented in this bug:
>>
>> http://public.kitware.com/Bug/view.php?id=1
>>
>> I checked out the latest GIT CMake and verified that the file in
>> question is the same in 2.8.1 and current GIT trunk.
>>
>> So is there some magical extra step I need to get my bundle properly
>> fixed up?
>>
>> project( BRAINSTracerQT )
>> cmake_minimum_required(VERSION 2.8)
>> cmake_policy(VERSION 2.8)
>>
>> find_package( VTK REQUIRED )
>> include(${VTK_USE_FILE})
>>
>> find_package( ITK REQUIRED )
>> include(${ITK_USE_FILE})
>>
>> find_package( Qt4 REQUIRED )
>> if(QT_USE_FILE)
>> include(${QT_USE_FILE})
>> set(QT_USE_QTXML 1)
>> else(QT_USE_FILE)
>> set( QT_LIBRARIES ${QT_QT_LIBRARY})
>> endif(QT_USE_FILE)
>>
>> find_package(ModuledescriptionParser REQUIRED)
>> include(${ModuleDescriptionParser_USE_FILE})
>>
>> find_package(TCL REQUIRED)
>>
>> find_package( VTK REQUIRED )
>> include(${VTK_USE_FILE})
>>
>> find_package( ITK REQUIRED )
>> include(${ITK_USE_FILE})
>> include_directories(
>> ${BRAINSTracerQT_SOURCE_DIR}
>> ${BRAINSTracerQT_BINARY_DIR}
>> )
>>
>> configure_file(${CMAKE_CURRENT_SOURCE_DIR}/ExecutablePath.h.in
>> ${CMAKE_BINARY_DIR}/ExecutablePath.h IMMEDIATE @ONLY)
>>
>> add_subdirectory(vtkRenderingAddOn)
>> include_directories(${BRAINSTracerQT_SOURCE_DIR}/vtkRenderingAddOn)
>>
>> set(BRAINSTracerQT_SRCS
>> main.cxx
>> BTMainWindow.cxx
>> vtkKWImage.cxx
>> vtkKWImage2D.cxx
>> QVtkImageViewer.cxx
>> vtkMultiWidgetBase.cxx
>> vtkMultiContourWidget.cxx
>> vtkBTPointSetWidget.cxx
>> vtkBTPointWidget.cxx
>> PolyDataUtils.cxx
>> BTContour.cxx
>> BTPolygon.cxx
>> DiscreteParticleFilter.cxx
>> PolygonFill.cxx
>> LoadMaskImage.cxx
>> qtcolorpicker.cxx
>> QVtkPropertyDialog.cxx
>> QModuleParameterWidget.cxx
>> QImageParameterWidget.cxx
>> QFileBrowserParameterWidget.cxx
>> )
>>
>> set(BRAINSTracerQT_HDRS
>> BTMainWindow.h
>> QVtkImageViewer.h
>> qtcolorpicker.h
>> QVtkPropertyDialog.h
>> QModuleParameterWidget.h
>> QImageParameterWidget.h
>> QFileBrowserParameterWidget.h
>> )
>>
>> set(BRAINSTracerQT_RCCS
>> BRAINSTracerQT.qrc)
>>
>> set(BRAINSTracerQT_UIS
>> qvtkpropertydialog.ui)
>>
>> QT4_WRAP_CPP( MOCSrcs ${BRAINSTracerQT_HDRS} )
>>
>> QT4_ADD_RESOURCES(RCC_SRCS ${BRAINSTracerQT_RCCS})
>>
>> QT4_WRAP_UI(UIHeaders ${BRAINSTracerQT_UIS} )
>>
>> set_source_files_properties(${BRAINSTracerQT_SRCS}
>> PROPERTIES OBJECT_D
[CMake] CMake 2.8.1 + Qt/Cocoa + OS X Problem -- qt_menu.nib not getting copied
I'll include my CMakeLists.txt at the end of this message, but the
long and the short of it is this: My ApplicationBundle crashes when I
try and open it with this classic error message:
Qt internal error: qt_menu.nib could not be loaded. The .nib file
should be placed in QtGui.framework/Versions/Current/Resources/ or in
the resources directory of your application bundle.
This is supposed to be fixed, as documented in this bug:
http://public.kitware.com/Bug/view.php?id=1
I checked out the latest GIT CMake and verified that the file in
question is the same in 2.8.1 and current GIT trunk.
So is there some magical extra step I need to get my bundle properly fixed up?
project( BRAINSTracerQT )
cmake_minimum_required(VERSION 2.8)
cmake_policy(VERSION 2.8)
find_package( VTK REQUIRED )
include(${VTK_USE_FILE})
find_package( ITK REQUIRED )
include(${ITK_USE_FILE})
find_package( Qt4 REQUIRED )
if(QT_USE_FILE)
include(${QT_USE_FILE})
set(QT_USE_QTXML 1)
else(QT_USE_FILE)
set( QT_LIBRARIES ${QT_QT_LIBRARY})
endif(QT_USE_FILE)
find_package(ModuledescriptionParser REQUIRED)
include(${ModuleDescriptionParser_USE_FILE})
find_package(TCL REQUIRED)
find_package( VTK REQUIRED )
include(${VTK_USE_FILE})
find_package( ITK REQUIRED )
include(${ITK_USE_FILE})
include_directories(
${BRAINSTracerQT_SOURCE_DIR}
${BRAINSTracerQT_BINARY_DIR}
)
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/ExecutablePath.h.in
${CMAKE_BINARY_DIR}/ExecutablePath.h IMMEDIATE @ONLY)
add_subdirectory(vtkRenderingAddOn)
include_directories(${BRAINSTracerQT_SOURCE_DIR}/vtkRenderingAddOn)
set(BRAINSTracerQT_SRCS
main.cxx
BTMainWindow.cxx
vtkKWImage.cxx
vtkKWImage2D.cxx
QVtkImageViewer.cxx
vtkMultiWidgetBase.cxx
vtkMultiContourWidget.cxx
vtkBTPointSetWidget.cxx
vtkBTPointWidget.cxx
PolyDataUtils.cxx
BTContour.cxx
BTPolygon.cxx
DiscreteParticleFilter.cxx
PolygonFill.cxx
LoadMaskImage.cxx
qtcolorpicker.cxx
QVtkPropertyDialog.cxx
QModuleParameterWidget.cxx
QImageParameterWidget.cxx
QFileBrowserParameterWidget.cxx
)
set(BRAINSTracerQT_HDRS
BTMainWindow.h
QVtkImageViewer.h
qtcolorpicker.h
QVtkPropertyDialog.h
QModuleParameterWidget.h
QImageParameterWidget.h
QFileBrowserParameterWidget.h
)
set(BRAINSTracerQT_RCCS
BRAINSTracerQT.qrc)
set(BRAINSTracerQT_UIS
qvtkpropertydialog.ui)
QT4_WRAP_CPP( MOCSrcs ${BRAINSTracerQT_HDRS} )
QT4_ADD_RESOURCES(RCC_SRCS ${BRAINSTracerQT_RCCS})
QT4_WRAP_UI(UIHeaders ${BRAINSTracerQT_UIS} )
set_source_files_properties(${BRAINSTracerQT_SRCS}
PROPERTIES OBJECT_DEPENDS ${UIHeaders})
add_definitions(-DQT_GUI_LIBS -DQT_CORE_LIB -DQT3_SUPPORT)
#set_source_files_properties(${BRAINSTracerQT_SRCS} PROPERTIES
# OBJECT_DEPENDS "${UIHeaders}")
add_executable( BRAINSTracerQT
MACOSX_BUNDLE
WIN32
${BRAINSTracerQT_SRCS}
${MOCSrcs}
${RCC_SRCS}
)
target_link_libraries( BRAINSTracerQT
QVTK
${QT_LIBRARIES}
${ITK_LIBRARIES}
vtkRenderingAddOn
vtkRendering
vtkFiltering
vtkVolumeRendering
${TCL_LIBRARY}
ModuleDescriptionParser
)
GET_TARget_property(TARGET_EXEC_DIR BRAINSTracerQT RUNTIME_OUTPUT_DIRECTORY)
set(TARGET_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/bin")
set(DEFAULT_MODULE_SEARCH_PATH
"${TARGET_EXEC_DIR}/Modules")
#
# Now the installation stuff below
#
SET(plugin_dest_dir bin)
SET(qtconf_dest_dir bin)
SET(APPS "\${CMAKE_INSTALL_PREFIX}/bin/BRAINSTracerQT")
IF(APPLE)
SET(plugin_dest_dir BRAINSTracerQT.app/Contents/MacOS)
SET(qtconf_dest_dir BRAINSTracerQT.app/Contents/Resources)
SET(APPS "\${CMAKE_INSTALL_PREFIX}/BRAINSTracerQT.app")
ENDIF(APPLE)
IF(WIN32)
SET(APPS "\${CMAKE_INSTALL_PREFIX}/bin/BRAINSTracerQT.exe")
ENDIF(WIN32)
#
# Install the BRAINSTracerQT application, on Apple, the bundle is at
the root of the
# install tree, and on other platforms it'll go into the bin directory.
INSTALL(TARGETS BRAINSTracerQT
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION bin COMPONENT Runtime
)
#
# Install needed Qt plugins by copying directories from the qt installation
# One can cull what gets copied by using 'REGEX "..." EXCLUDE'
INSTALL(DIRECTORY "${QT_PLUGINS_DIR}/imageformats" DESTINATION
${plugin_dest_dir}/plugins COMPONENT Runtime)
#
# install a qt.conf file
# this inserts some cmake code into the install script to write the file
INSTALL(CODE "
file(WRITE \"\${CMAKE_INSTALL_PREFIX}/${qtconf_dest_dir}/qt.conf\" \"\")
" COMPONENT Runtime)
#
# Use BundleUtilities to get all other dependencies for the
[CMake] ExternalProject vs add_subdirectory (was Re: SubProject configuration in same build as host)
There's a 'chicken-and-egg' problem with using ExternalProject in this context: When you configure a project that uses ExternalProject_add, that project won't be available to be found by FindPackage until AFTER the project is built. But CMake will want to find it at Configuration Time, and it will not yet exist. The only way I know out of this 'chicken and egg' problem is to make ParaView itself an ExternalProject that depends on HDF5. ExternalProject is great and all, but this is rather an annoying problem, because the most natural thing to do would be to add ExternalProjects into the CMakeLists.txt for the projects upon which they depend. To do this, ExternalProject would probably have to be more than a Module. You can probably finesse this by defining the variables defined by e.g. UseHDF5.cmake based on where the ExternalProject will drop its files when it's done building and installs. Or maybe this would be a good thing to add to the ExternalProject macro itself -- have it define the variables a project would need to use the ExternalProject once it's built. Then at configure time, the build system should be generated so that anything depending on an ExternalProject should be built after it. On Thu, Apr 15, 2010 at 5:57 AM, Dave Partyka wrote: > Just thinking out loud but we could make an "external_project" call instead. > This would sync, configure, build and install it easily without needing to > override anything. And then ParaView would just FindPackage(HDF5) with the > internal build directory as a hint. > ___ 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] ExternalProject module -- questions
I'm trying to come up with a workable 'super build' for our programs,
using the ExternalProject module. I'm using CMake 2.8.0 -- not sure
if there's any substantive improvements in ExternalProject.cmake in
2.8.1 or CMake CVS.
In short, I want to build Tcl, Tk, VTK, ITK (with WrapITK), CableSwig
(for WrapITK). My application also depends on Qt, but I'm using an
installed binary for that
My strategy is to build everything using as close to a vanilla setup
as is possible, and have each package install using the project binary
directory as the install target. In other words, my top level
CMakeLists.txt, which includes all the ExternalProject_add macros,
sets CMAKE_INSTALL_PREFIX to CMAKE_CURRENT_BINARY_DIR
I've solved some problems for myself, but I'm running into several
confusing things:
1. VTK can't seem to build, at least with Wrapping turned on. The
problem seems to be that it tries to build the executable 'vtk' in
VTK-prefix/src/VTK-build/Wrapping/Tcl, which contains a directory
named 'vtk'
2. The included CMakeLists.txt seems to generate projects that build
in a non-deterministic, order. Sometimes Tcl builds first, Sometimes
CableSwig.
3. I'm confused about the interaction between CMAKE_INSTALL_PREFIX,
and the ExternalProject_add parameter INSTALL_DIR. If I give
INSTALL_DIR in the ExternalProject_add macro, it still tries to
install the programs in /usr/local. So now I explicitly set
CMAKE_INSTALL_PREFIX in the arguments to ExternalProject_add, but it
doesn't make sense that I should have to?
project(BRAINSTracer)
cmake_minimum_required(VERSION 2.8)
cmake_policy(VERSION 2.8)
set(CMAKE_VERBOSE_MAKEFILE on)
enable_testing()
include(Dart)
include(CPack)
include(ExternalProject)
#set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lib)
#set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/lib)
#set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
#set(CMAKE_BUNDLE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/bin)
find_package( Qt4 REQUIRED )
if(QT_USE_FILE)
include(${QT_USE_FILE})
set(QT_USE_QTXML 1)
else(QT_USE_FILE)
set( QT_LIBRARIES ${QT_QT_LIBRARY})
endif(QT_USE_FILE)
SET(QT_CMAKE_FLAGS
-DVTK_USE_QT:BOOL=ON
-DVTK_USE_QVTK:BOOL=ON
-DVTK_USE_GUISUPPORT:BOOL=ON
-DDESIRED_QT_VERSION:STRING=4
-DVTK_USE_QVTK_QTOPENGL:BOOL=ON
)
if(APPLE)
set(QT_CMAKE_FLAGS ${QT_CMAKE_FLAGS}
-DVTK_USE_CARBON:BOOL=OFF
-DVTK_USE_COCOA:BOOL=ON
-DVTK_USE_X:BOOL=OFF
)
set(LIB_EXT dylib)
set(EXTRA_TK_FLAGS
--enable-aqua
--enable-corefoundation
)
else(APPLE)
set(QT_CMAKE_FLAGS ${QT_CMAKE_FLAGS}
-DVTK_USE_CARBON:BOOL=OFF
-DVTK_USE_COCOA:BOOL=OFF
-DVTK_USE_X:BOOL=ON
)
set(LIB_EXT .so)
endif(APPLE)
# -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_INSTALL_PREFIX}
SET(LOCAL_CMAKE_BUILD_OPTIONS
-DMAKECOMMAND:STRING=${MAKECOMMAND}
-DCMAKE_SKIP_RPATH:BOOL=ON
-DCMAKE_BUILD_TYPE:STRING=${CMAKE_BUILD_TYPE}
-DCMAKE_CXX_FLAGS_RELEASE:STRING=${CMAKE_CXX_FLAGS_RELEASE}
-DCMAKE_CXX_FLAGS_DEBUG:STRING=${CMAKE_CXX_FLAGS_DEBUG}
-DCMAKE_CXX_FLAGS:STRING=${CMAKE_CXX_FLAGS}
-DCMAKE_C_FLAGS_RELEASE:STRING=${CMAKE_C_FLAGS_RELEASE}
-DCMAKE_C_FLAGS_DEBUG:STRING=${CMAKE_C_FLAGS_DEBUG}
-DCMAKE_C_FLAGS:STRING=${CMAKE_C_FLAGS}
-DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}
-DBUILD_EXAMPLES:BOOL=OFF
-DBUILD_SHARED_LIBS:BOOL=${BUILD_SHARED_LIBS}
-DBUILD_TESTING:BOOL=OFF
-DCMAKE_GENERATOR:STRING=${CMAKE_GENERATOR}
-DCMAKE_EXTRA_GENERATOR:STRING=${CMAKE_EXTRA_GENERATOR}
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY:PATH=${CMAKE_LIBRARY_OUTPUT_DIRECTORY}
-DCMAKE_ARCHIVE_OUTPUT_DIRECTORY:PATH=${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
-DCMAKE_BUNDLE_OUTPUT_DIRECTORY:PATH=${CMAKE_BUNDLE_OUTPUT_DIRECTORY}
-DLIBRARY_OUTPUT_PATH:PATH=${CMAKE_LIBRARY_OUTPUT_DIRECTORY}
-DEXECUTABLE_OUTPUT_PATH:PATH=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
-DDART_TESTING_TIMEOUT:STRING=${DART_TESTING_TIMEOUT}
-DMEMORYCHECK_COMMAND_OPTIONS:STRING=${MEMORYCHECK_COMMAND_OPTIONS}
-DMEMORYCHECK_COMMAND:PATH=${MEMORYCHECK_COMMAND}
-DCMAKE_SHARED_LINKER_FLAGS:STRING=${CMAKE_SHARED_LINKER_FLAGS}
-DCMAKE_EXE_LINKER_FLAGS:STRING=${CMAKE_EXE_LINKER_FLAGS}
-DCMAKE_MODULE_LINKER_FLAGS:STRING=${CMAKE_MODULE_LINKER_FLAGS}
-DSITE:STRING=${SITE}
-DBUILDNAME:STRING=${BUILDNAME}
${QT_CMAKE_FLAGS}
)
set(TCL_DEPEND tcl)
set(proj tcl)
ExternalProject_Add(${proj}
CVS_REPOSITORY ":pserver:anonymous:@tcl.cvs.sourceforge.net:/cvsroot/tcl"
CVS_TAG -r core-8-5-7
CVS_MODULE "tcl"
CONFIGURE_COMMAND CMAKE_C_COMPILER="${CMAKE_C_COMPILER}"
CMAKE_CXX_COMPILER="${CMAKE_CXX_COMPILER}"
${CMAKE_CURRENT_BINARY_DIR}/TCL-prefix/src/TCL/unix/configure
--prefix=${CMAKE_CURRENT_BINARY_DIR}
INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}
UPDATE_COMMAND ""
)
set(buildTK True)
if(buildTK)
set(TK_DEPEND tk)
set(proj tk)
ExternalProject_Add(${proj}
CVS_REPOSITORY ":pserver:anonymous:@tcl.cvs.sourceforge.net:/cvsroot/tktoolkit"
CVS_TAG -r core-8-5-7
CVS_MODULE "tk"
CONFIGURE_COMMAND CMAK
[CMake] ExternalProject_add: Does it have to rebuild every time you run make?
So if I use large libraries as ExternalProject builds, am I doomed to
have everything rebuild every time I run Make? Every time I type make
at the top level of my tree, it does every step of every external
project build.
This wouldn't be so terrible, but if Tcl and Tk get re-installed, then
VTK will recompile everything including a Tcl or Tk header.
Below I have my CMakeLists.txt that I'm currently working with.
CMakeLists.txt==
project(TclTkVtk)
cmake_minimum_required(VERSION 2.8)
cmake_policy(VERSION 2.8)
set(CMAKE_VERBOSE_MAKEFILE on)
enable_testing()
include(Dart)
include(CPack)
include(ExternalProject)
find_package( Qt4 REQUIRED )
if(QT_USE_FILE)
include(${QT_USE_FILE})
set(QT_USE_QTXML 1)
else(QT_USE_FILE)
set( QT_LIBRARIES ${QT_QT_LIBRARY})
endif(QT_USE_FILE)
SET(QT_CMAKE_FLAGS
-DVTK_USE_QT:BOOL=ON
-DVTK_USE_QVTK:BOOL=ON
-DVTK_USE_GUISUPPORT:BOOL=ON
-DDESIRED_QT_VERSION:STRING=4
-DVTK_USE_QVTK_QTOPENGL:BOOL=ON
)
if(APPLE)
set(QT_CMAKE_FLAGS ${QT_CMAKE_FLAGS}
-DVTK_USE_CARBON:BOOL=OFF
-DVTK_USE_COCOA:BOOL=ON
-DVTK_USE_X:BOOL=OFF
)
set(LIB_EXT dylib)
set(EXTRA_TK_FLAGS
--enable-aqua
--enable-corefoundation
)
else(APPLE)
set(QT_CMAKE_FLAGS ${QT_CMAKE_FLAGS}
-DVTK_USE_CARBON:BOOL=OFF
-DVTK_USE_COCOA:BOOL=OFF
-DVTK_USE_X:BOOL=ON
)
set(LIB_EXT .so)
endif(APPLE)
SET(LOCAL_CMAKE_BUILD_OPTIONS
-DMAKECOMMAND:STRING=${MAKECOMMAND}
-DCMAKE_SKIP_RPATH:BOOL=ON
-DCMAKE_BUILD_TYPE:STRING=${CMAKE_BUILD_TYPE}
-DCMAKE_CXX_FLAGS_RELEASE:STRING=${CMAKE_CXX_FLAGS_RELEASE}
-DCMAKE_CXX_FLAGS_DEBUG:STRING=${CMAKE_CXX_FLAGS_DEBUG}
-DCMAKE_CXX_FLAGS:STRING=${CMAKE_CXX_FLAGS}
-DCMAKE_C_FLAGS_RELEASE:STRING=${CMAKE_C_FLAGS_RELEASE}
-DCMAKE_C_FLAGS_DEBUG:STRING=${CMAKE_C_FLAGS_DEBUG}
-DCMAKE_C_FLAGS:STRING=${CMAKE_C_FLAGS}
-DBUILD_EXAMPLES:BOOL=OFF
-DBUILD_SHARED_LIBS:BOOL=${BUILD_SHARED_LIBS}
-DBUILD_TESTING:BOOL=OFF
-DCMAKE_GENERATOR:STRING=${CMAKE_GENERATOR}
-DCMAKE_EXTRA_GENERATOR:STRING=${CMAKE_EXTRA_GENERATOR}
-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_INSTALL_PREFIX}
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY:PATH=${CMAKE_LIBRARY_OUTPUT_DIRECTORY}
-DCMAKE_ARCHIVE_OUTPUT_DIRECTORY:PATH=${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=${CMAKE_RUNTIME_OUTPUT_DIRECTORY}
-DCMAKE_BUNDLE_OUTPUT_DIRECTORY:PATH=${CMAKE_BUNDLE_OUTPUT_DIRECTORY}
-DDART_TESTING_TIMEOUT:STRING=${DART_TESTING_TIMEOUT}
-DMEMORYCHECK_COMMAND_OPTIONS:STRING=${MEMORYCHECK_COMMAND_OPTIONS}
-DMEMORYCHECK_COMMAND:PATH=${MEMORYCHECK_COMMAND}
-DCMAKE_SHARED_LINKER_FLAGS:STRING=${CMAKE_SHARED_LINKER_FLAGS}
-DCMAKE_EXE_LINKER_FLAGS:STRING=${CMAKE_EXE_LINKER_FLAGS}
-DCMAKE_MODULE_LINKER_FLAGS:STRING=${CMAKE_MODULE_LINKER_FLAGS}
-DSITE:STRING=${SITE}
-DBUILDNAME:STRING=${BUILDNAME}
${QT_CMAKE_FLAGS}
)
set(TCL_DEPEND TCL)
set(proj TCL)
ExternalProject_Add(${proj}
CVS_REPOSITORY ":pserver:anonymous:@tcl.cvs.sourceforge.net:/cvsroot/tcl"
CVS_TAG -r core-8-5-7
CVS_MODULE "tcl"
CONFIGURE_COMMAND CMAKE_C_COMPILER="${CMAKE_C_COMPILER}"
CMAKE_CXX_COMPILER="${CMAKE_CXX_COMPILER}"
${CMAKE_CURRENT_BINARY_DIR}/TCL-prefix/src/TCL/unix/configure
--prefix=${CMAKE_CURRENT_BINARY_DIR}
)
set(TK_DEPEND TK)
set(proj TK)
ExternalProject_Add(${proj}
CVS_REPOSITORY ":pserver:anonymous:@tcl.cvs.sourceforge.net:/cvsroot/tktoolkit"
CVS_TAG -r core-8-5-7
CVS_MODULE "tk"
CONFIGURE_COMMAND CMAKE_C_COMPILER="${CMAKE_C_COMPILER}"
CMAKE_CXX_COMPILER="${CMAKE_CXX_COMPILER}"
${CMAKE_CURRENT_BINARY_DIR}/TK-prefix/src/TK/unix/configure
--prefix=${CMAKE_CURRENT_BINARY_DIR}
--with-tcl=${CMAKE_CURRENT_BINARY_DIR}/lib ${EXTRA_TK_FLAGS}
DEPENDS ${TCL_DEPEND}
)
#
# build VTK
# -DVTK_USE_TK:BOOL=yes
set(VTK_DEPEND VTK)
set(proj VTK)
ExternalProject_Add(${proj}
CVS_REPOSITORY ":pserver:anonym...@public.kitware.com:/cvsroot/VTK"
CVS_TAG -r VTK-5-4-2
CVS_MODULE "VTK"
CMAKE_ARGS ${LOCAL_CMAKE_BUILD_OPTIONS} -DVTK_WRAP_TCL:BOOL=ON
-DTCL_INCLUDE_PATH:PATH=${CMAKE_CURRENT_BINARY_DIR}/include
-DTK_INCLUDE_PATH:PATH=${CMAKE_CURRENT_BINARY_DIR}/include
-DTCL_LIBRARY:FILEPATH=${CMAKE_CURRENT_BINARY_DIR}/lib/libtk8.5.${LIB_EXT}
-DTK_LIBRARY:FILEPATH=${CMAKE_CURRENT_BINARY_DIR}/lib/libtcl8.5.${LIB_EXT}
-DTCL_TCLSH:FILEPATH=${CMAKE_CURRENT_BINARY_DIR}/bin/tclsh8.5
INSTALL_DIR ${CMAKE_INSTALL_PREFIX}
DEPENDS ${TCL_DEPEND} ${TK_DEPEND}
)
___
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] HOW DO I: Build VTK with CMake/ExternalProject_add against Qt with Cocoa on OS X?
I've descended into a confusing morass of complicated CMake macros, and I need help getting out! The situation is this: I didn't have much trouble building VTK with QT as long as I stuck with Carbon. Now I'm running into some serious problems (phantom dependencies on X11 libraries, for starters) when I try to use QT/Cocoa -- which is necessary, according to my boss, to build on OS X 10.6. So does anyone have a successful example of building VTK against QT using ExternalProject? 2 ___ 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] Strange search order of CMakeCache.txt
I recently had to help out a CMake newbie, who had run CMake in the source directory. Then he re-read the instructions on build setup for our programs, and did it the right way -- i.e. he configured a build directory for an out of source build. Problem is, if you run CMake and configure the source directory, CMake will assume you want an in-source build, even if you try and configure an out-of-source build directory. So you get this mystifying behavior. # sourcedir is 'test', in same directory as test-build cd test # source dir cmake # whoops, configured in the source directory! cd ../test-build# come to senses, go to out-of-srouce build. cmake ../test # try configuring for out of source build make # now you get a "Makefile not found" error! In order to get rid of the problem you have to delete CMakeCache.txt in the source directory -- at a minimum -- before you can configure the out-of-source build. I ended up going through the source code trying to get rid of CMake droppings, which are numerous! ___ 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] How do I set generated scripts executable in CMakeLists.txt?
Say I generate a script using CONFIGURE_FILE. How would I make it executable? In other words, is there a CMake way of doing this that will work on all CMake platforms? The way we deal with portability in our particular case is to use Tcl scripts. Our stuff won't work on any platform without tcl, so tclsh is the 'most portable' script processor. ___ 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] My nomination for least helpful CMake Error Message (CONFIGURE_FILE issue)
CMake Error at common/CMakeLists.txt:83 (CONFIGURE_FILE):
configure_file Problem configuring file
The issue being the CONFIGURE_FILE command:
PROJECT(SGICOMMONLIB)
#
# other stuff removed for brevity.
#
SET(DIRNAME pixmaps)
FILE(GLOB DEFAULT_CONFIG_FILES "*.xbm" ".xpm" ".gif" "*.tif" "*.pal" )
FOREACH(MODULE ${DEFAULT_CONFIG_FILES} )
GET_FILENAME_COMPONENT(CURR_FILENAME ${MODULE} NAME)
CONFIGURE_FILE(${SGICOMMONLIB_SOURCE_DIR}/${CURR_FILENAME}
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${DIRNAME}/${CURR_FILENAME} COPYONLY
IMMEDIATE )
INSTALL(FILES ${SGICOMMONLIB_SOURCE_DIR}/${DIRNAME}/${CURR_FILENAME}
DESTINATION bin/${DIRNAME})
ENDFOREACH(MODULE)
---
I think the reason I'm having this trouble is that
CMAKE_RUNTIME_OUTPUT_DIRECTORY isn't defined. But the error message
doesn't say anything useful.
___
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] How does interaction between UseXXX.cmake, XXXBuildSettings.cmake and XXXConfig.cmake supposedly work.
I use some classes of vtkINRIA3D library for an ITK/VTK/KWWidgets
application. If you haven't heard of it:
http://www-sop.inria.fr/asclepios/software/vtkINRIA3D/
I had always been building against vtkINRIA3D 'in place' -- i.e.
including the UsevtkINRIA3D.cmake from its build directory.
I'm changing this to instead install the library in a common directory
with the other prerequisite libraries for our applications. This is
primarily an issue of delivery -- it makes it marginally easier to
collect all the shared libraries our app depends on for installation.
But if I try and build against this installed copy of vtkINRIA3D, the
compiler can't find the include files. In looking at
UsevtkINRIA3D.cmake, it has this clause:
INCLUDE_DIRECTORIES(${vtkINRIA3D_INCLUDE_DIRS})
but that variable is not defined. It IS defined in
vtkINRIA3DConfig.cmake, but that file is not included by
UsevtkINRIA3D.cmake. So I assumed there was something wrong with how
vtkINRIA3D is set up or built, in that vtkINRIA3DConfig.cmake is not
included. So I looked at what ITK and VTK do, and there's a similar
setup -- I don't see where either of them include the *Config.cmake
file.
So I'm down in the maze of CMake's deep structure, lost. How is this
all supposed to work?
___
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] How do I tell a program to link against the static version of a library if both static and shared are there.
We use the Slicer Execution Model stuff from Slicer3 for command line processing. This lets Slicer3 load our programs as modules and generate user interface panels. This works really slick EXCEPT for this issue: the utility GenerateCLP which is needed to convert the command line description XML to C++ header builds shared, and depends on a shared library libModuleDescriptionParser.so. This means that GenerateCLP now will not work unless you add the directory containing the shared library to LD_LIBRARY_PATH For a while I just changed the ModuleDescriptionParser CMakeLists.txt so that it built the library static, but then I ran into a problem with that: When I needed to link the ModuleDescriptionParser library into one of my own shared libraries, the link failed because the static library wasn't compiled for position-independent code (i.e. -fPIC for gcc). So I found the trick to build both the shared and static versions in the FAQ, but GenerateCLP links to the shared version of the library when I want it to link to the static version. Is there a way in CMake to tell it to link GenerateCLP to link preferentially to the static version of the library? Oh the thousands of man-months that get expended wrestling with shared libraries ___ 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] Valgrind and CTest on OS X -- num-callers default failure
Maybe I'm out on the bleeding edge, but... I built the current .svn for valgrind on OS X 10.5.7. Then I tried to do a memory check with CTest for Insight. Every test failed with this error message: ./Testing/20090708-0100/DynamicAnalysis.xml:==81796== '--num-callers' argument must be between 1 and 50 Now if I look in the CMake source, -num-callers is set for 100. Since this doesn't fail on e.g. Linux, I have to assume that the current SVN valgrind has lowered the upper limit. ___ 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] OS X Bundle building -- adding external DYLIB files?
I was able to use this example to successfully build a standalone application. Many thanks! One thing: I had to set EXECUTABLE_OUTPUT_PATH in my CMakeLists.txt file -- otherwise when it built the install scripts that variable was empty and it wasn't finding my application at all. And with CMake 2.6.3 I get this warning: CMake Warning (dev) at cmake_install.cmake:31 (INCLUDE): Policy CMP0011 is not set: Included scripts do automatic cmake_policy PUSH and POP. Run "cmake --help-policy CMP0011" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The included script /scratch/kent/paulstretch/paulstretch-build/paulstretch_OSX_MakeStandAloneBundle.cmake affects policy settings. CMake is implying the NO_POLICY_SCOPE option for compatibility, so the effects are applied to the including context. This warning is for project developers. Use -Wno-dev to suppress it. On Tue, Apr 28, 2009 at 2:52 PM, Mike Jackson wrote: > There is also this wiki entry that might help. > > http://www.cmake.org/Wiki/BundleUtilitiesExample > > Mike Jackson > > On Tue, Apr 28, 2009 at 2:21 PM, kent williams > wrote: >> I just wrote a CMakeLists.txt file for a program that depends on a >> bunch of libraries that I had to build before building the >> application. >> >> I want to generate a deliverable OS X bundle, but I'm neither an OS X >> development expert nor a CMAKE OS X bundle expert. >> >> Simply put, I want to do the absolute minimum in order to package the >> DYLIB files in the bundle and have the application know to use those >> DYLIB files. >> >> How does one do this? >> >> Right now, the application that gets built seems to refer to these >> DYLIB files by their absolute path where I built them. This makes >> giving the program to anyone who doesn't have those libraries at >> exactly the same absolute path impossible. >> >> I have read the CMake documentation, and done some searching around >> with Google, without much enlightenment. If you think I need to just >> RTFM -- point me to TFM please ;-) >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake >> > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] OS X Bundle building -- adding external DYLIB files?
I just wrote a CMakeLists.txt file for a program that depends on a bunch of libraries that I had to build before building the application. I want to generate a deliverable OS X bundle, but I'm neither an OS X development expert nor a CMAKE OS X bundle expert. Simply put, I want to do the absolute minimum in order to package the DYLIB files in the bundle and have the application know to use those DYLIB files. How does one do this? Right now, the application that gets built seems to refer to these DYLIB files by their absolute path where I built them. This makes giving the program to anyone who doesn't have those libraries at exactly the same absolute path impossible. I have read the CMake documentation, and done some searching around with Google, without much enlightenment. If you think I need to just RTFM -- point me to TFM please ;-) ___ 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] Project structure
It's not very elegant, but this will have the desired effect: 1. make sure the library SUBDIR is in your CMakeLists.txt before any other subdir that depends on it. 2. use add_custom_command to copy the library, once built, into each subdir. 3. use install in each subdir to install the library where you want it. On Fri, Mar 13, 2009 at 1:11 PM, Daniele Galdi wrote: > Hi Alex, > > first of all thanks for the reply. > > The reason is simple, I want to distribute each tool with all the libraries > needed to run. > > You said that the library will be installed only once...is it possible to > decide where install the library > within the "CMakeFile" of each single tools? It's ok for me build one by one > each single tool, but what > I really want is to decide each time where install the shared lib. > > Hope I've been clear > > \Daniele > > > On 13 Mar, 2009, at 6:43 PM, Alexander Neundorf wrote: > >> On Friday 13 March 2009, Daniele Galdi wrote: >>> >>> Hi, >>> >>> I have a project structure like this in my cmake project. >>> >>> project/src/core-lib >>> project/src/tool1 >>> project/src/tool2 >>> project/src/tool3 >>> >>> the core library is a shared library. Each tool links this lib, what i >>> want to achieve is decide >>> where install the core-lib in each tool. eg. tool1 install core-lib >>> under /usr/lib/tool1, tool2 >>> will install the core-lib in /usr/lib/tool2 etc... >>> >>> Is this scenario possibile with cmake? >> >> No, not really. >> If this is all within one project, the library will be installed only >> once. >> You can try to setup three separate projects, then they can install to >> whereever you want. >> Why do you actually want to do that ? >> >> Alex > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] HOW TO: build development versions, plus proper INSTALL setup?
Thanks for the suggestions. I believe that if you force all your test
programs to get thrown into ${XXX_BINARY_DIR}, you could do the
ADD_TEST without specifying ${XXX_BINARY_DIR}/testname -- just
testname would suffice.
Oh and when someone says "If you can wade through the boost sources" I
draw my revolver. Boost is one of those things that has all sorts of
great goodies, but when you look at actually using it, the
build/config/etc system is a deal breaker. And you can never just use
one thing from Boost -- everything in Boost has itself been Boosted,
so it doesn't seem to ever decompose into independent modules.
Not trying to give you grief, just an observation. ;-)
On Mon, Mar 9, 2009 at 3:27 PM, Michael Jackson
wrote:
> The other items in your list looks like you have figured out so I'll just
> make a suggestion for #3:
>
> I tried the following and it does work:
>
>
> # All the following in its own CMakeLists.txt file that
> # will be called with add_subdirectory() from the top level
> # CMakeLists.txt file.
> project(UnitTests)
> add_executable(foo_test foo_test.c)
> target_link_Libraries(foo_test .. )
> set_target_properties(foo_test PROPERTIES
> RUNTIME_OUTPUT_DIRECTORY ${UnitTests_BINARY_DIR})
> add_test(foo_test ${UnitTests_BINARY_DIR}/foo_test)
>
>
> If you can wade through the Boost sources there is an experimental CMake
> build system that I believe does a lot of this. You could probably distill
> all of this down to a Macro that you could invoke to do all of the above
> with just a few arguments.
>
> Hope that helps.
> _
> Mike Jackson mike.jack...@bluequartz.net
> BlueQuartz Software www.bluequartz.net
> Principal Software Engineer Dayton, Ohio
>
>
>
> On Mar 9, 2009, at 2:49 PM, kent williams wrote:
>
>> 3. Test programs should NOT get thrown in with the actual 'product'
>> programs, and ideally stay in ${LOCALDIR_BINARY_DIR} for the local
>> project.
>
>
___
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] HOW TO: build development versions, plus proper INSTALL setup?
I think I've gotten myself needlessly tied into knots over
EXECUTABLE_OUTPUT_PATH vs RUNTIME_OUTPUT_DIRECTORY vs INSTALL command.
So maybe someone wants to talk me down about it.
We have a suite of programs that are built by a nested set of
directories. We'd like 2 things to happen (and a third if possible):
1. All the executables generated go into one binary directory. This
directory is what a developer would add to PATH in order to run
programs while he or she is adding source, debugging, etc.
2. When the whole package is installed, likewise, all programs would
go into one directory, most likely ${CMAKE_INSTALL_PREFIX}/bin
3. Test programs should NOT get thrown in with the actual 'product'
programs, and ideally stay in ${LOCALDIR_BINARY_DIR} for the local
project.
Right now, what I'm doing is this:
1. Set CMAKE_RUNTIME_OUTPUT_DIRECTORY and
CMAKE_LIBRARY_OUTPUT_DIRECTORY during the initial cmake configure.
2. using INSTALL(TARGETS ...) for programs
3. When I do an ADD_TEST, I give the test program's command as
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/testprogram, since setting
CMAKE_RUNTIME_OUTPUT_DIRECTORY doesn't discriminate between tests and
end-user programs.
So what _should_ I be doing, if I want to follow the One True CMake way?
___
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] ccmake gets all squirrelly over which C++ compiler to use.
Yeah, if you're comfortable using the Unix command line, using non-interactive CMake this way is almost always an easier path to joy than using the GUI or Curses interactive application. It's why the Slicer people spent considerable time putting together a suite of TCL scripts to do their builds, rather than ask users to configure and build many different packages. I've taken the Slicer scripts and tailored them to the BRAINS suite of applications, and have spent some time fine tuning them to the point where on supported platforms, there's no configuration necessary at all for a full development build, and there's some support for generating installable packages as well. On Tue, Mar 3, 2009 at 10:19 AM, Jed Brown wrote: > On Tue 2009-03-03 09:20, kent williams wrote: >> Lather, Rinse, Repeat. After 2 or 3 go-arounds, CCMake is happy and >> lets you generate your build files. > > This and the fact that most modules aren't written to handle multiple > passes (for instance, if the wrong version is found on the first pass, > the cache becomes corrupt) means that I frequently configure cmake > packages by repeatedly running > > $ rm -rf * && cmake .. -DVAR1=foo -DVAR2=bar > > and adding options based on the output. ___ 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] ccmake gets all squirrelly over which C++ compiler to use.
So the problem with CCMake forgetting valid user input stems from the entire CMakeCache.txt file getting deleted if there's a compiler mismatch? On Tue, Mar 3, 2009 at 11:21 AM, Bill Hoffman wrote: > Mathieu Malaterre wrote: >> >> On Tue, Mar 3, 2009 at 4:20 PM, kent williams >> wrote: >>> >>> Lather, Rinse, Repeat. After 2 or 3 go-arounds, CCMake is happy and >>> lets you generate your build files. >>> >>> And if I recall correctly, earlier versions (2.3? 2.4?) did not act this >>> way. >> >> Yup, this behavior appears exactly when 2.6.0 was released. >> Because this can be reproduce only by manual process, it may have gone >> unnoticed in the cmake regression testing... >> > OK, so to address changing a compiler from ccmake, a very common complaint > on the list. I put something in that would detect a change in compilers > from the ccmake application. If one is detected, the cache is removed > allowing for the new compiler to be used. Unfortunately, this conflicted > with some overly paranoid stuff in the VTK/ITK CMakeLists.txt files that > forces a compiler change. In hind site that was a bad idea, and there is > already a way to disable it. > > http://public.kitware.com/Bug/view.php?id=7745 > > So, if you run cmake -DCMAKE_OVERRIDE_COMPILER_MISMATCH=TRUE, or add that > variable to your cache, then the problem will go away... > > -Bill > > ___ 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] Setting environment variables prebuild
You're not missing anything per se. If you set environment variables
in your CMakeLists.txt file for some operations it's just too late. In
particular, it doesn't add commands to the build files it generates to
set the environment variables the way you need them.
You can get around this -- I think -- by setting the QNX environment
variables before you run CMake, and making sure they're set before you
try and build or use Eclipse. CMake also will honor CXX, CC, CXXFLAGS
and CFLAGS environment variables, using them to initialize the
corresponding CMAKE variables.
This is the sort of squirrelly messing about that is an inevitable
part of being a software developer. That's why they pay you the big
bucks.
On Tue, Mar 3, 2009 at 9:13 AM, Kito Berg-Taylor
wrote:
> Hello all,
>
> I'm very new to cmake, so excuse me if I'm missing some obvious
> functionality that cmake already has.
>
> I am building a project using a QNX cross-compile toolchain that I
> setup. For those not familiar with the QNX toolchain, the QNX compiler
> qcc is a wrapper around gcc that's mostly the same but has a few
> peculiarities. Of particular relevance, it requires QNX_HOST and
> QNX_TARGET (and QNX_CONFIGURATION on win32) to be set as environment
> variables. I have setup my toolchain_qnx640.cmake file to automatically
> locate the $QNX_HOST (...etc) path and then set it as follows:
>
> SET( ENV{QNX_HOST} ${PATH_TO_QNX_HOST} )
>
> This allows the configure/generate steps to work correctly, however when
> I go to build the project unless these variables are set separately in
> the environment, the build will fail. In other words, CMake is not
> setting this variable as part of the build (although it did set them
> when it went to test the compiler, because qcc passed the compiler
> test).
>
> When building from UNIX Makefiles I can set the variable at the console
> and then "make" and it will work. When using Codeblocks projects if (and
> only if) I change the project compiler to QCC Compiler it will also
> build, since Codeblocks knows how to setup the environment for QCC. I
> can't find a way to make QCC the default compiler when generating the
> project (otherwise this will get overridden every time the project is
> re-generated). Eclipse CDT projects similarly won't build, unless I mess
> around with the project settings (new to eclipse, haven't found the
> right settings yet).
>
> Am I missing something? Is this a bug/design choice?
>
> I realize that the simple answer is to just set these environment
> variables on the machines before building, but this is not always
> possible (and shouldn't be necessary).
>
> I've included the toolchain_qnx640.cmake file below in case it makes
> things a little clearer. I welcome any input...
>
> SET( CMAKE_SYSTEM_NAME Qnx )
> SET( CMAKE_SYSTEM_VERSION 6.4.0 )
> SET( CMAKE_SYSTEM_PROCESSOR x86 )
> SET( TOOLCHAIN QNX )
>
> # used to help us find the programs
> # CMAKE_EXECUTABLE_SUFFIX wasn't working
> # because it found the target suffix, which
> # is not what we want here
> IF( CMAKE_HOST_WIN32 )
> SET( HOST_EXECUTABLE_SUFFIX ".exe" )
> ENDIF( CMAKE_HOST_WIN32 )
>
> # see if we can find QNX_HOST and QNX_TARGET
> # this is not the most intelligent search, but it should
> # serve our purposes for now
> FIND_PATH( QNX_HOST
> NAME usr/bin/qcc${HOST_EXECUTABLE_SUFFIX}
> PATHS $ENV{QNX_HOST} C:/Programme/CodeBlocks/QNXSDK630/host/win32/x86
> NO_CMAKE_PATH
> NO_CMAKE_ENVIRONMENT_PATH
> )
>
> FIND_PATH( QNX_TARGET
> NAME usr/include/qnx_errno.h
> PATHS $ENV{QNX_TARGET} C:/Programme/CodeBlocks/QNXSDK630/target/qnx6
> NO_CMAKE_PATH
> NO_CMAKE_ENVIRONMENT_PATH
> )
>
> # QNX_CONFIGURATION only exists in windows
> IF( CMAKE_HOST_WIN32 )
> FIND_PATH( QNX_CONFIGURATION
> NAME bin/qnxactivate.exe
> PATHS $ENV{QNX_CONFIGURATION}
> C:/Programme/CodeBlocks/QNXSDK630/config
> NO_CMAKE_PATH
> NO_CMAKE_ENVIRONMENT_PATH
> )
> ENDIF( CMAKE_HOST_WIN32 )
>
> # export the QNX flags so that QNX can use them too
> # this is necessary for qcc to work, otherwise it will
> # complain about the license and missing QNX_HOST,QNX_TARGET
> SET( ENV{QNX_HOST} ${QNX_HOST} )
> SET( ENV{QNX_TARGET} ${QNX_TARGET} )
> IF( CMAKE_HOST_WIN32 )
> SET( ENV{QNX_CONFIGURATION} ${QNX_CONFIGURATION} )
>
> # cygwin1.dll needs to be in the PATH for qcc to run
> SET( ENV{PATH} "$ENV{PATH};${QNX_HOST}/usr/bin" )
> ENDIF( CMAKE_HOST_WIN32 )
>
> # Find some basic programs
> SET( CMAKE_MAKE_PROGRAM "${QNX_HOST}/usr/bin/make
> ${HOST_EXECUTABLE_SUFFIX}" CACHE PATH "QNX Make Program" )
> SET( CMAKE_SH "${QNX_HOST}/usr/bin/sh
> ${HOST_EXECUTABLE_SUFFIX}" CACHE PATH "QNX shell Program" )
> SET( CMAKE_AR "${QNX_HOST}/usr/bin/ntox86-ar
> ${HOST_EXECUTABLE_SUFFIX}" CACHE PATH "QNX ar Program" )
> SET( CMAKE_NM "${QNX_HOST}/usr/bin/ntox86-nm
> ${HOST_EXECUTABLE_SUFFIX}" CACHE PATH "QNX nm Program" )
> SET( CMAKE_OBJCOPY "${QNX_HOST}/usr/bin/ntox86-objcopy
> ${HOST_EXECUTABLE_SU
Re: [CMake] ccmake gets all squirrelly over which C++ compiler to use.
That's all well and good, but is exactly the sort of thing I DONT want to have to put in FOSS CMakeaLists.txt files. It would be useful in situations like this where you're liking against multiple system-installed CMake-built libraries. But any other situation, you'd run into problems where a naive user would download something, configure it and then have the build fail with obscure linker errors they're unqualified to diagnose and correct. But that's beside the point of my post, which maybe I didn't make clear: What was driving me nuts was the way that when CCMake finds an error in your configuration, IT FORGETS WHAT YOU JUST LABORIOUSLY TYPED IN THAT WAS IN FACT CORRECT. Then you have to TYPE IT IN AGAIN. Then for some reason EVEN THOUGH YOU'VE ENTERED THE CORRECT CONFIG INFORMATION, it throws a warning, and FORGETS WHAT YOU JUST TYPED IN AGAIN. Lather, Rinse, Repeat. After 2 or 3 go-arounds, CCMake is happy and lets you generate your build files. And if I recall correctly, earlier versions (2.3? 2.4?) did not act this way. On Tue, Mar 3, 2009 at 4:27 AM, Mathieu Malaterre wrote: > I have had this issue an infinite number of time. Debian packager > would be using inconsistant c++ compiler and I could not use both ITK > and VTK at the same time (from debian package). So I provided an > (undocumented) hack: > CMAKE_OVERRIDE_COMPILER_MISMATCH > > 2cts > > On Mon, Mar 2, 2009 at 8:27 PM, kent williams > wrote: >> Version 2.6 patch 2 on OS X and Linux -- you know your code is >> portable when the same issue happens on multiple platforms! >> >> Here's the scenario -- a guy in our department was having trouble >> getting ccmake to generate makefiles. >> >> My diagnosis was pretty simple: His project depended on both ITK and >> VTK. ITK had been compiled with and VTK had been compiled with >> '/usr/bin/g++'. So he got into an infinite loop where CMake would >> force the CMAKE_CXX_COMPILER to '/usr/bin/c++' when it processed >> UseITK.cmake, then when it processed UseVTK.cmake, it woud force it >> back to '/usr/bin/g++'. Then it would tell you it had to delete >> CMakeCache.txt, and re-run the Configuration pass. >> >> This turns the CCMake run into effectively an endless loop with a >> human in the loop, endlessly trying to reconfigure. >> >> The solution was obvious -- make sure both VTK and ITK use the same >> compiler Of course on most machines /usr/bin/c++ is a symbolic link to >> /usr/bin/g++ (or vice versa) but CCMake can't assume that's the >> case... >> >> But here is the real problem, the 'squirrelyness' referred to in the >> subject line: >> >> In ccmake, once VTK and ITK were built with the same compiler, I >> changed CMAKE_CXX_COMPILER to match what VTK and ITK were reporting, >> set ITK_DIR and VTK_DIR , and hit compile. >> >> But again it would pop up a warning, and when I exited the warning >> screen, CCMake had forgotten what I'd entered for CMAKE_CXX_COMPILER, >> ITK_DIR, and VTK_DIR, so I had to type them in a second time. Once I >> did that, the Configure pass would finish and I could get through the >> Generate pass. >> >> This is one specific case, but I've noticed in general that if the >> Configure pass has an error, it forgets everything you just entered >> and you have to re-enter it, and fix the error, and Configure again. >> This is extremely frustrating, like dying in a video game and having >> to go back and re-run all levels to get back to where you died. >> >> What's the story? Can this be fixed? >> ___ >> 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 >> > > > > -- > Mathieu > ___ 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] ccmake gets all squirrelly over which C++ compiler to use.
Version 2.6 patch 2 on OS X and Linux -- you know your code is portable when the same issue happens on multiple platforms! Here's the scenario -- a guy in our department was having trouble getting ccmake to generate makefiles. My diagnosis was pretty simple: His project depended on both ITK and VTK. ITK had been compiled with and VTK had been compiled with '/usr/bin/g++'. So he got into an infinite loop where CMake would force the CMAKE_CXX_COMPILER to '/usr/bin/c++' when it processed UseITK.cmake, then when it processed UseVTK.cmake, it woud force it back to '/usr/bin/g++'. Then it would tell you it had to delete CMakeCache.txt, and re-run the Configuration pass. This turns the CCMake run into effectively an endless loop with a human in the loop, endlessly trying to reconfigure. The solution was obvious -- make sure both VTK and ITK use the same compiler Of course on most machines /usr/bin/c++ is a symbolic link to /usr/bin/g++ (or vice versa) but CCMake can't assume that's the case... But here is the real problem, the 'squirrelyness' referred to in the subject line: In ccmake, once VTK and ITK were built with the same compiler, I changed CMAKE_CXX_COMPILER to match what VTK and ITK were reporting, set ITK_DIR and VTK_DIR , and hit compile. But again it would pop up a warning, and when I exited the warning screen, CCMake had forgotten what I'd entered for CMAKE_CXX_COMPILER, ITK_DIR, and VTK_DIR, so I had to type them in a second time. Once I did that, the Configure pass would finish and I could get through the Generate pass. This is one specific case, but I've noticed in general that if the Configure pass has an error, it forgets everything you just entered and you have to re-enter it, and fix the error, and Configure again. This is extremely frustrating, like dying in a video game and having to go back and re-run all levels to get back to where you died. What's the story? Can this be fixed? ___ 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] EXECUTABLE_OUTPUT_PATH is not just deprecated, it's harmful!
On Thu, Feb 19, 2009 at 4:25 PM, Brad King wrote:
>> The problem? If you're running standalone, everything's fine. If
>> you're building inside the BRAINS tree, though, the LAST
>> CMakeLists.txt file in the directory tree that sets
>> EXECUTABLE_OUTPUT_PATH wins, and consequently executable files end up
>> unexpected places.
>
> What code are you using to set it? If it doesn't get cached then each
> directory should use its own value. The only reason to cache it is if
> you want the user to be able to edit the value at CMake time.
>
The code used to set it does make it a cached value. It was part of
some boilerplate that was unfortunately propogated throughout a bunch
of projects.
The root problem is that PostDocs and grad students who are really
smart about Image Processing and advanced mathematics are sometimes
very green as Software Engineers. They see something like a
CMakeLists.txt file as an obstacle to implementing their great ideas,
not a fundamental tool of maintainable software development.
>> But this isn't the case with, for example ADD_TEST. ADD_TEST will
>> search for the named executable in a number of places, but not,
>> apparently, in CMAKE_RUNTIME_OUTPUT_DIRECTORY. So you must do your
>> add test like this
>>
>> add_test(gumby ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/gumbyTest args)
>
> FYI, I've been working on a new signature for add_test that automatically
> recognizes target names and generates the proper path for you.
>
That sounds good. Really, I'd like to configure things so that tests
stay in the project_BINARY_DIR and 'real' targets -- the ones that are
deliverable -- end up in the master bin directory, as it were. That's
actually a perfect user for SET_TARGET_PROPERTIES, right ;-)
> AFAIK the word 'deprecated' does not appear in the documentation for
> EXECUTABLE_OUTPUT_PATH.
"This variable should no longer be used as of CMake 2.6." -- I read
this as 'deprecated'. Obviously this will have to stick around, since
a lot of Kitware and other projects still use this everywhere.
___
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] EXECUTABLE_OUTPUT_PATH is not just deprecated, it's harmful!
So we have a big program (well a couple of them Brains2 and Brains3),
and a bunch of 'unbundled' programs (BRAINSFit, BRAINSDemonWarp,
BRAINSTracer etc..).
We use SVN to add the 'unbundled' programs as subdirectories of our
BRAINS svn checkout.
So our CMakeLists.txt files in our unbundled programs MUST work
properly as a standalone build, or as a sub-directory of BRAINS.
We've done this, at the cost of some slight added complexity in the
unbundled CMakeLists.txt. But one thing has REALLY been kicking my
butt since CMake 2.6 -- they each set EXECUTABLE_OUTPUT_PATH, relative
to their own CMAKE_CURRENT_BINARY_DIR
The problem? If you're running standalone, everything's fine. If
you're building inside the BRAINS tree, though, the LAST
CMakeLists.txt file in the directory tree that sets
EXECUTABLE_OUTPUT_PATH wins, and consequently executable files end up
unexpected places.
So I've had to go through and change everywhere that variable occurs
with CMAKE_RUNTIME_OUTPUT_DIRECTORY, and replace LIBRARY_OUTPUT_PATH
with CMAKE_LIBRARY_OUTPUT_DIRECTORY.
Now, ideally, you should be able set those CMAKE_*_OUTPUT_DIRECTORY
variables in your top level Makefile, and then the path properties for
targets are set, and everybody's happy.
But this isn't the case with, for example ADD_TEST. ADD_TEST will
search for the named executable in a number of places, but not,
apparently, in CMAKE_RUNTIME_OUTPUT_DIRECTORY. So you must do your
add test like this
add_test(gumby ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/gumbyTest args)
So I guess the question is this -- how should I manage this issue?
Since EXECUTABLE_OUTPUT_PATH is deprecated, it looks like it has
functionally been replaced by CMAKE_RUNTIME_OUTPUT_DIRECTORY. It's
also subject to the same problem if any CMakeLists.txt file set it
incorrectly somewhere in a build tree.
___
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] Using CMake to bootstrap a build source tree via CVS/SVN
Right now we have a Slicer3 style 'getbuildtest' script to check out a bunch of Kitware packages in order to build an application. This basically works like this for all packages, check out the package configure it with cmake build it. Since the 'configure it with cmake' step is redundant over a series of patches, it seems like you should be able to user CMake to manage the whole process, but I'm not sure that's true. What I'd like to end up with the CMakeLists.txt file below. The question is this: I can certainly run CVS or SVN with EXECUTE_PROCESS, but will that happen early enough in the CMake config process that the ADD_SUBDIRECTORY clauses will be able to actually find the checked out subdirectories? Or should I just punt and have a 'check everything out' script I run before running CMake? PROJECT(MyProjectBuild) # # check out all the source from various places # # set all CMake variables for the packages ADD_SUBDIRECTORY(tk) ADD_SUBDIRECTORY(tcl) ADD_SUBDIRECTORY(Insight) ADD_SUBDIRECTORY(VTK) ADD_SUDIRECTORY(vtkinria3d) ADD_SUBDIRECTORY(MyProject) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Q: How do I _portably_ create a directory in the binary directory
Never mind, I found it in the 'FILE' command...
On Fri, Sep 19, 2008 at 10:26 AM, kent williams
<[EMAIL PROTECTED]> wrote:
> I am CMake-izing a non-CMake project -- or rather we have CMake-ized
> it, and are doing some clean up.
>
> We have a testing shell script that I'm converting to CTest tests.
> The first thing it does is create a directory where it drops all the
> testing output.
>
> I'd like to do the same thing -- create a directory as a child of
> ${CMAKE_BINARY_DIR} to drop files created via testing.
>
> How do I do that in CMake? I've done some googling and reading
> through the documentation without seeing any clues.
>
> I know that CMake itself uses portable routines (from kwsys) to make
> directories, but that isn't exposed anywhere.
>
> Do I need to write a CMake Macro for this, so that Unix and OSX do
>
> mkdir -p "${PATH_TO_MAKE}"
>
> and Windows does
>
> cmd.exe /e:on /c mkdir "${PATH_TO_MAKE}"
>
> ?
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Q: How do I _portably_ create a directory in the binary directory
I am CMake-izing a non-CMake project -- or rather we have CMake-ized
it, and are doing some clean up.
We have a testing shell script that I'm converting to CTest tests.
The first thing it does is create a directory where it drops all the
testing output.
I'd like to do the same thing -- create a directory as a child of
${CMAKE_BINARY_DIR} to drop files created via testing.
How do I do that in CMake? I've done some googling and reading
through the documentation without seeing any clues.
I know that CMake itself uses portable routines (from kwsys) to make
directories, but that isn't exposed anywhere.
Do I need to write a CMake Macro for this, so that Unix and OSX do
mkdir -p "${PATH_TO_MAKE}"
and Windows does
cmd.exe /e:on /c mkdir "${PATH_TO_MAKE}"
?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Mysterious build error that seems to have been slipstreamed into CMake 2.6
By the way the problem is fixed by changing CMake/Source/CMakeLists.txt to build the file that defines GetInstalledSizeInKBytes. *** CMakeLists.txt 14 Jul 2008 10:36:50 -0500 1.397.2.2 --- CMakeLists.txt 14 Jul 2008 10:52:08 -0500 *** *** 348,353 --- 348,354 # SET(CPACK_SRCS CPack/cmCPackGeneratorFactory.cxx + CPack/cmCPackComponentGroup.cxx CPack/cmCPackGenerator.cxx CPack/cmCPackLog.cxx CPack/cmCPackNSISGenerator.cxx On Mon, Jul 14, 2008 at 10:23 AM, kent williams <[EMAIL PROTECTED]> wrote: > We have an application based on the Slicer3 build. The Slicer3 build > downloads and builds CMake. We currently grab CMake with this command > > cvs -q -d :pserver:[EMAIL PROTECTED]:/cvsroot/CMake checkout -r > CMake-2-6 CMake > > If I understand that correctly we're asking for the release tag of > 2.6. But up until today CMake built without problems and now I'm > getting this build error: > > Linking CXX executable ../bin/cpack > /usr/bin/ld: Undefined symbols: > cmCPackComponent::GetInstalledSizeInKbytes(char const*) const > collect2: ld returned 1 exit status > make[2]: *** [bin/cpack] Error 1 > make[1]: *** [Source/CMakeFiles/cpack.dir/all] Error 2 > make: *** [all] Error 2 > > Are there changes being 'slipstreamed' into 2.6? > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Mysterious build error that seems to have been slipstreamed into CMake 2.6
We have an application based on the Slicer3 build. The Slicer3 build downloads and builds CMake. We currently grab CMake with this command cvs -q -d :pserver:[EMAIL PROTECTED]:/cvsroot/CMake checkout -r CMake-2-6 CMake If I understand that correctly we're asking for the release tag of 2.6. But up until today CMake built without problems and now I'm getting this build error: Linking CXX executable ../bin/cpack /usr/bin/ld: Undefined symbols: cmCPackComponent::GetInstalledSizeInKbytes(char const*) const collect2: ld returned 1 exit status make[2]: *** [bin/cpack] Error 1 make[1]: *** [Source/CMakeFiles/cpack.dir/all] Error 2 make: *** [all] Error 2 Are there changes being 'slipstreamed' into 2.6? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] "another target with the same name exists"
Am I insane, or is CMake?
In a subdirectory of our big ol build tree, CMake is freaking out
about duplicate targets in a way that makes no sense to me:
CMake Error at src/iplProg/AutoSeg/ProcessDescription/CMakeLists.txt:3
(ADD_LIBRARY):
add_library cannot create target "ProcessDescription" because another
target with the same name already exists. The existing target is a static
library created in source directory
"/scratch/kent/brains2/src/iplProg/AutoSeg/ProcessDescription". See
documentation for policy CMP0002 for more details.
Here is the entirety of the 'offending' CMakeLists.txt:
FILE (GLOB ProcessDescription_SRC *.cxx)
ADD_LIBRARY(ProcessDescription ${ProcessDescription_SRC})
Grepping through all the CMakeLists.txt in our source tree, that is
the only place that library is cited as a target.
Note that 'src/iplProg/AutoSeg/ProcessDescription' is the same
directory as "/scratch/kent/brains2/src/iplProg/AutoSeg/ProcessDescription"
I read the CMP0002 policy description, and I don't see how it applies
in this particular case. CMake is acting as though it's incorrectly
detecting a target as having been defined twice in exactly the same
place in the same CMakeLists.txt.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bump -- CMAKE_INSTALL_PREFIX weirdness.
http://public.kitware.com/Bug/view.php?id=7084 I made the simplest possible library project, and then messed it up based on our build system just enough to reproduce the error. ;-) Now obviously, what is done in this project -- Calling Cmake from make to batch-configure projects -- might be off-label usage for CMake. But the little test project demonstrates something annoying and a bit disturbing: Running cmake twice with the same command line parameters works for an empty build directory, and fails for an already existing build directory. On Fri, May 23, 2008 at 9:33 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > Sounds like a bug. Do you think you can create a small script that > reproduces the problem? > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bump -- CMAKE_INSTALL_PREFIX weirdness.
There seems to be something unique about our build system that is causing this problem, and I am beginning to suspect what it is: It calls cmake to do a command-line configure even if the build directory is already configured. This is kind of ridiculous to do, I know, but for one thing, the configure target in the Makefile depends on the Makefile itself, with the rationale that if you change the Makefile, then you're conceivably changing the flags passed in to CMake, so you should call CMake again to make sure. For another, our gnu-make build system is 10+ years old and has turned into a giant ball of tangled barbed wire. I think I can fix the problem by deleting the CMakeCache.txt file before the call to cmake. But should I have to do this? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bump -- CMAKE_INSTALL_PREFIX weirdness.
I'm getting these results with cmake version 2.6-patch 0 On Fri, May 23, 2008 at 8:50 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > Also, what version of CMake are we talking about here? There were bugs in > some versions of CMake with the -D and the cache. Perhaps it works when you > use the right versions of CMake. > > -Bill > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Bump -- CMAKE_INSTALL_PREFIX weirdness.
I'll ask this again. We use a build system that for better or worse, invokes cmake from a Makefile to configure ITK, VTK, KWWidgets etc. In other words we have a command invoked from gnu make that looks like this: cmake /scratch/kent/brains2/iplFreeware/unpackdir/Insight -DCMAKE_INSTALL_PREFIX:PATH=/scratch/kent/brains2/MACOSX/DEBUG/src \ -DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_CXX_COMPILER:FILEPATH="c++ " \ -DCMAKE_CXX_FLAGS:STRING=" -bind_at_load -g -UNDEBUG -Wall -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION " -DCMAKE_CXX_FLAGS_RELEASE:STRING=" -bind_at_load -g -UNDEBUG -Wall -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION " -DCMAKE_CXX_FLAGS_DEBUG:STRING=" -bind_at_load -g -UNDEBUG -Wall -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION " etc etc etc. The problem is that about half the time, the CMakeCache.txt file gets written with CMAKE_INSTALL_PREFIX as /usr/local, even though it has been overriden on the command line. This happens with ITK, VTK, KWWidgets, etc. The workaround is when the build dies, delete CMakeCache.txt, and run the build again. My boss ran into the same problem on his system so it isn't something I've screwed up on my machine. He asked me "did you log a bug with Kitware about it?" and the answer was "no" -- I've tried making a simple example that illustrates the problem, and the problem doesn't occur. But I'm at a loss as to how we've gotten this Heisenberg problem, where sometimes CMake writes the wrong Path into the build. Any suggestions on how to debug this? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to deal with silly custom Gnu Make recipes with CMake
I won't name the package because I find this construction really
stupid, but I'm writing CMakeLists.txt files for a package we want to
use and came across this:
%_floof: %.c
$(CC) $(CFLAGS) -DFLOOF -o $@ -lfloof
So I don't really see how CMake could do something like this. And
that doesn't even adding C Preprocessor definitions to the command
line, which is hard to do portably.
What I ended up doing is this Unix-only workaround:
PROJECT(EXAMPLE)
add_custom_command(OUTPUT test_floof.c
COMMAND echo '\#define FLOOF 1' >
${EXAMPLE_BINARY_DIR}/test_floof.c
COMMAND cat ${EXAMPLE_SOURCE_DIR}/test.c >>
${EXAMPLE_BINARY_DIR}/test_floof.c
DEPENDS ${EXAMPLE_SOURCE_DIR}/test.c
)
ADD_EXECUTABLE(test_floof ${EXAMPLE_BINARY_DIR}/test_floof.c)
TARGET_LINK_LIBRARIES(test_floof floof)
This seems incredibly rickety. Is there an elegant way to do this?
And am I missing something in the CMake documentation, but it's
confusing to me how you'd write a custom command that would be general
-- i.e. replace the Gnu Make pattern rules as given above.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] What the... Can't seem to change CMAKE_INSTALL_PREFIX
We call cmake from inside our top level Makefile to build ITK. To that end we specify the CMAKE_INSTALL_PREFIX on the command line. I've appended our whole cmake command line at the end of this message but the operative thing is that the CMake command line includes: -DCMAKE_INSTALL_PREFIX:PATH=/scratch/kent/brains2/MACOSX/DEBUG/src But try as I might, the CMakeCache.txt after configuring Insight contains this: //Install path prefix, prepended onto install directories. CMAKE_INSTALL_PREFIX:PATH=/usr/local What the heck is going on here? This is using a recent snapshot if ITK CVS. make -f Makefile.brains2 /scratch/kent/brains2/MACOSX/DEBUG/src/lib/InsightToolkit/ITKBuildSettings.cmake mkdir -p /scratch/kent/brains2/iplFreeware/MACOSX/DEBUG/Insight; cd /scratch/kent/brains2/iplFreeware/MACOSX/DEBUG/Insight && CMAKE_LIBRARY_PATH=/usr/X11R6/lib:/usr/lib:/scratch/kent/brains2/MACOSX/DEBUG/src/lib /scratch/kent/opt/bin/cmake /scratch/kent/brains2/iplFreeware/unpackdir/Insight \ -DCMAKE_INSTALL_PREFIX:PATH=/scratch/kent/brains2/MACOSX/DEBUG/src -DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_CXX_COMPILER:FILEPATH="c++ " -DCMAKE_CXX_FLAGS:STRING=" -bind_at_load -g -UNDEBUG -Wall -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION " -DCMAKE_CXX_FLAGS_RELEASE:STRING=" -bind_at_load -g -UNDEBUG -Wall -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION " -DCMAKE_CXX_FLAGS_DEBUG:STRING=" -bind_at_load -g -UNDEBUG -Wall -Wcast-qual -UITKIO_DEPRECATED_METADATA_ORIENTATION " -DCMAKE_LD_FLAGS:STRING="" -DCMAKE_C_COMPILER:FILEPATH="cc " -DCMAKE_C_FLAGS:STRING=" -bind_at_load -g -UNDEBUG -Wall -Wstrict-prototypes -UITKIO_DEPRECATED_METADATA_ORIENTATION " -DCMAKE_EXE_LINKER_FLAGS:STRING=" -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib" -DCMAKE_MODULE_LINKER_FLAGS:STRING=" -r -c -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib" -DCMAKE_SHARED_LINKER_FLAGS:STRING=" -r -c -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib" -DBUILD_SHARED_LIBS:BOOL=OFF -DCMAKE_USE_PTHREADS:BOOL=ON -DCMAKE_USE_SPROC:BOOL=OFF -DMEMORYCHECK_COMMAND_OPTIONS:STRING="--verbose --suppressions=/scratch/kent/brains2/ValgrindSuppression.supp" -DSITE:STRING=golgi.uiowa -DBUILDNAME:STRING=Darwin-c++-4.0-dbg -DDART_TESTING_TIMEOUT:STRING=6500 \ -DTCL_INCLUDE_PATH:PATH=/scratch/kent/brains2/MACOSX/DEBUG/src/include -DTCL_LIBRARY:FILEPATH=/scratch/kent/brains2/MACOSX/DEBUG/src/lib/libtcl8.4BRAINSg.a -DTCL_STUB_LIBRARY:FILEPATH=/scratch/kent/brains2/MACOSX/DEBUG/src/lib/libtclstub8.4BRAINSg.a -DTCL_TCLSH:FILEPATH=/scratch/kent/brains2/MACOSX/DEBUG/src/bin/tclsh8.4 -DTK_INCLUDE_PATH:PATH=/scratch/kent/brains2/MACOSX/DEBUG/src/include -DTK_LIBRARY:FILEPATH=/scratch/kent/brains2/MACOSX/DEBUG/src/lib/libtk8.4BRAINSg.a -DTK_STUB_LIBRARY:FILEPATH=/scratch/kent/brains2/MACOSX/DEBUG/src/lib/libtkstub8.4BRAINSg.a \ -DFFTW_INCLUDE_PATH:PATH=/scratch/kent/brains2/MACOSX/DEBUG/src/include -DFFTWD_LIB:FILEPATH=/scratch/kent/brains2/MACOSX/DEBUG/src/lib/libfftw3.a -DFFTWF_LIB:FILEPATH=/scratch/kent/brains2/MACOSX/DEBUG/src/lib/libfftw3f.a -DUSE_FFTWF:BOOL=ON -DUSE_FFTWD:BOOL=OFF -DUSE_SCSL:BOOL=OFF \ -DBUILD_FEM_CODE:BOOL=OFF \ -DBUILD_FEM_MESH_EXAMPLE:BOOL=OFF \ -DBUILD_METAIMAGE:BOOL=ON \ -DBUILD_AUXILIARY:BOOL=OFF \ -DBUILD_EXAMPLES:BOOL=OFF \ -DBUILD_TESTING:BOOL=OFF \ -DITK_USE_TRANSFORM_IO_FACTORIES:BOOL=ON \ -DITK_USE_OPTIMIZED_REGISTRATION:BOOL=ON \ -DITK_USE_STRICT_CONCEPT_CHECKING:BOOL=ON \ -DITK_USE_REVIEW:BOOL=ON \ -DBUILD_VTKINTERFACE:BOOL=ON \ -DFLTK_APPLE:BOOL=ON -DOPENGL_INCLUDE_DIR:PATH=/usr/X11R6/include -DOPENGL_gl_LIBRARY:STRING="-framework OpenGL;/usr/X11R6/lib/libGL.dylib" \ -DFEM_USE_SMART_POINTERS:BOOL=OFF \ -DITK_USE_SYSTEM_STDLIB:BOOL=ON \ -DITK_EXPLICIT_INSTANTIATION:BOOL=OFF \ -DITK_WRAP_TCL:BOOL=OFF \ -DITK_CSWIG_TCL:BOOL=OFF \ -DITK_CSWIG_PYTHON:BOOL=OFF \ -DGDCM_LEGACY_REMOVE:BOOL=ON \ -DITK_LEGACY_REMOVE:BOOL=ON \ -DITK_CSWIG_JAVA:BOOL=OFF ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] qmake to cmake
Check http://www.cmake.org/HTML/Documentation.html for the CMake INCLUDE_DIRECTORIES claus. You can have multiple INCLUDE_DIRECTORIES clauses, and they're inherited in subdirectories. On 10/12/07, Ajay Divekar <[EMAIL PROTECTED]> wrote: > Experts, > > I was wondering how do I pass the include directories (-I option) and the -D > option to the files that being moc'd ? I am using qt4_wrap_cpp function to > generate the moc_x.cxx files. > > Thanks in advance. > > Regards, > > Aj > > > On 10/10/07, Marie-Christine Vallet <[EMAIL PROTECTED]> wrote: > > Brandon Van Every wrote: > > > On 10/10/07, Ajay Divekar <[EMAIL PROTECTED]> wrote: > > > > > >> Hello Experts, > > >> > > >> I found this ruby script on > > >> > > >> http://www.cmake.org/Wiki/CMake:ConvertFromQmake > > >> > > >> which helps in converting from qmake to cmake. Has anyone tried it and > if > > >> so what has been there experience? Also before I start if anyone has > any > > >> suggestion they are welcome. > > >> > > > > > > > > Hi, > > I am no expert but I used this converted, and ended up doing some > > modifications by hand. > > But if your .pro files are not too complex, it's pretty straightforward. > > Marie > > > > ___ > > CMake mailing list > > CMake@cmake.org > > http://www.cmake.org/mailman/listinfo/cmake > > > > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest results without submitting
If you only want to see whether tests succeed or fail, then you just need to go to the build directory and type make test Or you can run ctest directly ctest If you want to see the output of your tests, then run ctest -V If you only care about one test ctest -R testname_regexp i.e. give a regular expression matching all or part of the names of tests you wish to run. If you want a local dashboard, I don't know the answer to your question. It would require faking the submission to a server, then running the dashboard roll-up locally. You might better ask this question on the DART mailing list. On 10/11/07, Baptiste Derongs <[EMAIL PROTECTED]> wrote: > Hello all, > > I am running a lot of tests with Ctest, and I would like to gather the > results. However I do not want to send them to a Dart server (not > really I do not want, but that is not the easiest way for me). > > So I made a CTestConfig.cmake with some weird commands that make > Ctests -D unable to find where to submit, and next I just get .xml > files. That works, but I was wondering if there is no better solution, > like a --create-xml-results option (I am quite sure this one doesn't > exist...). > > Regards > > Baptiste > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake, CPack, RPM
Thanks for your prompt reply. To some extent you're answering
questions that come from me being an RPM newbie.
My problem with the Source RPM generation is that it requires that my
system -- the one building the source RPM, doesn't have CMake
installed as an RPM.When I try and generate the source RPM, the
build process fails because it doesn't detect a CMake RPM package on
my system.
It would seem to me that the dependencies of the Source RPM shouldn't
affect the system building the RPM this way. I should be able to
generate the source RPM, specify that I need ITK, VTK, KWWidgets, and
CMake.
Is CPack/CMake complaining about this or is it rpmbuild? If it's
rpmbuild, there's not much we can do, but it seems spurious to require
the building system to have RPMs installed that won't be needed until
the target system tries to build the RPM.
On 10/11/07, Eric Noulard <[EMAIL PROTECTED]> wrote:
> 2007/10/10, kent williams <[EMAIL PROTECTED]>:
> > OK, so... if I use the built in RPM generator it will generate an RPM.
> > It isn't clear to me what ends up in that RPM aside from the files in
> > the manifest -- no dependencies seem to be mentioned.
>
> That's almost true.
> RPM generator cannot guess your dependencies and
> will package all files which are INSTALL() in your CMakeLists.txt files.
> You'll get some dependencies because CPack RPM use
> rpmbuild command to build the RPM and this command
> try it's best to add "guessable" binary dependencies.
>
> > Using UseRPMTools.cmake to try and generate a source RPM doesn't work
> > so hot. You can only make a source RPM if there's a package 'cmake' in
> > the RPM database apparently. If you haven't installed such an RPM (and
> > I'm not sure who installs CMake from an RPM) you're SOL, even if you
> > do have CMake installed and available.
>
> The specs file generated by UseRPMTools
> include the requirement:
>
> BuildRequires: cmake
>
> This is "logical" since the Source RPM you will build
> precisely WILL NEED cmake to produce the binary RPM.
>
> Many RPM based distros I know DO provide cmake prebuilt RPM.
> I don't yours but you may try: http://rpm.pbone.net/ in order
> to see if you can find one.
>
> >
> > Which is kind of a cart-before-horse situation. Obviously you have
> > CMake installed, if you're using CMake to build the RPM. On the other
> > hand, you probably should require CMake as a prerequisite.
>
> You get it.
> That's why CPack builtin RPM don't put *any* requirement,
> using CPack buitlin RPM you should be able to build a binary RPM
> (including CMake RPM itself if you compile CMake yourself).
>
>
> > This particular program requires ITK, VTK, KWWidgets, (header and
> > libs) and CMake (executable) at a minimum for a source distribution.
> > For a binary distribution you don't need CMake, but you do need all
> > the SO Libraries from ITK, VTK, KWWidgets. Not sure how I'd put that
> > into the spec files.
>
> If you use either CPack built-in RPM or UseRPMTools macro
> you are able to specify your own .spec file which may include
> your requirement.
> See http://wiki.rpm.org/Docs for informations about the content
> of a spec file.
>
> For example for RPMTools:
>
> RPMTools_ADD_RPM_TARGETS(packagename)
>
> will generate a "minimal" spec file for you
> whereas
> RPMTools_ADD_RPM_TARGETS(packagename ${CMAKE_SOURCE_DIR}/package.spec)
>
> will use the provided spec file.
>
> Using CPack built-in RPM
> SET(RPM_USER_BINARY_SPECFILE )
> will provide the user spec file to the generator.
> Currently this may not work because:
> http://www.cmake.org/pipermail/cmake/2007-September/016606.html
>
> The trouble is that nor CPack nor UseRPMTools may guess
> the requirement you probably "manually" set-up using
> a bunch of FIND_PACKAGE + TARGET_LIBRARY +...
>
> May be I can think about a way to "only specify" dependencies
> and not the "whole spec file".
>
> I don't know if I would have time for working on this, by the end of this week
> but I may give it a try next week.
>
> --
> Erk
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake, CPack, RPM
OK, so... if I use the built in RPM generator it will generate an RPM. It isn't clear to me what ends up in that RPM aside from the files in the manifest -- no dependencies seem to be mentioned. Using UseRPMTools.cmake to try and generate a source RPM doesn't work so hot. You can only make a source RPM if there's a package 'cmake' in the RPM database apparently. If you haven't installed such an RPM (and I'm not sure who installs CMake from an RPM) you're SOL, even if you do have CMake installed and available. Which is kind of a cart-before-horse situation. Obviously you have CMake installed, if you're using CMake to build the RPM. On the other hand, you probably should require CMake as a prerequisite. This particular program requires ITK, VTK, KWWidgets, (header and libs) and CMake (executable) at a minimum for a source distribution. For a binary distribution you don't need CMake, but you do need all the SO Libraries from ITK, VTK, KWWidgets. Not sure how I'd put that into the spec files. make ImageEval_srpm CPack: Create package using TGZ CPack: Install projects CPack: - Install directory: /scratch/kent/temp/slicer/ImageEval CPack: Compress package CPack: Finalize package CPack: Package /scratch/kent/temp/slicer/ImageEval-build/ImageEval-1.0.0-Source.tar.gz generated. error: Failed build dependencies: cmake is needed by ImageEval-1.0.0-1.i386 make[3]: *** [CMakeFiles/ImageEval_srpm] Error 1 make[2]: *** [CMakeFiles/ImageEval_srpm.dir/all] Error 2 make[1]: *** [CMakeFiles/ImageEval_srpm.dir/rule] Error 2 make: *** [ImageEval_srpm] Error 2 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] how broken is the RPM support?
I just installed the CVS CMake. There is a CPackRPM.cmake file in the Modules directory, but it's not clear to me how to tell CPack I want to generate an RPM, or a Source RPM. Anyone have any clues for me? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake version 2.5-20060616 -- INSTALL(DIRECTORY ...) broken?
No, not silly advice. I just use the documentation on cmake.org out of habit, and they apparently don't keep it up to date. For a while, apparently, during 2.4 CMake, there was an INSTALL(DIRECTORY ) form available and they got rid of it. A pity because other than that, there is no portable way to simply copy a directory tree to an installation directory. I did it the hard way around, putting a CMakeLists.txt in every subdirectory that needs to be copied, with an INSTALL(FILES ) command that lists all the files in that directory... On 5/22/07, David Cole <[EMAIL PROTECTED]> wrote: Then the subject line of your original email is a typo? I'm sorry if I offered silly advice, I thought you were using CMake 2.5-20060616... On 5/22/07, kent williams <[EMAIL PROTECTED]> wrote: > Um, I use a newer CMake, just read the docs on CMake.org which are > apparently older? > > On 5/22/07, David Cole <[EMAIL PROTECTED]> wrote: > > 20060616 is a snapshot from CVS that is almost a year old now. You should > > use the --help with your local CMake for what existed in CMake as of that > > time... > > > > Or - better yet - update to a more current CMake. > > > > HTH, > > David > > > > > > > > On 5/22/07, kent williams <[EMAIL PROTECTED]> wrote: > > > > > > According to the man pages for 2.4-patch 7 RC-6 on CMake.org, there is > > > a form of the INSTALL command for directories. After reading through > > > the description, I added a command to install a subdirectory into the > > > bin install directory: > > > > > > INSTALL(DIRECTORY pipeline_approved DESTINATION bin) > > > > > > i.e. pipeline_approved is a directory in the same directory as my > > > CMakeLists.txt, and I want the file to go into the installation tree > > > bin directory. > > > > > > But when I run CMake, I get this message: > > > > > > CMake Error: Error in cmake code at > > > > > /Volumes/Scratch/kent/brains2/src/iplProg/CMakeLists.txt:61: > > > INSTALL called with unknown mode DIRECTORY > > > -- cmake src dir = /Volumes/Scratch/kent/brains2 > > > > > > What's up with that? > > > ___ > > > CMake mailing list > > > CMake@cmake.org > > > http://www.cmake.org/mailman/listinfo/cmake > > > > > > > > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake version 2.5-20060616 -- INSTALL(DIRECTORY ...) broken?
Um, I use a newer CMake, just read the docs on CMake.org which are apparently older? On 5/22/07, David Cole <[EMAIL PROTECTED]> wrote: 20060616 is a snapshot from CVS that is almost a year old now. You should use the --help with your local CMake for what existed in CMake as of that time... Or - better yet - update to a more current CMake. HTH, David On 5/22/07, kent williams <[EMAIL PROTECTED]> wrote: > > According to the man pages for 2.4-patch 7 RC-6 on CMake.org, there is > a form of the INSTALL command for directories. After reading through > the description, I added a command to install a subdirectory into the > bin install directory: > > INSTALL(DIRECTORY pipeline_approved DESTINATION bin) > > i.e. pipeline_approved is a directory in the same directory as my > CMakeLists.txt, and I want the file to go into the installation tree > bin directory. > > But when I run CMake, I get this message: > > CMake Error: Error in cmake code at > /Volumes/Scratch/kent/brains2/src/iplProg/CMakeLists.txt:61: > INSTALL called with unknown mode DIRECTORY > -- cmake src dir = /Volumes/Scratch/kent/brains2 > > What's up with that? > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake version 2.5-20060616 -- INSTALL(DIRECTORY ...) broken?
According to the man pages for 2.4-patch 7 RC-6 on CMake.org, there is a form of the INSTALL command for directories. After reading through the description, I added a command to install a subdirectory into the bin install directory: INSTALL(DIRECTORY pipeline_approved DESTINATION bin) i.e. pipeline_approved is a directory in the same directory as my CMakeLists.txt, and I want the file to go into the installation tree bin directory. But when I run CMake, I get this message: CMake Error: Error in cmake code at /Volumes/Scratch/kent/brains2/src/iplProg/CMakeLists.txt:61: INSTALL called with unknown mode DIRECTORY -- cmake src dir = /Volumes/Scratch/kent/brains2 What's up with that? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] can I run individual tests with valgrind?
I know that I can use valgrind for a nightly memory check with ctest -D NightlyMemoryCheck or if I know my build is successful, just do this ctest -D NightlyMemCheck What I don't know is how I can make running a single test, e.g. ctest -R OneParticularRegressionTest with valgrind, short of running valgrind --trace-children=yes ctest -r OneParticularRegressionTest ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CTestCustom.ctest not working?
I added a CTestCustom.ctest file to my build directory as suggested on
the CMake website, and it doesn't appear to be doing what it is supposed to.
I'll include my CTestCustom.ctest file below, but basically I want to
suppress warning messages that occur because of third party libraries
built outside our application. I used the CONFIGURE_FILE command to
copy it into the build directory.
Is this feature still kind of broken?
My CTestCustom.ctest file:
SET(CTEST_CUSTOM_WARNING_MATCH
${CTEST_CUSTOM_WARNING_MATCH}
"{standard input}:[0-9][0-9]*: Warning: "
)
SET(CTEST_CUSTOM_WARNING_EXCEPTION
${CTEST_CUSTOM_WARNING_EXCEPTION}
"Fl_Menu_Item\.H"
"FiberTrackingGUI\.cxx"
"has no symbols"
"itkConnectedComponentImageFilter\.txx(.*)comparison between signed
and unsigned"
"mac\.H(.*)deprecated"
"itkFixedArray\.h(.*)cast from"
"vxl(.*)support for exported templates is disabled"
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Is it possible to use ADD_TEST to execute multiple commands
Here's the problem. I have a test that invokes an external program. So I have this in my CMakeLists.txt ADD_TEST(ExampleTest exampleprogram a b c) The problem is that exampleprogram requires the first parameter to be the name of an output file, and will exit with an error return code if that file already exists. My 'naive' solution would be this: ADD_TEST(ExampleTest rm -f a ; exampleprogram a b c) which would essentially be a 2-command shell script. This does not work, and I tried a lot of different ways to get the test to generate a command that would remove a file, and then run the test. Any suggestions? Thanks in advance! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Coverage -- What is happening when you run a binary more than once?
For the NIfTI regression tests, we run a binary for each ADD_TEST -- i.e. we build, e.g. a program called nifti1_test. Then each test is of the form ADD_TEST(exampletest $(NIFTIUTILS_BINARY_DIR}/nifti1_test --testname exampletest) There are about 10 different executions of nifti1_test every time you do a 'make test'. When you have coverage turned on, doesn't each execution overwrite the previous coverage data file? If so, we're only getting coverage results for the last execution of nifti1_test, or am I missing something? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
