Re: [CMake] CTest: Glob files to include in coverage report with 0% line coverage
2012/1/24 Rolf Eike Beer : > Andreas Schuh wrote: >> Hi, >> >> Setting CTEST_EXTRA_COVERAGE_GLOB in the CTestCustom.cmake file can be >> used to add additional files which shall be included in the coverage >> report. This is useful to ensure that files which are not covered by >> any test are still reported with 0% line coverage. > > Oh, interesting variable. How can it be that there is absolutely zero > documentation for in CMake? Because ctest and cpack documentation are very far from being documented as cmake is ? E.g. current ctest and cpack do not have --help-variable-* support? If you want to help please try my "stage/ImproveCPackDoc-reloaded" branch and may be read this: http://public.kitware.com/Bug/view.php?id=10067 The technique I propose may be used for cpack, ctest, etc... -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] CTest: Glob files to include in coverage report with 0% line coverage
Andreas Schuh wrote: > Hi, > > Setting CTEST_EXTRA_COVERAGE_GLOB in the CTestCustom.cmake file can be > used to add additional files which shall be included in the coverage > report. This is useful to ensure that files which are not covered by > any test are still reported with 0% line coverage. Oh, interesting variable. How can it be that there is absolutely zero documentation for in CMake? Eike signature.asc Description: This is a digitally signed message part. -- 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] [New Module] Arduino CMake
Hi Alfa, We are really interested in the teamcity + CTest support. Is that available somewhere already? Thanks /Johan On Sun, Jan 22, 2012 at 7:51 PM, Alfa Omega wrote: > Hi everyone, > > I'm not quite sure what the correct procedure is for becoming a CMake > contributor, but from what I've read I should send a email here if I want > to add a new module to cmake. > > For the past year I've been hosting my CMake modules on GitHub ( > https://github.com/queezythegreat/arduino-cmake) and the project is > mature enough that it could be included into CMake. The project is called > Arduino CMake and it adds support for building Arduino projects. It is a > alternative to the Arduino IDE, and works on Windows, Linux and Mac. > > The project is growing and getting more and more users, and I think it's > would be a god fit to start bundling it with CMake. The project is well > documented both from a developer standpoint as well as the user side. > > So what are the steps I should take in order to integrate my project into > CMake? > > I also would like to contribute back some extensions to the CMake, such as > Teamcity support for CTest. Any information would be greatly appreciated. > > Tomasz Bogdal > > -- > > 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] Packaging DEB at different directory with CPack
2012/1/24 Damián Nohales :
> Hello,
>
> I'm doing an application for Debian based systems and I need to package
> a .deb file, my application has several files to install in addition to
> the main executable.
>
> So, my CMakeLists.txt file looks like:
>
>
> project("myapp" C)
> cmake_minimum_required(VERSION 2.8)
>
> # The executable
> add_executable(myapp main.c)
> install(TARGETS myapp RUNTIME DESTINATION bin)
this is ok.
>
> # Another file to install
> install(FILES ${CMAKE_SOURCE_DIR}/data/myapp.desktop DESTINATION
> "${CMAKE_INSTALL_PREFIX}/share/applications")
This is usually wrong as it is an absolute PATH destination
why don't you simply specify
install(FILES ${CMAKE_SOURCE_DIR}/data/myapp.desktop DESTINATION
share/applications)
> SET(CPACK_GENERATOR "DEB")
> SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Damián Nohales")
>
> INCLUDE(CPack)
>
>
> I execute CMake and build the package in this way:
>
>
> $ cd build
> $ cmake -DCMAKE_INSTALL_PREFIX=install ..
Specifying CMAKE_INSTALL_PREFIX has no effect on the following CPack call
> $ make package
>
>
> I need to specify a prefix for the installation because I want to test
> the application without installing on my whole system.
Then you should override CPACK_PACKAGING_INSTALL_PREFIX
$ cd build
$ cpack -D CPACK_PACKAGING_INSTALL_PREFIX=$HOME/testinstall -G DEB
another possibility is to install you deb content at an alternate location
using
dpkg --instdir=$HOME/testinstall -i your.deb
> But the .deb content resulting of executing "make package" is not what I
> expected:
>
[...]
>
> Well, I'm sure you are understanding the problem, I'm expecting that the
> generated .deb package to has the files under the /usr directory having
> too the myapp.desktop file under the following filename
> "/usr/share/applications/myapp.desktop".
>
> Any suggestion?
Always use relative DESTINATION install path unless you forcibly want
an ABSOLUTE destination.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
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 define dependencies? Problem with nmake builds.
My component source list includes: easyrtd.src/COMRtdInterface.cpp easyrtd.src/EasyRTD.rc easyrtd.src/EasyRTD.idl and after fixing up the paths Visual Studio builds the project OK. However, nmake does not - the RC compiler runs before MIDL. It seems that there is a dependency that's missing. This would seem to be the implied one from the TYPELIB statement in the RC file. Is it enough to use OBJECT_DEPENDS on the rc file (treating the implied res file as an object) naming the tlb that would be output by midl? Presumably I'd also have to declare that the idl file produces the tlb file, using OBJECT_OUTPUTS? (Or not? This is only for Makefile generators, but how is the OBJECT_DEPENDS going to be handled in other cases?) There seems to be an element of magic going on here rather than explicitly handling the midl/rc/link toolchain. I know Visual Studio tries to make this stff easy - but how does it work with nmake (and ideally the mingw toolchain too)? James -- 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] Revision header
On 01/21/2012 10:51 PM, Oliver Smith wrote:
> I have a script that generates a revision.h file, I've spent the morning
> trying to figure out how to make it so that ... any time CMake rebuilds
> any of the other targets, it starts by running the make-new-revision script.
>
> The idea is, I use the script manually to upversion, but anytime I type
> "make" and /anything/ has to be done (even just a relink), it will do
> the upversion first.
>
> I've only managed to make it either source dependent or always build,
> which forces the versionNo file to recompile and forces all executables
> to relink, so if you type:
>
> make ; make ... it will have to relink the executables the second time
> because of an pointless upversion :)
>
> - Oliver
There might be a solution for your concern, but it's probably somewhat
fragile; look at the following exemplary project for a demonstration:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(VERSIONHEADERIN ${CMAKE_SOURCE_DIR}/version.h.in)
SET(VERSIONHEADER ${CMAKE_BINARY_DIR}/version.h)
SET(VERSIONFILE ${CMAKE_BINARY_DIR}/version.txt)
IF(NOT EXISTS ${VERSIONFILE})
FILE(WRITE ${VERSIONFILE} "0\n")
ENDIF()
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR})
ADD_EXECUTABLE(main main.c)
ADD_CUSTOM_TARGET(version
${CMAKE_COMMAND}
-DVERSIONHEADERIN=${VERSIONHEADERIN}
-DVERSIONHEADER=${VERSIONHEADER}
-DVERSIONFILE=${VERSIONFILE}
-P ${CMAKE_SOURCE_DIR}/version.cmake)
ADD_DEPENDENCIES(main version)
ADD_CUSTOM_TARGET(upversion
${CMAKE_COMMAND}
-DVERSIONFILE=${VERSIONFILE}
-P ${CMAKE_SOURCE_DIR}/upversion.cmake)
# version.cmake:
FILE(STRINGS ${VERSIONFILE} VERSION)
EXECUTE_PROCESS(
COMMAND make -n VERBOSE=
COMMAND grep "Linking"
RESULT_VARIABLE GREPPED
)
IF(GREPPED EQUAL 0)
# Something will be done, thus:
MATH(EXPR VERSION "${VERSION}+1")
FILE(WRITE ${VERSIONFILE} "${VERSION}\n")
ENDIF()
CONFIGURE_FILE(${VERSIONHEADERIN} ${VERSIONHEADER} @ONLY)
# upversion.cmake:
FILE(STRINGS ${VERSIONFILE} VERSION)
MATH(EXPR VERSION "${VERSION}+1")
FILE(WRITE ${VERSIONFILE} "${VERSION}\n")
/* version.h.in: */
#define VERSION @VERSION@
/* main.c: */
#include "version.h"
#include
int main(void)
{
printf("VERSION: %d\n",VERSION);
}
The basic idea is to run "make -n" (version.cmake), scan the output for
strings indicating an upcoming rebuild ("Linking"), increment a version
number accordingly (version.txt) and generate a version header in the
end (version.h.in). Anything else is done via the usual dependency
tracking. Additionally, the upversion.cmake script allows for
incrementing the version number manually.
Perhaps, you can adapt the approach to your needs. However, the critical
moment is how to detect if any actions which require the version number
to be incremented are going to happen. The example uses "make -n" and
"grep" for this purpose, but that's fragile, of course, as I remarked
at the outset.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [New Module] Arduino CMake
Hi, What part does not follow the convention? I'm using a toolchain file, plus when I was writing this I based it on a existing module bundled with CMake (but cant remember which). I'm open to modifying my project to match the convention. If you could point out which parts don't quite meet the convention, I would greatly appreciate that. Tomasz B. 2012/1/23 Alexander Neundorf > On Sunday 22 January 2012, Alfa Omega wrote: > > Hi everyone, > > > > I'm not quite sure what the correct procedure is for becoming a CMake > > contributor, but from what I've read I should send a email here if I want > > to add a new module to cmake. > > > > For the past year I've been hosting my CMake modules on GitHub ( > > https://github.com/queezythegreat/arduino-cmake) and the project is > mature > > enough that it could be included into CMake. The project is called > Arduino > > CMake and it adds support for building Arduino projects. It is a > > alternative to the Arduino IDE, and works on Windows, Linux and Mac. > > > > The project is growing and getting more and more users, and I think it's > > would be a god fit to start bundling it with CMake. The project is well > > documented both from a developer standpoint as well as the user side. > > > > So what are the steps I should take in order to integrate my project into > > CMake? > > Does it follow the regular cross compiling conventions ? > http://www.vtk.org/Wiki/CMake_Cross_Compiling > > From a quick look it didn't look like it does. > If so, why did you chose to do it differently ? > > 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
[CMake] Packaging DEB at different directory with CPack
Hello,
I'm doing an application for Debian based systems and I need to package
a .deb file, my application has several files to install in addition to
the main executable.
So, my CMakeLists.txt file looks like:
project("myapp" C)
cmake_minimum_required(VERSION 2.8)
# The executable
add_executable(myapp main.c)
install(TARGETS myapp RUNTIME DESTINATION bin)
# Another file to install
install(FILES ${CMAKE_SOURCE_DIR}/data/myapp.desktop DESTINATION
"${CMAKE_INSTALL_PREFIX}/share/applications")
SET(CPACK_GENERATOR "DEB")
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Damián Nohales")
INCLUDE(CPack)
I execute CMake and build the package in this way:
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=install ..
$ make package
I need to specify a prefix for the installation because I want to test
the application without installing on my whole system.
But the .deb content resulting of executing "make package" is not what I
expected:
DEBIAN
home
user
projects
myapp
build
install
share
applications
myapp.desktop
usr
bin
myapp
(Note that I'm developing my application on the following directory:
"/home/user/projects/myapp")
Well, I'm sure you are understanding the problem, I'm expecting that the
generated .deb package to has the files under the /usr directory having
too the myapp.desktop file under the following filename
"/usr/share/applications/myapp.desktop".
Any suggestion?
Thanks in advance!
--
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] Complex problem : recursive dependency configurations
As you know, in target_link_libraries(), you can specify "debug", "optimized", or "general" to specify which configurations a library will be applied to. I have developed a system to allow dependencies to recursively add their own dependencies. Suppose we have 3 targets: A: libx liby libz B: foo bar A C: A B Above, I list each target (A, B, C). The items under it are the targets it depends on. So, target A depends on targets named libx, liby, and libz. Similarly, target B depends on targets foo, bar, and A. When I flatten out all of the dependencies for target C, it looks like so: A B libx liby libz foo bar This is pretty simple, but each dependency listed can also have a "debug", "release", or "general" next to it. So let's use the same example as last time, but introduce some of these prefixes: A: libx liby libz B: foo bar A C: debug B Above, since "B" is listed as "debug", library B and all of its dependencies should only build in the debug configuration. So when we flatten this out, you will see the following. Note that this flattened list is what is sent to target_link_libraries() debug B debug foo debug bar debug A debug libx debug liby debug libz Now where this REALLY gets confusing, is when we have a mixture of "conflicts", where the same target is specified as a dependency twice, but with different configuration prefixes: A: libx liby libz B: foo bar A C: optimized A debug B In this case, A's dependencies are specified as optimized, but B's are specified as debug, but B also depends on A, so A's dependencies would be debug as well. I need to implement a system that can handle such conflicts and resolve them appropriately. For example, the way A's dependencies would be resolved is by specifying them as "general" or no prefix at all, since the flattened list includes them both in debug and optimized. So the final, flattened list would look like: A debug B libx liby libz debug foo debug bar This is VERY complex and due to the way lists work and stuff, I can't think of how to do this. Any tips? - Robert Dailey -- 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] CTest: Glob files to include in coverage report with 0% line coverage
Hi, Setting CTEST_EXTRA_COVERAGE_GLOB in the CTestCustom.cmake file can be used to add additional files which shall be included in the coverage report. This is useful to ensure that files which are not covered by any test are still reported with 0% line coverage. I tried using absolute paths in the glob expressions, which did not work. Only paths relative to the project's source directory worked for me. Now I have a scenario, where certain source files are configured/copied to the build tree. It seems that these files are, however, not considered by CTest. I assume the extra coverage glob looks only for files in the source tree? Is there any way I can ensure that uncovered files, such as .txx files, which are located in the build tree are added to the coverage report with 0% line coverage? Thanks, Andreas -- 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] MACOSX_BUNDLE for a shell script application
Hi,
I wish to package up a collection of dylibs, python scripts and a
starter shell script as a MACOSX_BUNDLE
E.g. given a file startup.sh
Is there some way to do something like (but as a MACOSX_BUNDLE)
add_executable ( STARTUP_SCRIPT IMPORTED IMPORTED_LOCATION
${CMAKE_SOURCE_DIR}/startup.sh )
I'd be happy to have a look at other open source project which
already does that and learn from them.
Regards
--
Nicholas Yue
Graphics - RenderMan, Houdini, Visualization, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue
--
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] [New Module] Arduino CMake
On Sunday 22 January 2012, Alfa Omega wrote: > Hi everyone, > > I'm not quite sure what the correct procedure is for becoming a CMake > contributor, but from what I've read I should send a email here if I want > to add a new module to cmake. > > For the past year I've been hosting my CMake modules on GitHub ( > https://github.com/queezythegreat/arduino-cmake) and the project is mature > enough that it could be included into CMake. The project is called Arduino > CMake and it adds support for building Arduino projects. It is a > alternative to the Arduino IDE, and works on Windows, Linux and Mac. > > The project is growing and getting more and more users, and I think it's > would be a god fit to start bundling it with CMake. The project is well > documented both from a developer standpoint as well as the user side. > > So what are the steps I should take in order to integrate my project into > CMake? Does it follow the regular cross compiling conventions ? http://www.vtk.org/Wiki/CMake_Cross_Compiling >From a quick look it didn't look like it does. If so, why did you chose to do it differently ? 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
Re: [CMake] Bug fix requests for the *next* release of CMake...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/23/2012 07:29 PM, Rolf Eike Beer wrote:
> Theodore Papadopoulo wrote:
>> I do not know if it is too late to require bugfix for the next
>> release or even whether this bug is known (a quick browsing of
>> buzilla shows nothing and the git sources still contain the bug),
>> but in any case.
>>
>> In cmake-2.8.6, the module FindLAPACK.cmake contains the lines:
>>
>> if (CMAKE_SYSTEM_NAME STREQUAL "Linux") # for ubuntu's libblas3gf
>> and liblapack3gf packages set(CMAKE_FIND_LIBRARY_SUFFIXES
>> ${CMAKE_FIND_LIBRARY_SUFFIXES} .so.3gf) endif ()
>
> AFAICS this just adds another suffix, but will not remove an
> existing one, so this should not make anything go undetected that
> was detected before. You can try yourself if you just comment out
> this lines.
I did that (not by deleting the line but by just keeping .so instead
of .so.3gf, and then the detection works...
Hum strange...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8dwNgACgkQEr8WrU8nPV2O8gCZAYxLCMkSbKO3SZpfJkD35w8N
ILwAoIIaesT3t5vL+IbgRKfAjT342+y7
=f5g0
-END PGP SIGNATURE-
--
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] Help! Is anyone embedding a ttype library?
From issue 12909: (rc.exe cannot find generated type library, Visual Studio 10 builder) I have an IDL file that generates a type library, and an RC file that wants to embed it. The .tlb is emitted here: C:\build\easyrtd.vs10\EasyRTD\easyrtd.dir\Debug>dir *.tlb Volume in drive C has no label. Volume Serial Number is 5AB0-0B44 Directory of C:\build\easyrtd.vs10\EasyRTD\easyrtd.dir\Debug 23/01/2012 18:52 2,612 EasyRTD.tlb 1 File(s) 2,612 bytes 0 Dir(s) 171,651,473,408 bytes free there is no obvious sign of the rc file (easyrtd.rc) in the working build directory, but if I insert a #error statement I get: 1>C:\src\easyrtd\EasyRTD\easyrtd.src\EasyRTD.rc(21): error RC2188: C:\build\easyrtd.vs10\EasyRTD\EasyRTD.dir\Debug\RCa03492(25) : fatal error RC1116: RC terminating after preprocessor errors 1> which suggests that the file was copied over, if temporarily. Unfortunately I cannot say: 2 TYPELIB "EasyRTD.tlb" since rc.exe fails to find the file. I can say: 2 TYPELIB "c:\build\easyrtd.vs10\EasyRTD\easyrtd.dir\Debug\EasyRTD.tlb" or, I can say: 2 TYPELIB "EasyRTD.tlb" if I also (don't laugh!) say in CMakeLists.txt: include_directories(. c:/build/easyrtd.vs10/EasyRTD/easyrtd.dir/Debug) before the source definition. This seems to me a fundamental part of COM server development. Is there a sane recipe I can use? (Even something that will get the correct build dir name into the include_directories command? Tho I'm concerned the dependency settings might not be quite right if the RC scanner doesn't treat TYPELIB as a resource search and embedding operation.) Thanks James -- 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] Different memcheck options for different tests
On Mon, Jan 23, 2012 at 2:26 PM, Andreas Schuh wrote: > Hi Roland, > > have you considered writing a CTest script which you would run as follows: > > ctest -S your_script.ctest > > ? > > In your CTest script, you can use the commands > > ctest_start() > ctest_configure() > ctest_build() > > set (CTEST_MEMORYCHECK_COMMAND_OPTIONS "...") > ctest_memcheck() where you include only certain tests > > set (CTEST_MEMORYCHECK_COMMAND_OPTIONS "...") > ctest_memcheck() where you include only certain tests > > set (CTEST_MEMORYCHECK_COMMAND_OPTIONS "...") > ctest_memcheck() where you include only certain tests > > ... > > ctest_submit() > > Have a closer look at the documentation of these functions that you > can use in your CTest script at > http://www.cmake.org/cmake/help/ctest-2-8-docs.html#section_Commands. > > I am not certain if setting the CTEST_MEMORYCHECK_COMMAND_OPTIONS in > between calls to ctest_memcheck() works as expected. Maybe you would > need to do also the ctest_configure() and ctest_build() steps before > again, but I would hope not... > > Andreas > > > On Fri, Dec 16, 2011 at 5:05 PM, Roland Schulz wrote: >> Hi, >> >> how can I specify different memcheck options (e.g. >> CTEST_MEMORYCHECK_COMMAND_OPTIONS) for different tests. Ideally I >> would like to be able to specify it depending on the test label or the >> directory. >> >> Ideally I could run "ctest -D ExperimentalMemCheck" and each test >> would be run with the respective options. >> But it would also be OK to have to run ctest more than once for the >> different labels. >> >> I have tried: >> 1) setting CTEST_MEMORYCHECK_COMMAND_OPTIONS different in the >> respective CMakeLists.txt per folder >> 2) setting CTEST_MEMORYCHECK_COMMAND_OPTIONS as an environment >> variable before executing ctest. >> >> This both doesn't seem to work. >> >> What would be the best approach to set different options for different tests? >> >> Roland >> >> -- >> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov >> 865-241-1537, ORNL PO BOX 2008 MS6309 >> -- >> >> 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 But be aware: each ctest_memcheck call will generate an xml file that needs submitting to CDash. Each call overwrites the previous one's file... To avoid losing data, also do a partial submit after each memcheck call in this case. Something like: ctest_memcheck(...) ctest_submit(PARTS MemCheck) ctest_memcheck(...) ctest_submit(PARTS MemCheck) HTH, David -- 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] Different memcheck options for different tests
Hi Roland, have you considered writing a CTest script which you would run as follows: ctest -S your_script.ctest ? In your CTest script, you can use the commands ctest_start() ctest_configure() ctest_build() set (CTEST_MEMORYCHECK_COMMAND_OPTIONS "...") ctest_memcheck() where you include only certain tests set (CTEST_MEMORYCHECK_COMMAND_OPTIONS "...") ctest_memcheck() where you include only certain tests set (CTEST_MEMORYCHECK_COMMAND_OPTIONS "...") ctest_memcheck() where you include only certain tests ... ctest_submit() Have a closer look at the documentation of these functions that you can use in your CTest script at http://www.cmake.org/cmake/help/ctest-2-8-docs.html#section_Commands. I am not certain if setting the CTEST_MEMORYCHECK_COMMAND_OPTIONS in between calls to ctest_memcheck() works as expected. Maybe you would need to do also the ctest_configure() and ctest_build() steps before again, but I would hope not... Andreas On Fri, Dec 16, 2011 at 5:05 PM, Roland Schulz wrote: > Hi, > > how can I specify different memcheck options (e.g. > CTEST_MEMORYCHECK_COMMAND_OPTIONS) for different tests. Ideally I > would like to be able to specify it depending on the test label or the > directory. > > Ideally I could run "ctest -D ExperimentalMemCheck" and each test > would be run with the respective options. > But it would also be OK to have to run ctest more than once for the > different labels. > > I have tried: > 1) setting CTEST_MEMORYCHECK_COMMAND_OPTIONS different in the > respective CMakeLists.txt per folder > 2) setting CTEST_MEMORYCHECK_COMMAND_OPTIONS as an environment > variable before executing ctest. > > This both doesn't seem to work. > > What would be the best approach to set different options for different tests? > > Roland > > -- > ORNL/UT Center for Molecular Biophysics cmb.ornl.gov > 865-241-1537, ORNL PO BOX 2008 MS6309 > -- > > 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] CTest build/configure not appending
On Mon, Jan 23, 2012 at 12:45 PM, Tim Gallagher
wrote:
> Hi,
>
> I have a CTest script that builds many different tests and sets it to APPEND
> by doing:
>
> foreach(TESTCASE ${LESLIE_AVAILABLE_TESTCASES})
> set(CTEST_CONFIGURE_COMMAND "./setup.py -t ${TESTCASE}
> '{${LESLIE_CONFIGURE_DICT_BASE}}'")
> ctest_configure(BUILD "${CTEST_REPO_DIRECTORY}" APPEND)
> set(CTEST_BUILD_COMMAND "./setup.py -t ${TESTCASE}
> '{${LESLIE_BUILD_DICT_BASE}}'")
> ctest_build(BUILD "${CTEST_REPO_DIRECTORY}" APPEND)
> endforeach()
>
> But, when I look in the configure.xml and build.xml, or check the dashboard,
> it only has the final test case information. It doesn't have the 96 previous
> ones.
>
> Does append not do what I think it should do?
>
> Tim
> --
>
> 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
APPEND does not do what you think it should do. It sets a flag in the
generated xml file to tell CDash to append it to the existing results
when submitted. It does not append to an existing xml file.
Each call to ctest_configure generates a Configure.xml file, each
ctest_build a Build.xml file. You must call something like:
ctest_submit(PARTS Configure Build)
before the endforeach so that ctest can submit the xml files it has
each time through the loop.
HTH,
David
--
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] Bug fix requests for the *next* release of CMake...
Theodore Papadopoulo wrote:
> I do not know if it is too late to require bugfix for the next release
> or even whether this bug is known (a quick browsing of buzilla shows
> nothing and the git sources still contain the bug), but in any case.
>
> In cmake-2.8.6, the module FindLAPACK.cmake contains the lines:
>
> if (CMAKE_SYSTEM_NAME STREQUAL "Linux")
># for ubuntu's libblas3gf and liblapack3gf packages
>set(CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES} .so.3gf)
> endif ()
AFAICS this just adds another suffix, but will not remove an existing one, so
this should not make anything go undetected that was detected before. You can
try yourself if you just comment out this lines.
I think this may be something entirely different, that I have seen today for
completely unrelated modules: if the library is in /usr/lib64 like on my
openSuSE 12.1, the library is sometimes not detected. When trying it on my
machine at home it works like a charm. I've not entirely understood what was
wrong there and had no time yet to debug this.
Eike
signature.asc
Description: This is a digitally signed message part.
--
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] Possible? Post CTest xml files to CDash w/o ctest/build tree?
Hi, I have been asked to run our ctest regression suite on a machine that is heavily firewalled. This means that I cannot use 'ctest_submit()' from my ctest script to post the results to our CDash web site. Through some script magic I can move the CTest xml files to a machine that can see our CDash server. Is there a way to post these xml results to CDash w/o having the full ctest/build tree available? Do you have an example? Thanks, -kt --- Kelly Thompson -- 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] CTest build/configure not appending
Hi,
I have a CTest script that builds many different tests and sets it to APPEND by
doing:
foreach(TESTCASE ${LESLIE_AVAILABLE_TESTCASES})
set(CTEST_CONFIGURE_COMMAND "./setup.py -t ${TESTCASE}
'{${LESLIE_CONFIGURE_DICT_BASE}}'")
ctest_configure(BUILD "${CTEST_REPO_DIRECTORY}" APPEND)
set(CTEST_BUILD_COMMAND "./setup.py -t ${TESTCASE}
'{${LESLIE_BUILD_DICT_BASE}}'")
ctest_build(BUILD "${CTEST_REPO_DIRECTORY}" APPEND)
endforeach()
But, when I look in the configure.xml and build.xml, or check the dashboard, it
only has the final test case information. It doesn't have the 96 previous ones.
Does append not do what I think it should do?
Tim
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack -G NSIS
It's a bit tricky to follow the code, but from my first attempt with the
debug symbols activated I get the following backtrace:
(running cpack -G NSIS)
--8<---cut here---start->8---
(gdb) bt
#0 0x76e28935 in raise () from /lib/libc.so.6
#1 0x76e29dab in abort () from /lib/libc.so.6
#2 0x7775d1ed in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/libstdc++.so.6
#3 0x7775b396 in ?? () from /usr/lib/libstdc++.so.6
#4 0x7775b3c3 in std::terminate() () from /usr/lib/libstdc++.so.6
#5 0x7775b4be in __cxa_throw () from /usr/lib/libstdc++.so.6
#6 0x777081f7 in std::__throw_logic_error(char const*) () from
/usr/lib/libstdc++.so.6
#7 0x77746039 in char* std::string::_S_constructconst*>(char const*, char const*, std::allocator const&,
std::forward_iterator_tag) () from /usr/lib/libstdc++.so.6
#8 0x77746113 in std::basic_stringstd::char_traits, std::allocator >::basic_string(char
const*, std::allocator const&) () from /usr/lib/libstdc++.so.6
#9 0x0066e5f8 in cmCPackNSISGenerator::InitializeInternal
(this=0xd20b20) at
/home/andrea/cmake/Source/CPack/cmCPackNSISGenerator.cxx:410
#10 0x0065c444 in cmCPackGenerator::Initialize (this=0xd20b20,
name=0xd1c248 "NSIS", mf=0x7fffcfe0) at
/home/andrea/cmake/Source/CPack/cmCPackGenerator.cxx:1104
#11 0x0064d553 in main (argc=3, argv=0x7fffe568) at
/home/andrea/cmake/Source/CPack/cpack.cxx:400
--8<---cut here---end--->8---
In particular it seems that the problem is trying to get this option:
file:~/cmake/Source/CPack/cmCPackNSISGenerator.cxx::std::string
nsisFileName = this->GetOption("CPACK_TOPLEVEL_DIRECTORY")
Which fails here:
file:~/cmake/Source/CPack/cmCPackGenerator.cxx::const char*
cmCPackGenerator::GetOption(const char* op) const
that thing returs 0x0 and the std::string explodes because it was not
what it was expecting..
That's all I could understand for now..
--
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] Bug fix requests for the *next* release of CMake...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I do not know if it is too late to require bugfix for the next release
or even whether this bug is known (a quick browsing of buzilla shows
nothing and the git sources still contain the bug), but in any case.
In cmake-2.8.6, the module FindLAPACK.cmake contains the lines:
if (CMAKE_SYSTEM_NAME STREQUAL "Linux")
# for ubuntu's libblas3gf and liblapack3gf packages
set(CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES} .so.3gf)
endif ()
The problem here is that not all linux distribution are ubuntu, as a
result the lapack detection is broken on releases such as Fedora (14
to 16).
Is there a way to make this test more specific, or at least to provide
an option to let the user disable this "feature".
In the meantime, it might be interesting to have a patch in the fedora
package that just removes the .3gf (Orion I put you in copy just in
case, as I saw you are the fedora packager for cmake).
Thank you very much,
Theo Papadopoulo.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8dltsACgkQEr8WrU8nPV2k7ACeOD8Df7A6wTPUNVCyiBDP4R4j
T6kAoJsnekGUH1s7AseXPwuB6teq4ujo
=ws/T
-END PGP SIGNATURE-
--
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] Setting intermediate directory permissions?
I want to force all the install permissions to be only owner accessible. I've done this everywhere using DIRECTORY_PERMISSIONS and FILE_PERMISSIONS. But, intermediate directories created by installing targets get some default permissions (in my case, 0755). I don't want to require the builder or build system to have their umask set properly. Is there a way to specify the permissions used for these intermediate directories? This looks related to the below issue, and some of it's related issues. http://public.kitware.com/Bug/view.php?id=9620 Thanks, Kevin -- 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] Revision header
On Saturday, 21. January 2012, 22:51:01, Oliver Smith wrote: > I have a script that generates a revision.h file, I've spent the morning > trying to figure out how to make it so that ... any time CMake rebuilds > any of the other targets, it starts by running the make-new-revision > script. > > The idea is, I use the script manually to upversion, but anytime I type > "make" and /anything/ has to be done (even just a relink), it will do > the upversion first. > > I've only managed to make it either source dependent or always build, > which forces the versionNo file to recompile and forces all executables > to relink, so if you type: > > make ; make ... it will have to relink the executables the second time > because of an pointless upversion :) I guess the most efficient way is to fix your upversion script so that it only overwrites revision.h if it actually changed. This way you can execute it every time without having it mess up the dependency tracking... Johannes -- 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
