[cmake-developers] [CMake 0012490]: Coverage counts 0 lines when path too long
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12490 == Reported By:funkycoder Assigned To: == Project:CMake Issue ID: 12490 Category: CTest Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-10-04 13:55 EDT Last Modified: 2011-10-04 13:55 EDT == Summary:Coverage counts 0 lines when path too long Description: If the path to the .gcov files to be generated becomes to long, there is no error message, the LOC counters are just 0. Steps to Reproduce: Dropping the attached files in a directory like '/home/pascal/ctest-cov' and running mkdir d cd d cmake .. make make ExperimentalTest make ExperimentalCoverage yields Covered LOC: 2 Not covered LOC: 0 Total LOC: 2 But when using 'abcdefghijklmnopqrstuvwxyz01234567890123456789' instead of 'd', it yields Covered LOC: 0 Not covered LOC: 0 Total LOC: 0 Additional Information: cmake version 2.8.5 ctest version 2.8.5 c++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 gcov (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 == Issue History Date ModifiedUsername FieldChange == 2011-10-04 13:55 funkycoder New Issue 2011-10-04 13:55 funkycoder File Added: CMakeLists.txt == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] CMake 2.8.6 available for download
On behalf of myself, Ken, Bill, Brad, Alex, Zach, Ben and the rest of the CMake team from all around the world, we are pleased to announce that CMake 2.8.6 is now available for download at: http://www.cmake.org/files/v2.8/?C=M;O=D It is also available from the usual download links found on the CMake web site: http://www.cmake.org/cmake/resources/software.html This email is also available on the Kitware blog at http://www.kitware.com/blog/home/post/176 This release we do not have pre-built binaries for the SunOS anymore. As mentioned on the CMake mailing list recently, our Sun hardware has bitten the proverbial dust. However, we are now providing two sets of installers for the Mac. The Darwin versions are for Mac OSX 10.4 and later, and are ppc;i386 universal binaries. The Darwin64 versions are for 10.6 and later, and are x86_64;i386 universal binaries. This release contains a last-minute addition that you should consider Experimental: a generator in the Windows build targeting Visual Studio 11. It will remain Experimental until VS11 itself is finalized. Please try it out if you have the developer preview of Visual Studio 11 installed. Let us know if you run into any VS11 specific issues. It is very new, and only tested enough to convince us it would be useful to include it for all of you to try out. If VS 11 crashes while you're using it, please send the crash reports in so that Microsoft has a chance to fix all those crashing bugs before VS11 becomes an official release. Thanks for using CMake! -Dave Changes in CMake 2.8.6 (since 2.8.6-rc4) Alex Neundorf (5): Remove trailing whitespace Minor improvements to the UsePkgConfig.cmake docs Remove trailing whitespace Improve behaviour of --find-package mode with try_run/try_compile Use makefile-IssueMessage() for better error messages Bill Hoffman (2): Use version 11.0 for 12.x and 9.10 for 10.x intel versions to fix 12.1 vsIDE. Also, check for 11.x as an intel fortran version. Brad King (2): Add Visual Studio 11 generator for x86 and x64 tools Teach our tests about special cases for VS 11 David Cole (1): CTestCustom.cmake: Ignore clang's summary warning Philip Lowman (1): FindBullet: Also search for _Debug postfixed library names Raphael Kubo da Costa (1): Fix typo in set_target_properties' documentation. Rolf Eike Beer (1): Fix typo in UsePkgConfig.cmake Changes in CMake 2.8.6-rc4 (since 2.8.6-rc3) Alex Neundorf (3): FindFLEX.cmake: also search the include dir Fix typos in FeatureSummary.cmake (#12462) Don't warn when setting a property multiple times to the same value #12464 Bill Hoffman (2): For VS Intel Fortran IDE builds, add a check to find the Fortran library PATH. Enable Fortran tests for IDE builds. Brad King (5): FortranCInterface: Compile separate Fortran lib in VerifyC[XX] Move IntelVSImplicitPath project to better location Simplify IntelVSImplicitPath detection project libarchive: Fix ssize_t detection with mingwrt 3.20 Make file(DOWNLOAD) fail on http error David Cole (8): Tests: Add a KWStyle test, equivalent to the make StyleCheck target KWStyle Test: Activate by default if KWStyle is found Xcode: Use EFFECTIVE_PLATFORM_NAME reference in ComputeOutputDir Xcode: Add test to demonstrate iOS project in Xcode CMake: Reference test targets only when BUILD_TESTING is ON Tests: Add the more modern Mac64 nightly build Release Scripts: Use Qt 4.7.4 on dashmacmini5 (#12460) Revert FindThreads: Try pthreads with no special option first (#11333) Eric NOULARD (4): CPack fix #12449 doc mispelled CPack fix template too CPackDeb fix #10325 automagically use fakeroot for DEB if fakeroot is found CPackRPM authorize per-component pre/post-[un]install scripts (#0012063) Marcus D. Hanwell (4): Just code style changes. Don't warn when nothing to do in visibility function. Made ADD_COMPILER_EXPORT_FLAGS into a macro. Make add_compiler_export_flags a function again. Rolf Eike Beer (1): remove stray brace in CPackDeb documentation Changes in CMake 2.8.6-rc3 (since 2.8.6-rc2) Alexey Ozeritsky (2): FindBLAS/LAPACK fixes FindBLAS/LAPACK fixes Andreas Schneider (1): Modules: Add support for more java archives in add_jar(). Björn Ricks (4): Search for the installed python interpreter first Determine python version Update documentation of FindPythonInterp.cmake Use FIND_PACKAGE_HANDLE_STANDARD_ARGS second mode Brad King (5): VS: Map per-source Fortran flags to IDE options VS: Map Fortran free- and fixed-format flags to IDE options Fortran: Add support for free- and fixed-form flags Xcode: Honor Fortran_FORMAT
Re: [cmake-developers] [PATCH 0/7] Preparation for Ninja generator: refactorings, bug fixes
On 03.10.2011 15:03, Brad King wrote: On 10/2/2011 1:41 PM, Peter Collingbourne wrote: I have modified the commit message to include more details, and pushed a modified branch to github. I've fetched the latest version of the branch. Thanks for the updates. -Brad Could you also enable Ninja files for CodeBlock's generators? Peter diff --git a/Source/cmExtraCodeBlocksGenerator.cxx b/Source/cmExtraCodeBlocksGenerator.cxx index 92dee5a..8c883d5 100644 --- a/Source/cmExtraCodeBlocksGenerator.cxx +++ b/Source/cmExtraCodeBlocksGenerator.cxx @@ -60,6 +60,7 @@ cmExtraCodeBlocksGenerator::cmExtraCodeBlocksGenerator() // this-SupportedGlobalGenerators.push_back(MSYS Makefiles); #endif this-SupportedGlobalGenerators.push_back(Unix Makefiles); + this-SupportedGlobalGenerators.push_back(Ninja); } -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 0/7] Preparation for Ninja generator: refactorings, bug fixes
On 04.10.2011 23:19, Peter Kümmel wrote: On 03.10.2011 15:03, Brad King wrote: On 10/2/2011 1:41 PM, Peter Collingbourne wrote: I have modified the commit message to include more details, and pushed a modified branch to github. I've fetched the latest version of the branch. Thanks for the updates. -Brad Could you also enable Ninja files for CodeBlock's generators? And maybe it is also trivial for 'Eclipse CDT4'. Peter -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 0/7] Preparation for Ninja generator: refactorings, bug fixes
On Tuesday 04 October 2011, Peter Kümmel wrote: On 03.10.2011 15:03, Brad King wrote: On 10/2/2011 1:41 PM, Peter Collingbourne wrote: I have modified the commit message to include more details, and pushed a modified branch to github. I've fetched the latest version of the branch. Thanks for the updates. -Brad Could you also enable Ninja files for CodeBlock's generators? And please also for Eclipse :-) (it's done the same way as for CodeBlocks) 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
Stephen Kelly wrote: Hi David, This is related to my patch to set the link_interface_libraries to empty and to: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030 Quoting: Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted. By default, all libraries a target is linked agaonst are in the LINK_INTERFACE, which leads to unnecessary dependencies and increased load time. The alternative would be not to set it to empty, and expect our developers to take care of it. I think this is not realistic. So I'm quite sure we still want that David Cole wrote: I'm going to say wait until Brad replies here, but I do not see a problem with that, *if* it's actually necessary. (Other than the obvious problem, which is that LINK_INTERFACE and LINK_INTERFACE_LIBRARIES are very close to each other and people will get them confused, and constantly be looking at the documentation to try to figure out which is which... A distinguishing naming difference, if you could come up with one, would be better. i.e., names where you can tell what the meaning is for each, without referring to the documentation...) set_target_libraries(foo bar baz LINK_DEPENDENCY_LIBRARIES bat mar ) So bat and mar do not become part of the link interface libraries? This is analogous to the IMPORTED_LINK_DEPENDENCY_LIBRARIES I think. The sideline discussion about linking seems to be finished, so I'm bumping the idea of being able to specify both the non-exposed dependencies and the exposed dependencies in one command without repetition. I see three options: 1) Change the meaning of LINK_INTERFACE_LIBRARIES in set_target_properties(foo LINK_INTERFACE_LIBRARIES bar) to not just communicate that users of foo should also link against bar, but make that command actually link foo against bar. I don't know if there is any use case for the existing behaviour. This could be done with a CMake policy. It would then be very trivial to make set_target_properties(foo baz LINK_INTERFACE_LIBRARIES bar) mean 'foo links against baz, but doesn't expose symbols from it; foo links against bar, and does export symbols from it'. 2) Introduce another variable for doing the same thing as above. As David notes, this might be confusing without looking up docs (though it wouldn't be the first part of CMake that needs docs to use). Also, if the existing behaviour of LINK_INTERFACE_LIBRARIES (do not actually link to the things listed there) doesn't have a use-case, or is rare, that one would fall out of use, and the new one would be more commonly used (it is good to optimise for the common case). 3) Introduce a variable for doing the opposite of what LINK_INTERFACE_LIBRARIES does. That is, the equivalent of the above would be set_target_properties(foo bat LINK_DEPENDENT_LIBRARIES baz) (note that bat and baz are swapped). This form communicates that baz should be linked against foo, but users of foo do not need to link against baz. My preference is (1). Does anyone know the reason for the current behaviour? Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
