Re: [CMake] CMake 2.8.6-rc2 ready for testing!
Hello Dave, Am 05.09.2011 18:29, schrieb Johannes Stallkamp: > > http://www.cmake.org/Bug/view.php?id=12260 > > is listed with target 2.8.6, but it's not listed in the changes (yet?). > > Will it be fixed for the next release or will it be pushed to 2.8.7? > > > Thank you, for fixing this. I will try your fix as soon as possible, but I will be out of office tomorrow. 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
Re: [CMake] CMake 2.8.6-rc2 ready for testing!
Hello, http://www.cmake.org/Bug/view.php?id=12260 is listed with target 2.8.6, but it's not listed in the changes (yet?). Will it be fixed for the next release or will it be pushed to 2.8.7? Regards 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
Re: [CMake] Bug fix requests for the *next* release of CMake...
Probably a bit late, but I was on vacaction: http://www.cmake.org/Bug/view.php?id=12260 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
Re: [CMake] CMake 2.8.5-rc1 ready for testing!
Hi, Would be great if http://www.cmake.org/Bug/view.php?id=12260 would make it into 2.8.5. Best 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
Re: [CMake] CTest incorrectly parses valgrind output
Hi, > Yes. And please use unified diff format. Preferred is if you could > do a checkout of CMake git and commit your patch (locally) and then > do "git format-patch HEAD^" and attach the resulting 0001-* file to > the bug. > Just did so. Hope the patch format is correct. Please advise, if not. http://www.cmake.org/Bug/view.php?id=12260 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
Re: [CMake] CTest incorrectly parses valgrind output
Hi, Am 09.06.2011 13:20, schrieb Michael Wild: > On 06/09/2011 01:11 PM, Rolf Eike Beer wrote: >>> Hi, >>> >>> I just notied that CTest 2.8.4 incorrectly parses valgrind's memcheck >>> output because it does not always take into account that numbers >>> reported by valgrind can be larger than 1,000 and then will contain a >>> comma as thousand-delimiter. Therefore, many errors/potential errors >>> are not correctly reported in the dashboard. >>> >>> Am I missing anything? >>> >>> The attached patch solves the problem. I hope I caught all cases. >>> Should I open a bug report for this? >> >> Yes. And please use unified diff format. Preferred is if you could do a >> checkout of CMake git and commit your patch (locally) and then do "git >> format-patch HEAD^" and attach the resulting 0001-* file to the bug. >> >> Just from a quick look: shouldn't the regex be something like >> [0-9]*(,[0-9]*)*? >> >> Eike > > > Isn't the separator locale-dependent? What does the output look like if > LC_ALL=C? Don't know, does valgrind take this into account? I just used the same regex that was already used in _some_ expressions (e.g. the direct/indirect entry) and put in all (?) other locations where it might be required. @Eike: About the parens in the regex: I don't see how 100 % correct parsing is required anyway. IMHO it is sufficient to be able to distinguish between the different valgrind events and not to accidentally include some console output of the test exectuable itself. I will try my best with the you git suggestions (though I am an absolute git newbie.) 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
[CMake] CTest incorrectly parses valgrind output
Hi,
I just noticed that CTest 2.8.4 incorrectly parses valgrind's memcheck
output because it does not always take into account that numbers
reported by valgrind can be larger than 1,000 and then will contain a
comma as thousand-delimiter. Therefore, many errors/potential errors
are not correctly reported in the dashboard.
Am I missing anything?
The attached patch solves the problem. I hope I caught all cases.
Should I open a bug report for this?
Regards
Johannes
Only in clean/cmake-2.8.4/Source/CTest: #cmCTestMemCheckHandler.cxx#
diff -r clean/cmake-2.8.4/Source/CTest/cmCTestMemCheckHandler.cxx
cmake-2.8.4/Source/CTest/cmCTestMemCheckHandler.cxx
663,664c663,664
< "== .*[0-9][0-9]* bytes in [0-9][0-9]* blocks are definitely lost"
<" in loss record [0-9][0-9]* of [0-9]");
---
> "== .*[0-9]*,?[0-9]* bytes in [0-9]*,?[0-9]* blocks are definitely lost"
>" in loss record [0-9]*,?[0-9]* of [0-9]*,?[0-9]*");
666,668c666,668
< "== .*[0-9][0-9]* \\([0-9]*,?[0-9]* direct, [0-9]*,?[0-9]* indirect\\)"
< " bytes in [0-9][0-9]* blocks are definitely lost"
< " in loss record [0-9][0-9]* of [0-9]");
---
> "== .*[0-9]*,?[0-9]* \\([0-9]*,?[0-9]* direct, [0-9]*,?[0-9]* indirect\\)"
> " bytes in [0-9]*,?[0-9]* blocks are definitely lost"
> " in loss record [0-9]*,?[0-9]* of [0-9]*,?[0-9]*");
672,673c672,673
< "== .*[0-9][0-9]* bytes in [0-9][0-9]* blocks are possibly lost in"
< " loss record [0-9][0-9]* of [0-9]");
---
> "== .*[0-9]*,?[0-9]* bytes in [0-9]*,?[0-9]* blocks are possibly lost in"
> " loss record [0-9]*,?[0-9]* of [0-9],?[0-9]*");
675,676c675,676
< "== .*[0-9][0-9]* bytes in [0-9][0-9]* blocks are still reachable"
< " in loss record [0-9][0-9]* of [0-9]");
---
> "== .*[0-9]*,?[0-9]* bytes in [0-9]*,?[0-9]* blocks are still reachable"
> " in loss record [0-9]*,?[0-9]* of [0-9]*,?[0-9]*");
680,681c680,681
< "== .*Use of uninitialised value of size [0-9][0-9]*");
< cmsys::RegularExpression vgUMR2("== .*Invalid read of size [0-9][0-9]*");
---
> "== .*Use of uninitialised value of size [0-9]*,?[0-9]*");
> cmsys::RegularExpression vgUMR2("== .*Invalid read of size [0-9]*,?[0-9]*");
Only in clean/cmake-2.8.4/Source/CTest: cmCTestMemCheckHandler.cxx~
___
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] Dynamic analysis results only for broken tests?
Hello, on our build server, I have set up CTest 2.8.-rc1 to run dynamic analysis with valgrind (3.6.0). Results are submitted to CDash 1.8.2. However, I noticed that only results with at least one error/leak show up in the dashboard. Tests that run flawlessly don't. In the DynamicAnalysis.xml, all tests show up within the TestList-Tags, but Test-Tags are only provided for those tests for which valgrind reports at least one (potential or real) error, no matter whether the test itself passed or failed. Is this intended behaviour? Or could it be caused by any misconfiguration on my end? Kind regards 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
Re: [CMake] Building a Version Header
Am 09.07.2010 12:56, schrieb Michael Hertling: > As the version target is always out of date it will be build each time > you (re)build main, but since CONFIGURE_FILE() obviously does not touch > the output file as long as it won't change, version.h isn't timestamped, > so it doesn't trigger the rebuild of the main target. Hey, that's great. I didn't know that CONFIGURE_FILE does not touch the output file if the content doesn't change. With that knowledge, I can now simplify my scripts which up to now checked manually whether the version number changed and only called CONFIGURE_FILE if this is the case. Where did you find that? Did I miss it in the docs? Thanks 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
Re: [CMake] Building a Version Header
Hi, Am 08.07.2010 22:31, schrieb Tyler Roscoe: > On Wed, Jul 07, 2010 at 10:43:15PM -0400, John Drescher wrote: >> On Wed, Jul 7, 2010 at 9:44 PM, Clark Gaebel wrote: >>> I would like to generate file that looks something like this: >>> >>>// version.h >>>#define VERSION "v0.1-345-ga77ede8" >> >> You want to do that with configure_file > > The upside of this approach is that it's simple. The downside is that it > is only run (and thus your version header is only updated) whenever > CMake runs. It's possible for the source code to change without > triggering a re-run of CMake. We use a custom command to check the SVN revision via a CMake script. I then let the target depend on this project. Within the script, the version header will only be updated if the revision actually changed. Thus, the target is recompiled if and only if the SVN revision changed. 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
Re: [CMake] CMake cross-compilation best practices
Hello Romain, Romain CHANU schrieb: > If I need to compile a library on both Linux and Windows, the best > CMake practice would be to write toolchain files for Linux and > Windows (cf. http://www.cmake.org/Wiki/CMake_Cross_Compiling) > > Is that correct? Do you really want to cross-compile (i.e. build your Linux library on Windows or vice versa) or do you just want to be able to compile your platform-independent library natively on Linux or Windows but with the same CMakeLists.txt ? In the latter case, just go for it. Basically, your Windows CMakeLists.txt should work just fine on Linux and vice versa. You might need to adjust some paths if you use some 3rd party libraries or use some compiler specific additional options. But you can implement that just fine within the same CMakeLists.txt using IF( MSVC ) ENDIF() (or other compiler/system-variables, see http://www.itk.org/Wiki/CMake_Useful_Variables ) HTH 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
[CMake] OpenMP compiler flag questoin
Hello, if I use FIND_PACKAGE( OpenMP ) I get the variables OpenMP_C_FLAGS and OpenMP_CXX_FLAGS correctly set to "/openmp" for VC2005. Is it correct behaviour that these are not automatically added to the CMAKE_CXX_FLAGS_[RELEASE|DEBUG] variables (and thus, the option is not configured in VC's project file)? Regards 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
[CMake] CTest coverage test and external subdirs
Hello, I am still trying to get ctest working on our directory structure. Thanks to the bugfix in 2.8, running the test itself works fine. However, there seems to be an issue with code coverage testing. Assuming the following directory structure: projects/ libFoo/ cmake CMakeLists.txt CTestConfig.cmake include Foo.h src Foo.cpp FooTest.cpp appBar/ cmake CMakeLists.txt CTestConfig.cmake include Bar.h src Bar.cpp Bar is an application that relies on libFoo. After building appBar, "make test" runs flawlessly. However, running ctest -T Coverage reports Covered/Total LOC of zero. I think this is related to the fact, that ctest tries to exclude system libraries and other external files from the coverage check by ignoring external directories. However, since CTest now allows absolute paths in its SUBDIRS command, I think it should consider the files in those directories as well (or to be more precise, the files in/below the "SourceDirectory" in that directory's/component's DartConfiguration.tcl). Or am I missing something? Kind regards 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
Re: [CMake] CTest: another sub-directory issue / coverage test
Richard, Richard Wackerbarth schrieb: > Johannes, > > Is there any compelling reason to place the cmake "control files" in a > directory under the root? > > Foo/ >CMakeLists.txt >CTestConfig.cmake >include > Foo.h >src > Foo.cpp > FooTest.cpp > > is a more conventional structure > its actually for historical reasons. Initially, the structure was like Foo/ include Foo.h gcc Makefile src Foo.cpp FooTest.cpp vc70 Foo.vcproj vc80 Foo.vcproj So creation of a cmake folder for CMakeLists.txt might have resulted from habit. However, since then, many new components have been created and I would actually want to avoid to adapt the directory structure and CMakeLists of all projects. So is it mandatory to put the CMakeLists.txt in the project root directory or is it only considered "best practice". Nevertheless, the question remains, why CTest accepts "Foo/" as source directory but not its equivalent "Foo/cmake/..". Regards 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
[CMake] CTest: another sub-directory issue / coverage test
Hello,
I am still experimenting and learning how to setup CTest/CDash support
for our projects.
We have the following directory structure for our projects:
Foo/
cmake
CMakeLists.txt
CTestConfig.cmake
include
Foo.h
src
Foo.cpp
FooTest.cpp
Running CMake generates DartConfiguration.tcl in my build directory
with source directory set to Foo/cmake. This actually prevents running
the code coverage test successfully.
It only covers the header file Foo.h and not the source code (which is
compiled/linked with the required compiler switches). If I manually
modify the source directory in DartConfiguration.tcl
to Foo/ it works just fine and all code including Foo.cpp (FooTest is
linked against libFoo which is compiled from Foo.cpp) is checked for
coverage.
Is this intended behaviour?
My first attempt to solve this issue was to change (in
DartConfiguration.tcl.in)
SourceDirectory: @PROJECT_SOURCE_DIR@
to
SourceDirectory: @PROJECT_SOURCE_DIR@/..
which results in
SourceDirectory: /Foo/cmake/..
when running cmake. This is/should be equivalent to
SourceDirectory: /Foo
but somehow it is not. The code coverage test did not cover all files,
just the headers.
So, my current workaround is to modify DartConfiguration.tcl.in to
SourceDirectory: @PROJECT_ROOT@
which I manually set to "/Foo" with
GET_FILENAME_COMPONENT( PROJECT_ROOT ${PROJECT_SOURCE_DIR}/.. ABSOLUTE )
While writing the email, I just found
http://public.kitware.com/Bug/view.php?id=9678 (CTest fails to
summarize code coverage using gcov for files compiled outside
PROJECT_SOURCE_DIR subtree)
and I think this is actually related. But shouldnt't the first
approach using "/.." work neverthless? Excluding system files
definitely makes sense but if I explicitly set the source directory,
CTest should accept that.
Any comments?
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
Re: [CMake] Problem with CTest SUBDIRS
Tyler Roscoe schrieb: > On Mon, Nov 09, 2009 at 07:18:05PM +0100, Johannes Stallkamp wrote: > >> Are there any reasons the suggested patch in >> http://public.kitware.com/Bug/view.php?id=9090 is not integrated into >> current CMake version? >> > > Looks like Zach Mullen just applied the patch. Hopefully that means this > fix will be scheduled for CMake 2.8, which would be awesome since we are > also still affected by the issue! > Great news. Just in time! :-) ___ 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] Problem with CTest SUBDIRS
Hello, sorry for asking this right after the release of CMake 2.8, but I only stumpled upon the problem right now (using 2.6, however). Are there any plans to fix http://public.kitware.com/Bug/view.php?id=9090 (still marked as "open")? We actually do have the same situation that we add "subdirectories" with ADD_SUBDIRECTORY that are not sub-directories of the including CMakeLists.txt. The resulting CTestTestfile.cmake then correctly contains absolute paths but CTest prepends the current directory and, consequently, cannot find any tests. Are there any reasons the suggested patch in http://public.kitware.com/Bug/view.php?id=9090 is not integrated into current CMake version? Thanks for your help 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
[CMake] CPack + NSIS: Are empty components omitted?
Hello,
I have another problem with CPack and NSIS package generator:
I currently create a CMake component for each sub-project/component of
my software.
The sub-project CMakeLists.txt use cpack_add_component(...) to define
display name, description and especially dependencies.
Now, appA might depend on static library libB. Since libB is static, I
do not need to install a shared library (DLL in my case) in order to be
able to run appA.
_However_, static libB might in turn be dependent on other shared
libraries (e.g. libC and libD) (which are defined in their own components).
So, in fact, I would have
INSTALL( TARGETS appA RUNTIME DESTINATION bin COMPONENT appA )
cpack_add_component( appA DEPENDS libB )
INSTALL( FILES DESTINATION bin COMPONENT libB )
(^^^dummy command to generate CMake component with name "libB" )
cpack_add_component( libB DEPENDS libC libD )
However, NSIS stumbles over the component name libB:
warning: unknown variable/constant "{libB}" detected, ignoring
(macro:Select_appA_depends:41)
SectionGetFlags: ${libB}->$0
IntOp: $0=$0|1
warning: unknown variable/constant "{libB}" detected, ignoring
(macro:Select_appA_depends:43)
SectionSetFlags: ${libB}->$0
Usage: IntOp $(user_var: result) val1 OP [val2]
OP=(+ - * / % | & ^ ~ ! || && << >>)
Error in macro Select_appA_depends on macroline 44
Error in macro MaybeSelectionChanged on macroline 14
Error in macro SectionList on macroline 3
The directory libB is created in the NSIS sub-directory, but of course
it's empty. It seems that CPack omits that component when generating the
NSIS input file as for component libB there are no entries like:
Var appA_selected
Var appA_was_installed
Section "-DrawStack" DrawStack
[...]
SectionEnd
Any help is appreciated
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
[CMake] CPack + NSIS: Dependencies between components
Hello, I have a question concerning component-based install with CPack and NSIS: Among others, I have a library libA and a component depending on that library, appA. Using CPACK_COMPONENT_APPA_DEPENDS I can achieve that libA is installed if I select appA. But: If appA is the only component depending on libA, is it possible that it is automatically deselected with deselection of appA ? In other words, I want to make sure, that libA is only installed if appA is installed. As far as I can see, dependency checking only works so far that libA is selected if I choose to install appA and that appA is deselected if I uncheck libA. The only workaround I could come up with so far is to disable all components and let the user manually check the ones he wants. However, that is very inconvenient and does not work if the indecisive user subsequently unchecks that component again. Am I missing something? Any help is appreciated 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
[CMake] relative CMAKE_MODULE_PATH
Hello list,
is it possible to set a relative path as CMAKE_MODULE_PATH ? I
actually had problems with that (CMake 2.6.3-RC 8)
Is it because the relative path would be resolved w.r.t current build
dir and not w.r.t. to the directory with CMakeLists.txt ?
Reason:
I want to point CMAKE_MODULE_PATH to a directory in the source tree
which contains a file with a couple of cmake macros and some
customized modules.
These should be available in all projects. These projects may be
located at varying depth within the tree.
e.g. (simplified view)
ROOT
|-common components
|-libraryA
|-libraryB
|-CMakeMacros
|-applicationA
|-subcomponentA
|-plugins
|-pluginA
|-pluginB
|-pluginC
|-applicationB
Initially, I just used
INCLUDE( "../../CMakeMacros/localmacros.cmake")
( ../ varying according to project location, of course )
which is fine, as long as I only want to use that single file but
creates problems if I want to add custom/customized modules.
However,
SET( CMAKE_MODULE_PATH "../../CMakeModules")
INCLUDE( localmacros )
does not work. CMake complains that it cannot find that file.
My current workaround is
SET( CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/../../CMakeModules")
INCLUDE( localmacros )
Is that necessary or is there a more elegant way I'm not aware of?
Kind Regards
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
