[CMake] ADD_SUBDIRECTORY not working as expected
Hi,
I have a cross-platform library project with multiple "test" programs
that test the library. Those tests come in separate directories, each
with it's own CMakeLists.txt file (although the files are all identical,
see below).
I'm adding the tests to the library project by
FILE(GLOB tests "../test/*")
FOREACH(test ${tests})
GET_FILENAME_COMPONENT(path "${test}" ABSOLUTE)
IF(IS_DIRECTORY ${path})
GET_FILENAME_COMPONENT(dir ${path} NAME)
IF(NOT ${dir} STREQUAL "CVS" AND NOT ${dir} STREQUAL ".svn")
ADD_SUBDIRECTORY(${path} ${CMAKE_CURRENT_BINARY_DIR})
ENDIF(NOT ${dir} STREQUAL "CVS" AND NOT ${dir} STREQUAL ".svn")
ENDIF(IS_DIRECTORY ${path})
ENDFOREACH(test ${tests})
The CMakeLists.txt files in ${path} each look like
GET_FILENAME_COMPONENT(name ${CMAKE_CURRENT_SOURCE_DIR} NAME)
SET(name test_${name})
PROJECT(${name})
INCLUDE_DIRECTORIES("../../include")
LINK_DIRECTORIES("../../lib")
SET(EXECUTABLE_OUTPUT_PATH "../../bin" CACHE INTERNAL "" FORCE)
FILE(GLOB_RECURSE sources "*.h" "*.cpp")
ADD_EXECUTABLE(${name} ${sources})
ADD_DEPENDENCIES(${name} gale)
All this works fine under Windows. Under Linux, however, only one test
(out of five) is added to the project (i.e. is available as a make
target). If I remove that test's directory and rerun cmake, another of
the four remaining tests is now available as a make target, so it seems
only the first or last test parsed gets added. I've verified ${path} is
correct. Any ideas why the other tests are missing as make targets?
--
Sebastian Schuberth
(Remove "NOSP" and "M" from my e-mail address)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] nmake to gnu-make
I try to "port" a nmake-makefile to a gnu-makefile (MinGW). There is a line !include "../../../Build.mak" I modified it to include "../../../Build.mak" Then make says makefile.gcc:152: "../../../Build.mak": Invalid argument mingw32-make: *** No rule to make target `"../../../Build.mak"'. Stop. The included file looks quite complex. Here are just the first 12 lines of it !IFDEF CPU LIBS = $(LIBS) bufferoverflowU.lib CFLAGS = $(CFLAGS) -GS- -Zc:forScope !ENDIF !IFNDEF O !IFDEF CPU O=$(CPU) !ELSE O=O !ENDIF !ENDIF I am not sure but I think make won't like the !IFDEF expressions? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] nmake to gnu-make
On 23.09.07 15:21:39, Christian Buhtz wrote: > I try to "port" a nmake-makefile to a gnu-makefile (MinGW). > > There is a line > !include "../../../Build.mak" > > I modified it to > include "../../../Build.mak" I think you posted to the wrong mailinglist. This list is for users of cmake, not nmake or gnu-make. CMake is a cross-platform buildtool that can generate nmake or gnu-make Makefiles, those are not supposed to be changed manually after generation. Andreas -- Your heart is pure, and your mind clear, and your soul devout. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMakeFileList gui
Is there a gui app do create a CMakeFileList.txt automaticly. Just give the source dir and everything is created automaticly. The CMake "code" is quite unergonomic. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] build types
I read the docs and the wiki and the faq. I know that I can specify build types but I didn't understand it right. How can I realize to build project as debug and/or release? How do I have to call cmake to generate a gnu-makefile that I can use like this: mingw32-make -f makefile.gcc BUILD=release or mingw32-make -f makefile.gcc BUILD=debug ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] nmake to CMake
I try to "port" a nmake-makefile to a cmake-file. But the project is foreign an the existing nmake-files extremly complex (including a lot of nmake-files from other dirs). Any idea? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeFileList gui
On 23.09.07 17:32:38, Christian Buhtz wrote: > Is there a gui app do create a CMakeFileList.txt automaticly. > Just give the source dir and everything is created automaticly. > > The CMake "code" is quite unergonomic. No, at least I'm not aware of any. The problem with such scripting-language buildsystems like CMake is that you can't fit it into a GUI, at least not for the "generic" case. Andreas -- Your society will be sought by people of taste and refinement. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] nmake to CMake
On 23.09.07 17:36:30, Christian Buhtz wrote: > I try to "port" a nmake-makefile to a cmake-file. > > But the project is foreign an the existing nmake-files extremly complex > (including a lot of nmake-files from other dirs). Any idea? Well, all you really need to find out is: What source files are used in which target. Whats the type of each target (library, executable). What other libraries does a target link to. What include dirs are needed for each subdirectory. Special compiler flags for certain targets/subdirs. Andreas -- You're definitely on their list. The question to ask next is what list it is. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeFileList gui
On 9/23/07, Christian Buhtz wrote: > Is there a gui app do create a CMakeFileList.txt automaticly. > Just give the source dir and everything is created automaticly. > > The CMake "code" is quite unergonomic. Compared to what? Have you seen code for other alternative tools? How much easier is it to create a hello world builder in other alternative tools? --- project(hello_world) add_executable(hello_world hello_world.cxx) --- --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] build types
On 23.09.07 17:34:34, Christian Buhtz wrote: > I read the docs and the wiki and the faq. > I know that I can specify build types but I didn't understand it right. > > How can I realize to build project as debug and/or release? > > How do I have to call cmake to generate a gnu-makefile that I can use like > this: You can't. You specify the build type during cmake-time, using -DCMAKE_BUILD_TYPE=Debug|Release|... And thats quite ok, because you need different directories for the targets and the intermediate object files anyway as those differ between release and debug. So its not a problem to have builddir/debug builddir/release and call cmake in each one using the right build type. Andreas -- Your supervisor is thinking about you. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating a static lib from other static libs, HOW?
On 9/22/07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > "Brandon Van Every" <[EMAIL PROTECTED]> writes: > > > > If CMake considered it. All I do is find the objects that CMake > > already generated, then dump them directly into a library target. > > CMake can swallow all kinds of stuff, *.c files, *.h files, *.o files, > > whatever. > > > > This is part of why I think you guys should stop messing around with > > non-CMake ways of doing things. It either works and hey presto! > > Or it just goes horribly wrong in some hidden corner with totaly > unpredictable effect and race conditions. That is why before > introducing a concept like yours you have to think out what it all > means. > > > you've got wonderful automagical cross-platform build stuff for no > > work... or it doesn't work, and you're helping CMake improve by > > submitting bug reports or feature requests. Like I said the 1st time. Help us improve CMake instead of working on AR-specific stuff or wringing hands about theoretical bugs that haven't been demonstrated yet. > CMake will have to use AR to create the archive and it has to limit > the command line. If it does multiple ar calls to add more and more > objects it can easily overwrite exitsing entries if the wrong options > are used. Also commandline overflow is much more likely with long > pathnames. Maybe just nobody cared about it yet since it never happens > for normal dirs. Also with a single dir name collisions won't happen > while with multiple dirs they might. So go look in the CMake sources and see if there are automated test cases that address these issues to your satisfaction. If there aren't, write some and contribute them. This is open source. My method worked for my build. I didn't make it public because I didn't want to deal with the full support burden of proving that it works everywhere for everything. When pressured with competing, bad solutions, I made it public. But you still have to go to the bug tracker and look up feature request #5155, so that's a barrier to people making casual, uninformed use of it. I'm not currently getting paid to write test cases for it, so YMMV. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: build types
Andreas Pakulat schrieb: You can't. You specify the build type during cmake-time, using -DCMAKE_BUILD_TYPE=Debug|Release|... And thats quite ok So I need to create makefile like this: makefile_release.gcc makefile_debug.gcc makefile_xx_yy_whatever.gcc ? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: build types
On 23.09.07 20:50:48, Christian Buhtz wrote: > Andreas Pakulat schrieb: > >You can't. You specify the build type during cmake-time, using > >-DCMAKE_BUILD_TYPE=Debug|Release|... And thats quite ok > > So I need to create makefile like this: No. CMake will create the makefiles it needs. You just need to use two different builddirs for building release and debug versions. As I tried to explain earlier, CMake is not a tool to describe how a Makefile should look like (just in another tongue), but its a tool to describe how you want to build your library or application. CMake then generates files for various buildtools, like make, Visual Studio and so on, which are understood by those buildtools and will call the compiler in the way you want it. Andreas -- Your supervisor is thinking about you. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] build types
forgot to cc the list... -- Forwarded message -- From: Miguel A. Figueroa-Villanueva Date: Sep 23, 2007 3:09 PM Subject: Re: [CMake] Re: build types To: Christian Buhtz On 9/23/07, Christian Buhtz wrote: > Andreas Pakulat schrieb: > > You can't. You specify the build type during cmake-time, using > > -DCMAKE_BUILD_TYPE=Debug|Release|... And thats quite ok > > So I need to create makefile like this: > makefile_release.gcc > makefile_debug.gcc > makefile_xx_yy_whatever.gcc > ? The only thing you will be creating is a CMakeLists.txt file. Then when you run cmake on that file it will generate your makefile. So make sure you can do this before you continue. Also, you should be doing out-of-source builds. That is: .../source .../builds/debug .../builds/release then all you need to do is: cd .../builds/debug cmake -DCMAKE_BUILD_TYPE=Debug ../../source cd .../builds/release cmake -DCMAKE_BUILD_TYPE=Release ../../source Note that this is assuming you are using unix makefiles and gcc. If you use Visual Studio, then it keeps your debug and release files in separate directories, so the following should do it. cd .../builds cmake .../source Now, the one thing you should understand is that you do not need to create any makefile manually, cmake will create it for you!! That is the whole purpose of its existance. --Miguel -- Miguel A. Figueroa Villanueva +1 787 832-4040 x.3610-4006 Department of Electrical and Computer Engineering University of Puerto Rico - Mayagüez Campus ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] build types
On 9/23/07, Miguel A. Figueroa-Villanueva <[EMAIL PROTECTED]> wrote: > > Now, the one thing you should understand is that you do not need to > create any makefile manually, cmake will create it for you!! That is > the whole purpose of its existance. Yes, CMake takes the manual labor to a higher level of abstraction. You still write something that's "like a makefile," that's your CMakeLists.txt. But once you've written that, it will generate files for dozens of different build systems. You may have to insert some system-specific code, it can't automagically do everything in the universe for you. For instance you might need IF(APPLE) or IF(UNIX) or IF(WIN32) or IF(MSVC) or some such. But mostly you can target lotsa platforms, lotsa compliers, and lotsa build tools, all with 1 CMakeLists.txt. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: build types
Brandon Van Every schrieb: But once you've written that, it will generate files for dozens of different build systems. CMake not only generate makefiles it executes it for me? I have never call mingw32-make manualy? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] ctest question
I want run a test program and pipe its results to a file. I then want to compare this file to the golden results using diff. Does anyone have a macro or cookbook example for doing this? Thank you, Juan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating a static lib from other static libs, HOW?
Hello Brandon, What is the appropriate email list for doing things in cmake for a particular architecture, like Unix? There is a rich history in many disciplines where people need to address a compelling need in a specific case. Once the immediate need is addressed, the system can be extended for the general case. In some instances, it is impossible to abstract away the differences for different architectures. For example, CMAKE has particular commands focused particularly on the way windows libraries work. Is there a safe forum where we can discuss these issues? Thanks, Juan Brandon Van Every wrote: > On 9/22/07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> "Brandon Van Every" <[EMAIL PROTECTED]> writes: >>> If CMake considered it. All I do is find the objects that CMake >>> already generated, then dump them directly into a library target. >>> CMake can swallow all kinds of stuff, *.c files, *.h files, *.o files, >>> whatever. >>> >>> This is part of why I think you guys should stop messing around with >>> non-CMake ways of doing things. It either works and hey presto! >> Or it just goes horribly wrong in some hidden corner with totaly >> unpredictable effect and race conditions. That is why before >> introducing a concept like yours you have to think out what it all >> means. >> >>> you've got wonderful automagical cross-platform build stuff for no >>> work... or it doesn't work, and you're helping CMake improve by >>> submitting bug reports or feature requests. > > Like I said the 1st time. Help us improve CMake instead of working on > AR-specific stuff or wringing hands about theoretical bugs that > haven't been demonstrated yet. > >> CMake will have to use AR to create the archive and it has to limit >> the command line. If it does multiple ar calls to add more and more >> objects it can easily overwrite exitsing entries if the wrong options >> are used. Also commandline overflow is much more likely with long >> pathnames. Maybe just nobody cared about it yet since it never happens >> for normal dirs. Also with a single dir name collisions won't happen >> while with multiple dirs they might. > > So go look in the CMake sources and see if there are automated test > cases that address these issues to your satisfaction. If there > aren't, write some and contribute them. This is open source. > > My method worked for my build. I didn't make it public because I > didn't want to deal with the full support burden of proving that it > works everywhere for everything. When pressured with competing, bad > solutions, I made it public. But you still have to go to the bug > tracker and look up feature request #5155, so that's a barrier to > people making casual, uninformed use of it. I'm not currently getting > paid to write test cases for it, so YMMV. > > > Cheers, > Brandon Van Every > ___ > 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: build types
On 23.09.07 21:47:55, Christian Buhtz wrote: > Brandon Van Every schrieb: > >But once you've written that, it will generate files > >for dozens of different build systems. > > CMake not only generate makefiles it executes it for me? No. > I have never call mingw32-make manualy? It works the same way as other make tools, just run "mingw32-make" in the build directory after having run cmake. Andreas -- Don't you wish you had more energy... or less ambition? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating a static lib from other static libs, HOW?
On my Linux laptop, I used getconf to see that the maximum argument length is 131072. This is not the maximum number of arguments. I ran a test CMakeLists.txt, and the maximum length to the echo command from EXEC_PROGRAM was 128788 characters. Fortunately, exec'ing a program will fail (non zero error code) if the argument list is too long. This is linux only, and other architectures and csh, both have a reputation for having a much shorter command line length capability. FWIW, it is well documented in the gnu ar documentation that your archives will get corrupted if you manage to call ar twice on the same archive at the same time. Filename collisions are undesirable. The posix specification says that the .o filename, and not its path, are used in the archiving process. Therefore you need to be careful that you don't add the same .o filename twice to your archive. Regards, Juan Brandon Van Every wrote: > On 9/22/07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> "Brandon Van Every" <[EMAIL PROTECTED]> writes: >>> If CMake considered it. All I do is find the objects that CMake >>> already generated, then dump them directly into a library target. >>> CMake can swallow all kinds of stuff, *.c files, *.h files, *.o files, >>> whatever. >>> >>> This is part of why I think you guys should stop messing around with >>> non-CMake ways of doing things. It either works and hey presto! >> Or it just goes horribly wrong in some hidden corner with totaly >> unpredictable effect and race conditions. That is why before >> introducing a concept like yours you have to think out what it all >> means. >> >>> you've got wonderful automagical cross-platform build stuff for no >>> work... or it doesn't work, and you're helping CMake improve by >>> submitting bug reports or feature requests. > > Like I said the 1st time. Help us improve CMake instead of working on > AR-specific stuff or wringing hands about theoretical bugs that > haven't been demonstrated yet. > >> CMake will have to use AR to create the archive and it has to limit >> the command line. If it does multiple ar calls to add more and more >> objects it can easily overwrite exitsing entries if the wrong options >> are used. Also commandline overflow is much more likely with long >> pathnames. Maybe just nobody cared about it yet since it never happens >> for normal dirs. Also with a single dir name collisions won't happen >> while with multiple dirs they might. > > So go look in the CMake sources and see if there are automated test > cases that address these issues to your satisfaction. If there > aren't, write some and contribute them. This is open source. > > My method worked for my build. I didn't make it public because I > didn't want to deal with the full support burden of proving that it > works everywhere for everything. When pressured with competing, bad > solutions, I made it public. But you still have to go to the bug > tracker and look up feature request #5155, so that's a barrier to > people making casual, uninformed use of it. I'm not currently getting > paid to write test cases for it, so YMMV. > > > Cheers, > Brandon Van Every > ___ > 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] Creating a static lib from other static libs, HOW?
Addendum to my previous email: I find it absolutely entertaining that the command line length limitation for command lines and environment variables on windows xp and later is 8192. http://support.microsoft.com/kb/830473 So while this doesn't affect AR. It positively affect any solution on windows requiring an explicit list of all files going into a library. Regards, Juan Juan Sanchez wrote: > On my Linux laptop, I used getconf to see that the maximum argument > length is 131072. This is not the maximum number of arguments. I ran a > test CMakeLists.txt, and the maximum length to the echo command from > EXEC_PROGRAM was 128788 characters. > > Fortunately, exec'ing a program will fail (non zero error code) if the > argument list is too long. > > This is linux only, and other architectures and csh, both have a > reputation for having a much shorter command line length capability. > > FWIW, it is well documented in the gnu ar documentation that your > archives will get corrupted if you manage to call ar twice on the same > archive at the same time. Filename collisions are undesirable. The > posix specification says that the .o filename, and not its path, are > used in the archiving process. Therefore you need to be careful that > you don't add the same .o filename twice to your archive. > > Regards, > > Juan > > Brandon Van Every wrote: >> On 9/22/07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >>> "Brandon Van Every" <[EMAIL PROTECTED]> writes: If CMake considered it. All I do is find the objects that CMake already generated, then dump them directly into a library target. CMake can swallow all kinds of stuff, *.c files, *.h files, *.o files, whatever. This is part of why I think you guys should stop messing around with non-CMake ways of doing things. It either works and hey presto! >>> Or it just goes horribly wrong in some hidden corner with totaly >>> unpredictable effect and race conditions. That is why before >>> introducing a concept like yours you have to think out what it all >>> means. >>> you've got wonderful automagical cross-platform build stuff for no work... or it doesn't work, and you're helping CMake improve by submitting bug reports or feature requests. >> Like I said the 1st time. Help us improve CMake instead of working on >> AR-specific stuff or wringing hands about theoretical bugs that >> haven't been demonstrated yet. >> >>> CMake will have to use AR to create the archive and it has to limit >>> the command line. If it does multiple ar calls to add more and more >>> objects it can easily overwrite exitsing entries if the wrong options >>> are used. Also commandline overflow is much more likely with long >>> pathnames. Maybe just nobody cared about it yet since it never happens >>> for normal dirs. Also with a single dir name collisions won't happen >>> while with multiple dirs they might. >> So go look in the CMake sources and see if there are automated test >> cases that address these issues to your satisfaction. If there >> aren't, write some and contribute them. This is open source. >> >> My method worked for my build. I didn't make it public because I >> didn't want to deal with the full support burden of proving that it >> works everywhere for everything. When pressured with competing, bad >> solutions, I made it public. But you still have to go to the bug >> tracker and look up feature request #5155, so that's a barrier to >> people making casual, uninformed use of it. I'm not currently getting >> paid to write test cases for it, so YMMV. >> >> >> Cheers, >> Brandon Van Every >> ___ >> 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 question
Hi, I think that execute_process() is your command :). Bye! On 9/23/07, Juan Sanchez <[EMAIL PROTECTED]> wrote: > I want run a test program and pipe its results to a file. I then want > to compare this file to the golden results using diff. > > Does anyone have a macro or cookbook example for doing this? > > Thank you, > > Juan > > > ___ > 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] Creating a static lib from other static libs, HOW?
On 9/23/07, Juan Sanchez <[EMAIL PROTECTED]> wrote: > > What is the appropriate email list for doing things in cmake for a > particular architecture, like Unix? Of course this one is. Plenty of system-specific stuff is discussed here. > There is a rich history in many disciplines where people need to address > a compelling need in a specific case. Once the immediate need is > addressed, the system can be extended for the general case. > > In some instances, it is impossible to abstract away the differences for > different architectures. For example, CMAKE has particular commands > focused particularly on the way windows libraries work. > > Is there a safe forum where we can discuss these issues? However, that's not going to stop me from suggesting / encouraging / cajoling / flogging people towards using the more abstract cross-platform capabilities that CMake provides. You can write anything you want in CMake with an ADD_CUSTOM_COMMAND. Stuff that only works on a Unix shell, stuff that only works for certain toolchains, you name it you can do it. CMake is a general purpose language and it doesn't tie your hands as far as rolling your own. But doing so is often *missing the point*. CMake is supposed to be doing certain things for you, that's why you're using a build system. The management of AR probably falls within that purview. And if it doesn't, it should be made to. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest question
So I somehow tell ADD_TEST to EXECUTE_PROCESS? Any examples of doing this? The ctest documentation is a little unclear on this as I don't even think execute_process existed when the cmake book was written. Also ADD_TEST seems to only invoke external commands, and not cmake ones? Would this sound reasonable? Write a perl script with the name of the test program and golden result file as arguments. The perl script will run the test and compare the output results with the golden file and then return success or failure. Regards, Juan -Original Message- From: Aleix [mailto:[EMAIL PROTECTED] Sent: Sun 9/23/2007 5:33 PM To: Sanchez, Juan Cc: CMake ML Subject: Re: [CMake] ctest question Hi, I think that execute_process() is your command :). Bye! On 9/23/07, Juan Sanchez <[EMAIL PROTECTED]> wrote: > I want run a test program and pipe its results to a file. I then want > to compare this file to the golden results using diff. > > Does anyone have a macro or cookbook example for doing this? > > Thank you, > > Juan > > > ___ > 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: build types
Andreas Pakulat schrieb: It works the same way as other make tools, just run "mingw32-make" in the build directory after having run cmake. So I was right to say that I have to generate a makefile for each buildtype? Not with the names makefile_release.gcc, etc but as Release/makefile.gcc, Debug/makefile.gcc, xx_yy/makefile.gcc, ...? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest question
On 2007-09-23 18:48-0700 Sanchez, Juan wrote: Would this sound reasonable? Write a perl script with the name of the test program and golden result file as arguments. The perl script will run the test and compare the output results with the golden file and then return success or failure. ADD_TEST allows you to run any command-line executable with any arguments. You will find that running a script (bash or perl or python) is one option, but that may be overkill for what you appear to want. Why not simply run diff, i.e., ADD_TEST(my_first_test diff -q goldenfile testfile) ? If that hint isn't quite right for your needs, then I suggest you implement some really simple examples of ADD_TEST to see what is possible, and what the resulting ctest results look like. (That is one of the nice things about cmake; you can make a complete example with just a few lines to explore and learn about any part of it.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest question
Well the fundamental problem is the point when the test gets run. I would think your solution requires that the test has already been executed. For my purposes, that is way too premature and costly. I was hoping that other people may have run into this situation and would be willing to share their best practices. It would be a shame for me to develop NIH and continuosly reinvent the wheel. The whole point of cmake for me is to avoid reinventing the wheel. The whole point of me querying the list about this type of stuff is to share collective experiences about an issue I don't believe to be covered in the online or book documentation. Am I correct in saying that execute_processs cannot be invoked from add_test? Writing a perl script to execute the test and run the diff would be a simple exercise, and I guess that is what I'll have to do. Regards, Juan -Original Message- From: Alan W. Irwin [mailto:[EMAIL PROTECTED] Sent: Sun 9/23/2007 10:08 PM To: Sanchez, Juan Cc: Aleix; CMake ML Subject: RE: [CMake] ctest question On 2007-09-23 18:48-0700 Sanchez, Juan wrote: > Would this sound reasonable? > Write a perl script with the name of the test program and golden result file > as arguments. The perl script will run the test and compare the output > results with the golden file and then return success or failure. ADD_TEST allows you to run any command-line executable with any arguments. You will find that running a script (bash or perl or python) is one option, but that may be overkill for what you appear to want. Why not simply run diff, i.e., ADD_TEST(my_first_test diff -q goldenfile testfile) ? If that hint isn't quite right for your needs, then I suggest you implement some really simple examples of ADD_TEST to see what is possible, and what the resulting ctest results look like. (That is one of the nice things about cmake; you can make a complete example with just a few lines to explore and learn about any part of it.) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: build types
On 24.09.07 04:18:22, Christian Buhtz wrote: > Andreas Pakulat schrieb: > >It works the same way as other make tools, just run "mingw32-make" in > >the build directory after having run cmake. > > So I was right to say that I have to generate a makefile for each buildtype? > Not with the names makefile_release.gcc, etc but as Release/makefile.gcc, > Debug/makefile.gcc, xx_yy/makefile.gcc, ...? You don't specify the Makefile-names, CMake will always generate a xy/Makefile so you don't have to use the -f parameter for (mingw32-|n|gnu-|...)make. Other than that, yes you're going to generate a builddir for each build type (a builddir usually contains more than just 1 Makefile) Andreas -- You may be recognized soon. Hide. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest question
On 2007-09-23 20:58-0700 Sanchez, Juan wrote: Well the fundamental problem is the point when the test gets run. When you run ctest (after cmake and make). I would think your solution requires that the test has already been executed. For my purposes, that is way too premature and costly. I believe you are concerned about an issue that does not exist. Hopefully, my answer above addresses your concern. [...]The whole point of me querying the list about this type of stuff is to share collective experiences about an issue I don't believe to be covered in the online or book documentation. We (PLplot) use ctest to extensively test our software build, and I am sure the same is true of most other mature projects that use cmake. I think you are concerned it is something really complicated when in fact it is standard stuff that is pretty trivial to set up. You set up ctest with ADD_TEST at cmake time (look at the ADD_TEST documentation for more details), and the actual test gets run when you run ctest (after build time). (Run ctest --help-full for more details). It should all become clear once you run a simple ctest case following the documentation I have specified. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
