[cmake-developers] [PATCH] Tell CTest about Apache Maven warnings
Hi,
we had a lot of fun debugging our nightly builds in the last couple of days.
Part of our build process are some programs that get build using Apache Maven
and are used to generate other files later on. It's something like this:
ADD_CUSTOM_COMMAND(
OUTPUT ${artifact}
DEPENDS ${sources}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
COMMAND ${MAVEN_EXECUTABLE} --quiet install
COMMENT Building Java artifacts using Apache Maven...
VERBATIM
)
ADD_CUSTOM_TARGET(${target} ALL DEPENDS ${artifact})
And then some other ADD_CUSTOM_COMMANDS that depend on ${target}. When this
was run on any of our desktops it worked fine, when we log in to the build
machines it works fine, but when it runs with cron it doesn't work (not even
on the Windows hosts). Since the first errors we got in CDash log were those
of the target files that could not be generated because the maven output was
missing we suspected some sort of dependency problem. It took us a while to
find out that the dependencies were fine and Maven really wrote out some
errors but CTest just didn't catch them. At the end it was just JAVA_HOME
environment not being set when running with cron (easily fixed by source
/etc/profile in the nightly script).
To prevent other people wasting their time hunting bugs that are simply not
there: here is a small patch that tells CTest to detect Mavens error and
warning messages.
Eike
From 36fdcaf33df5435a3f351158c8e1a3040518d210 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer e...@sf-mail.de
Date: Fri, 18 Mar 2011 09:38:34 +0100
Subject: [PATCH] CTest: catch warning output of Apache Maven
Some samples of things that got unnoticed by our nightly builds:
$ JAVA_HOME= mvn
Warning: JAVA_HOME environment variable is not set.
...
$ mvn
[INFO] Scanning for projects...
[INFO]
[ERROR] BUILD FAILURE
...
---
Source/CTest/cmCTestBuildHandler.cxx |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Source/CTest/cmCTestBuildHandler.cxx b/Source/CTest/cmCTestBuildHandler.cxx
index 9678ac4..86bd85d 100644
--- a/Source/CTest/cmCTestBuildHandler.cxx
+++ b/Source/CTest/cmCTestBuildHandler.cxx
@@ -93,6 +93,7 @@ static const char* cmCTestErrorMatches[] = {
: No such file or directory,
: Invalid argument,
^The project cannot be built\\.,
+ ^\\[ERROR\\],
0
};
@@ -119,7 +120,7 @@ static const char* cmCTestWarningMatches[] = {
^\[^\]+\, line [0-9]+: [Ww](arning|arnung),
([^:]+): warning[ \\t]*[0-9]+[ \\t]*:,
^(Warning|Warnung) ([0-9]+):,
- ^(Warning|Warnung) ,
+ ^(Warning|Warnung)[ :],
WARNING: ,
([^ :]+) : warning,
([^:]+): warning,
@@ -131,6 +132,7 @@ static const char* cmCTestWarningMatches[] = {
\.*\, line [0-9]+: remark\\([0-9]*\\):,
cc-[0-9]* CC: REMARK File = .*, Line = [0-9]*,
^CMake Warning.*:,
+ ^\\[WARNING\\],
0
};
--
1.7.3.4
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
I'm trying to get the entire hdf5 project compiling with the fortran stuff
enabled, but I've run into an issue
The solution has mixed fortran and c targets, and it adds dependency
information which includes the project file extension
cmVisualStudio10TargetGenerator::WriteProjectReferences ...
if (dt-GetProperty(Fortran_MODULE_DIRECTORY))
{
path += .vfproj;
}
else {
path += .vcxproj;
}
I added the .vfproj clause to try to get the h5fortran_detect projects to be
classed as vfproj (otherwise the custom rules which generate .f90 files don't
run it seems - I'm still trying to work out exactly what's wrong, but this is
one guess)...
Anyway the dt-GetProperty(Fortran_MODULE_DIRECTORY) always returns true,
even if one of the C projects is the target - because it is globally for the
cmake project.
What I need is a if target_link_language == fortran (or if target is
fortrantarget) then use this extension, otherwise ...
How can I test if one of the individual targets is using fortran of not.
My best guess so far is to add a method to cmTarget to iterate over source
files and test their extensions individually, but I'm sure there must be a
correct way of doing it.
TIA
JB
Git fortrancomposerbranch pushed to
git://git.cscs.ch/cmake.git
it's only my test hack to get stuff working, I'll clean it up once I am
confident that I can build complex projects.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Tell CTest about Apache Maven warnings
Thanks. Looks reasonable. Merged/pushed to next:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fcf3208ac10942344d4e7302ca8351758ba26978
Expect it in the next release.
thx,
David
On Fri, Mar 18, 2011 at 4:51 AM, Rolf Eike Beer e...@sf-mail.de wrote:
Hi,
we had a lot of fun debugging our nightly builds in the last couple of days.
Part of our build process are some programs that get build using Apache Maven
and are used to generate other files later on. It's something like this:
ADD_CUSTOM_COMMAND(
OUTPUT ${artifact}
DEPENDS ${sources}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
COMMAND ${MAVEN_EXECUTABLE} --quiet install
COMMENT Building Java artifacts using Apache Maven...
VERBATIM
)
ADD_CUSTOM_TARGET(${target} ALL DEPENDS ${artifact})
And then some other ADD_CUSTOM_COMMANDS that depend on ${target}. When this
was run on any of our desktops it worked fine, when we log in to the build
machines it works fine, but when it runs with cron it doesn't work (not even
on the Windows hosts). Since the first errors we got in CDash log were those
of the target files that could not be generated because the maven output was
missing we suspected some sort of dependency problem. It took us a while to
find out that the dependencies were fine and Maven really wrote out some
errors but CTest just didn't catch them. At the end it was just JAVA_HOME
environment not being set when running with cron (easily fixed by source
/etc/profile in the nightly script).
To prevent other people wasting their time hunting bugs that are simply not
there: here is a small patch that tells CTest to detect Mavens error and
warning messages.
Eike
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
if(cmTarget::LinkInterface const* iface = dt-GetLinkInterface(Debug))
{
if (iface-Languages.size()0 iface-Languages[0]==Fortran)
{
path += .vfproj;
}
Seems to work.
-Original Message-
From: cmake-developers-boun...@cmake.org
[mailto:cmake-developers-boun...@cmake.org] On Behalf Of Biddiscombe, John A.
Sent: 18 March 2011 14:19
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] VS2010 fortran composer
I'm trying to get the entire hdf5 project compiling with the fortran stuff
enabled, but I've run into an issue
The solution has mixed fortran and c targets, and it adds dependency
information which includes the project file extension
cmVisualStudio10TargetGenerator::WriteProjectReferences ...
if (dt-GetProperty(Fortran_MODULE_DIRECTORY))
{
path += .vfproj;
}
else {
path += .vcxproj;
}
I added the .vfproj clause to try to get the h5fortran_detect projects to be
classed as vfproj (otherwise the custom rules which generate .f90 files don't
run it seems - I'm still trying to work out exactly what's wrong, but this is
one guess)...
Anyway the dt-GetProperty(Fortran_MODULE_DIRECTORY) always returns true,
even if one of the C projects is the target - because it is globally for the
cmake project.
What I need is a if target_link_language == fortran (or if target is
fortrantarget) then use this extension, otherwise ...
How can I test if one of the individual targets is using fortran of not.
My best guess so far is to add a method to cmTarget to iterate over source
files and test their extensions individually, but I'm sure there must be a
correct way of doing it.
TIA
JB
Git fortrancomposerbranch pushed to
git://git.cscs.ch/cmake.git
it's only my test hack to get stuff working, I'll clean it up once I am
confident that I can build complex projects.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
2011/3/18 Bill Hoffman bill.hoff...@kitware.com: The commits that went in this day: http://www.cdash.org/CDash/viewChanges.php?project=CMakedate=2011-03-12 Caused memory leaks to show up here: http://www.cdash.org/CDash/viewDynamicAnalysisFile.php?id=1142597 May be for me. I'll have a look tonight. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New Cmake module - Armadillo C++
On Thursday 17 March 2011, creusot wrote:
Hi Alex,
Thanks for your help.
I have changed the FindArmadillo.cmake file using your comments.
The file is attached to this email.
I also modified Armadillo installation. A new ArmadilloConfig.cmake file
is installed in ${INSTALL_DATA_DIR}/Armadillo/cmake/. It works well,
thanks for the tips.
Clement.
On 16/03/11 19:16, Alexander Neundorf wrote:
Hi Clement,
On Wednesday 16 March 2011, creusot wrote:
Hi everybody,
I would like to propose a new cmake module for the Armadillo C++
library. http://arma.sourceforge.net/
This library provides fast linear algebra methods with an interface very
similar to octave code:
colvec x = solve(A,b);
colvec x = inv(trans(A)*A)*trans(A)*b ;
I have attached the FindArmadillo.cmake file to this email.
I propose myself as Module maintainer for Armadillo C++.
My details: Clement Creusot (creu...@cs.york.ac.uk)
Can you tell me if I need to do other steps (in addition to sending this
email) ?
Here you can find more information, please follow the links there:
http://www.vtk.org/Wiki/CMake:Module_Maintainers
IMO technically the attached file looks good now.
Now please follow the steps described in the link above to become a cmake
module maintainer.
Thanks for your contribution
Alex
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
On 3/18/2011 11:00 AM, Eric Noulard wrote: 2011/3/18 Bill Hoffmanbill.hoff...@kitware.com: The commits that went in this day: http://www.cdash.org/CDash/viewChanges.php?project=CMakedate=2011-03-12 Caused memory leaks to show up here: http://www.cdash.org/CDash/viewDynamicAnalysisFile.php?id=1142597 May be for me. I'll have a look tonight. With a closer look, it seems that it is actually crashing under valgrind: ==21354== ==21354== Invalid read of size 1 ==21354==at 0x4C270C2: strlen (mc_replace_strmem.c:242) ==21354==by 0x530886B: std::string::operator+=(char const*) (in /usr/lib/libstdc++.so.6.0.10) ==21354==by 0x613511: cmCPackDebGenerator::createDeb() (cmCPackDebGenerator.cxx:303) ==21354==by 0x617227: cmCPackDebGenerator::PackageFiles() (cmCPackDebGenerator.cxx:292) ==21354==by 0x5FC1EC: cmCPackGenerator::DoPackage() (cmCPackGenerator.cxx:1012) ==21354==by 0x5EA0CE: main (cpack.cxx:430) ==21354== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==21354== ==21354== Process terminating with default action of signal 11 (SIGSEGV) ==21354== Access not within mapped region at address 0x0 ==21354==at 0x4C270C2: strlen (mc_replace_strmem.c:242) ==21354==by 0x530886B: std::string::operator+=(char const*) (in /usr/lib/libstdc++.so.6.0.10) ==21354==by 0x613511: cmCPackDebGenerator::createDeb() (cmCPackDebGenerator.cxx:303) ==21354==by 0x617227: cmCPackDebGenerator::PackageFiles() (cmCPackDebGenerator.cxx:292) ==21354==by 0x5FC1EC: cmCPackGenerator::DoPackage() (cmCPackGenerator.cxx:1012) ==21354==by 0x5EA0CE: main (cpack.cxx:430) ==21354== If you believe this happened as a result of a stack overflow in your ==21354== program's main thread (unlikely but possible), you can try to increase ==21354== the size of the main thread stack using the --main-stacksize= flag. ==21354== The main thread stack size used in this run was 8388608. ==21354== -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] New Cmake module - Armadillo C++
Hi Alex, I did followed the steps on the website: - formatting the cmake file - subscribing to the mailing list - sending an email with the new module If there is something to do next, it is not clear what it is. Is there someone to contact to include the file on the CVS? Clement Here you can find more information, please follow the links there: http://www.vtk.org/Wiki/CMake:Module_Maintainers IMO technically the attached file looks good now. Now please follow the steps described in the link above to become a cmake module maintainer. Thanks for your contribution Alex Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
2011/3/18 Bill Hoffman bill.hoff...@kitware.com: On 3/18/2011 11:00 AM, Eric Noulard wrote: 2011/3/18 Bill Hoffmanbill.hoff...@kitware.com: The commits that went in this day: http://www.cdash.org/CDash/viewChanges.php?project=CMakedate=2011-03-12 Caused memory leaks to show up here: http://www.cdash.org/CDash/viewDynamicAnalysisFile.php?id=1142597 May be for me. I'll have a look tonight. With a closer look, it seems that it is actually crashing under valgrind: Yes but this could be a real symptom a memory corruption. What is the simplest way for me to run the same valgrind test locally? Which ctest one line command, may use for that? ==21354== ==21354== Invalid read of size 1 ==21354== at 0x4C270C2: strlen (mc_replace_strmem.c:242) ==21354== by 0x530886B: std::string::operator+=(char const*) (in /usr/lib/libstdc++.so.6.0.10) ==21354== by 0x613511: cmCPackDebGenerator::createDeb() (cmCPackDebGenerator.cxx:303) ==21354== by 0x617227: cmCPackDebGenerator::PackageFiles() (cmCPackDebGenerator.cxx:292) ==21354== by 0x5FC1EC: cmCPackGenerator::DoPackage() (cmCPackGenerator.cxx:1012) ==21354== by 0x5EA0CE: main (cpack.cxx:430) ==21354== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==21354== ==21354== Process terminating with default action of signal 11 (SIGSEGV) ==21354== Access not within mapped region at address 0x0 ==21354== at 0x4C270C2: strlen (mc_replace_strmem.c:242) ==21354== by 0x530886B: std::string::operator+=(char const*) (in /usr/lib/libstdc++.so.6.0.10) ==21354== by 0x613511: cmCPackDebGenerator::createDeb() (cmCPackDebGenerator.cxx:303) ==21354== by 0x617227: cmCPackDebGenerator::PackageFiles() (cmCPackDebGenerator.cxx:292) ==21354== by 0x5FC1EC: cmCPackGenerator::DoPackage() (cmCPackGenerator.cxx:1012) ==21354== by 0x5EA0CE: main (cpack.cxx:430) ==21354== If you believe this happened as a result of a stack overflow in your ==21354== program's main thread (unlikely but possible), you can try to increase ==21354== the size of the main thread stack using the --main-stacksize= flag. ==21354== The main thread stack size used in this run was 8388608. ==21354== -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
On 3/18/2011 3:52 PM, Eric Noulard wrote: Yes but this could be a real symptom a memory corruption. What is the simplest way for me to run the same valgrind test locally? Which ctest one line command, may use for that? That said... The problem seems to be here: dbfilename += this-GetOption(WDIR); My guess is WDIR is returning null from GetOption in this test which causes the crash. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
2011/3/18 Bill Hoffman bill.hoff...@kitware.com: On 3/18/2011 3:52 PM, Eric Noulard wrote: Yes but this could be a real symptom a memory corruption. What is the simplest way for me to run the same valgrind test locally? Which ctest one line command, may use for that? That said... The problem seems to be here: dbfilename += this-GetOption(WDIR); My guess is WDIR is returning null from GetOption in this test which causes the crash. Yes you are right about the symptom. The fact is we should never get to this point, because the reading of CPackDeb.cmake have failed. -- stderr='CMake Error at /home/eric/workspace/CMake-gitted/Modules/CPackDeb.cmake:274 (MESSAGE): CPackDeb: Debian package requires a maintainer for a package, set CPACK_PACKAGE_CONTACT or CPACK_DEBIAN_PACKAGE_MAINTAINER The CPackTestAllGenerators was probably failing to run CPackDeb since the beginning (of the existence of CPackDeb) but without crash :-] I'll fix it, not sure I have time to do it tonight but tomorrow for sure. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] memory leaks in cpack
2011/3/18 Eric Noulard eric.noul...@gmail.com: 2011/3/18 Bill Hoffman bill.hoff...@kitware.com: On 3/18/2011 3:52 PM, Eric Noulard wrote: Yes but this could be a real symptom a memory corruption. What is the simplest way for me to run the same valgrind test locally? Which ctest one line command, may use for that? That said... The problem seems to be here: dbfilename += this-GetOption(WDIR); My guess is WDIR is returning null from GetOption in this test which causes the crash. Yes you are right about the symptom. The fact is we should never get to this point, because the reading of CPackDeb.cmake have failed. -- stderr='CMake Error at /home/eric/workspace/CMake-gitted/Modules/CPackDeb.cmake:274 (MESSAGE): CPackDeb: Debian package requires a maintainer for a package, set CPACK_PACKAGE_CONTACT or CPACK_DEBIAN_PACKAGE_MAINTAINER Is it the expected behavior to have bool cmCPackGenerator::ReadListFile(const char* moduleName) return true when the processed list file exited because of a: MESSAGE(FATAL_ERROR Whatever) how can I know whether if the processing of a list file encountered a message(ERROR message(FATAL_ERROR or return ? I can add some VAR RUN_OK to the concerned list file (CPackDeb.cmake) in order to know if it was processed without error but I find it awkward. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
