Re: [CMake] Cmake replacement for AC_SEARCH_LIBS?

On 25.02.09 18:39:20, Steve Huston wrote: I'm working on replacing a autoconf/automake build with Cmake. One thing I'm stuck on is replacing AC_SEARCH_LIBS. For example: AC_SEARCH_LIBS(dlopen, [dl], [test $ac_cv_search_dlopen = none required ||

Re: [CMake] Generating shell script through cmake

2009/2/26 ankit jain ankitgu...@gmail.com: Hi, I want to generate a shell script which should be executable through three files. first file has some macros with other functions and other code. Second and third file haev definitions fot he macro the functions. Can i generate a shell script

[CMake] automatically re-generating makefiles

Hi there, I've noticed that when I run make blah then the makefile is automatically re-generated if I've changed anything in CMakeLists.txt since the last time I built blah. However, if I add a new target to CMakeLists.txt then I have to run cmake manually or else I just get to rule to make foo.

Re: [CMake] automatically re-generating makefiles

2009/2/26 Alex Flint alex.fl...@gmail.com: Hi there, I've noticed that when I run make blah then the makefile is automatically re-generated if I've changed anything in CMakeLists.txt since the last time I built blah. However, if I add a new target to CMakeLists.txt then I have to run cmake

[CMake] SunCC bypass linker in trycompile

Hello, I'm am trying the SunStudio compiler on linux. Due to an issue with their linker, I need to pass an option to use the default system linker. How do I tell cmake to use the Qpath option below for both trycompile and my project. CC -Qpath /usr/bin Thanks, Juan Linking CXX executable

Re: [CMake] Adding extensions to AUX_SOURCE_DIRECTORY

Reisinger, Thomas Karl wrote: Hello, AUX_SOURCE_DIRECTORY by default searches for the following extensions - .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx Because CMake works case sensitive I need to ADD another extension .CPP to the command AUX_SOURCE_DIRECTORY.

Re: [CMake] problem with add_custom_command / add_custom_target in different directories

Philip Lowman wrote: Brad King wrote: I suggest making the extraction rule generate a stamp file with cmake -E touch Thanks for pointing out those two problems. Not too worried about either of them at the moment given what this is intended for. Another thing did concern me which was

Re: [CMake] using two different compilers together

Bill: Thanks for the pointer, it's working brilliantly Alex: Thanks for the suggestions even though I ended up going with findcuda On Wed, Feb 25, 2009 at 8:45 PM, Bill Hoffman bill.hoff...@kitware.com wrote: There is a FindCuda.cmake here, that I have looked at:

[CMake] Memory checking MPI programs with valgrind?

Hello, Does anyone know how to get CMake/CTest to do memory testing with MPI programs using valgrind? The problem is that by default valgrind just tests the mpiexec/mpirun driver program and not your user program. I think there are some options you can pass to valgrind to get it to do this

[CMake] MAC OXS linking problem : -lcrt1.10.5.o not found

Hello, I am new to CMake. I want to compile under Mac OSX 10.5 Server demo application from the Ogre3D package. After some tweaking : *installation of Ogre frameworks in correct directories I end up with the following message: Linking CXX executable CubeMapping.app/Contents/MacOS/CubeMapping

Re: [CMake] MAC OXS linking problem : -lcrt1.10.5.o not found

On 2/26/09 4:07 PM, Benoit Callebaut said: I end up with the following message: Linking CXX executable CubeMapping.app/Contents/MacOS/CubeMapping ld: library not found for -lcrt1.10.5.o I can compile the same program using the command line (no makefile). My command line is : g++ -o App -I

Re: [CMake] Memory checking MPI programs with valgrind?

2009/2/26 Bartlett, Roscoe A raba...@sandia.gov: Hello, Does anyone know how to get CMake/CTest to do memory testing with MPI programs using valgrind?  The problem is that by default valgrind just tests the mpiexec/mpirun driver program and not your user program.  I think there are some

[CMake] Cannot add a Dependency to INSTALL Target

Under CMakeLists.txt files, I want to add a dependency so Install will run a target add_custom_target(3rd_party_install ALL) ADD_DEPENDENCIES(INSTALL 3rd_party_install ) When I run cmake, it complains INSTALL is not defined yet but, it is if I exclude this new depenency -- Adding

Re: [CMake] Memory checking MPI programs with valgrind?

-Original Message- From: Eric Noulard [mailto:eric.noul...@gmail.com] Sent: Thursday, February 26, 2009 9:29 AM To: Bartlett, Roscoe A Cc: cmake@cmake.org; Willenbring, James M; Perschbacher, Brent M Subject: Re: [CMake] Memory checking MPI programs with valgrind? 2009/2/26

Re: [CMake] Memory checking MPI programs with valgrind?

I don't know if you've considered it and I'm not sure if it would work in your situation, but you might be able to use mpirun to run valgrind. For example: mpirun mpirun args valgrind valgrind args executable executable args --ND ___ Powered by

Re: [CMake] Memory checking MPI programs with valgrind?

Bartlett, Roscoe A wrote: Does anyone know how to get valgrind to not search for errors in the parent but only in the children? No way to do that, but you can create a suppression file. If you add --gen-suppressions=all to the valgrind command line it will create entries for the

Re: [CMake] Cannot add a Dependency to INSTALL Target

On Thu, Feb 26, 2009 at 10:43:05AM -0700, david_bjorn...@agilent.com wrote: Under CMakeLists.txt files, I want to add a dependency so Install will run a target add_custom_target(3rd_party_install ALL) ADD_DEPENDENCIES(INSTALL 3rd_party_install ) When I run cmake, it complains INSTALL

Re: [CMake] Cannot add a Dependency to INSTALL Target

Tyler, What I'm really working is, I want to install debian files ( *.deb files ) during an installation or INSTALL target. I tried using INSTALL(CODE [SCRIPT] point to execute_process command but, execute_process does not play nice with this path either. I prefer to have ALL_BUILD

Re: [CMake] Help with cmake_policy

Alexander Neundorf wrote: On Wednesday 25 February 2009, eblo...@free.fr wrote: The customer may not need to know about CMake internals, and get weird warning messages. I'd also like to have them somewhat less scary looking... Manu, are you actually cutting release snapshots for the

[CMake] printing search paths?

Hi If I do a few include_directories() commands in various files.. is there a variable which I can use to print the current search path as changed by those commands? thanks b. ___ Powered by www.kitware.com Visit other Kitware open-source projects at

Re: [CMake] Help with cmake_policy

Manu, are you actually cutting release snapshots for the customer and delivering them outside your version control trunk? In that case you can make -Wno-dev the default by adding We deliver SDKs, however CMake binaries are not bundled along with our SDKs. A SDK that builds w/o a single

[CMake] Technique for generating projects that depend on generated sources

I'm working on a project that involves generating a large chunk of the sources from separate definitions. The set of generated source files is not known before it is generated. The approach I've tried so far (and I'm very new to cmake) is to define a custom_command that does the source

Re: [CMake] Technique for generating projects that depend on generated sources

Steve Huston wrote: I'm working on a project that involves generating a large chunk of the sources from separate definitions. The set of generated source files is not known before it is generated. The approach I've tried so far (and I'm very new to cmake) is to define a custom_command that does

Re: [CMake] printing search paths?

Hi Bill, You can use the MESSAGE(${SOME_INCLUDES}) command. You can also use the verbose makefile to watch the -I flags that are passed to the compiler. Chris. Bill O'Hara wrote: Hi If I do a few include_directories() commands in various files.. is there a variable which I can use to print

[CMake] linking cmake targets to cpack targets

When I was using autotools, I'd hook up a target version to dist-gzip so that my version.c (which was auto-generated and had my svn repo revision in it) was always up to date when I built my source tarball. Is there a way to do that with cpack's package_source target? Doing the obvious: