From gvjung at gmail.com Tue Jul 1 03:41:22 2014 From: gvjung at gmail.com (Greg Jung) Date: Tue, 1 Jul 2014 00:41:22 -0700 Subject: [cmake-developers] FreeType headers almost there but not quite ... Message-ID: I've been debugging the plplot-5.10.0 build under MSYS and finally found, it can all go well only when the "include/freetype2" cflags are manually included in the build.make files (containing the gcc commands) for plfreetype.c and for wingcc.c. This build uses freetype 15.0.9, where include/ft2build.h points to . Despite its presence in pkgconfig/freetype2.pc cflags line, the actual compile command (in build.make) includes "-DUNSINGDLL -I" with nothing attached to the -I. The funny thing, though, is that treatment of the include/freetype2 flag is correct for pango, cairo, etc., all those more complicated packages come in with freetype2 as well where necessary. I bellieve plfreetype and wingcc are the only modules that access freetype directly, without using libraries also dependent on freetype.. I've tried adding include/freetype2 directory to C_includes.rsp files and to flags.make files, that has no effect the CMAKECACHE shows the following: FREETYPE_INCLUDEDIR:INTERNAL=D:/Mingw/msys/1.0/local/include FREETYPE_INCLUDE_DIRS:INTERNAL=D:/Mingw/msys/1.0/local/include/freetype2;D:/Mingw/msys/1.0/local/include FREETYPE_CFLAGS:INTERNAL=-ID:/Mingw/msys/1.0/local/include/freetype2;-ID:/Mingw/msys/1.0/local/include de _CAIRO_STATIC_CFLAGS:INTERNAL=-mms-bitfields;-ID:/Mingw/msys/1.0/local/include/freetype2;-ID:/Mingw/ msys/1.0/local/include;-ID:/Mingw/include/cairo;-ID:/Mingw/include/glib-2.0;-ID:/Mingw/lib/glib-2.0/ include;-ID:/Mingw/include/pixman-1;-ID:/Mingw/include;-ID:/Mingw/include/libpng15 _CAIRO_INCLUDE_DIRS:INTERNAL=D:/Mingw/msys/1.0/local/include/freetype2;D:/Mingw/msys/1.0/local/inclu de;D:/Mingw/include/cairo;D:/Mingw/include/glib-2.0;D:/Mingw/lib/glib-2.0/include;D:/Mingw/include/p ixman-1;D:/Mingw/include;D:/Mingw/include/libpng15 I have no clue about where to search to resolve this, as I am still on the bunny slopes of the CMAKE learning curve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Jul 1 07:47:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 1 Jul 2014 07:47:02 -0400 Subject: [cmake-developers] [CMake 0014999]: Changing Intermediate Directory of Visual Studio 2012 Message-ID: <9c79fccb05b96077485ddab5f84e7183@www.gccxml.org> The following issue has been SUBMITTED. ====================================================================== http://www.gccxml.org/Bug/view.php?id=14999 ====================================================================== Reported By: Ram Singh Assigned To: ====================================================================== Project: CMake Issue ID: 14999 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-07-01 07:47 EDT Last Modified: 2014-07-01 07:47 EDT ====================================================================== Summary: Changing Intermediate Directory of Visual Studio 2012 Description: We want to change the Intermediate Directory of CMake build so that our object files, executables and libraries can be build outside of CMake built files. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-01 07:47 Ram Singh New Issue ====================================================================== From mantis at public.kitware.com Tue Jul 1 14:33:56 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 1 Jul 2014 14:33:56 -0400 Subject: [cmake-developers] [CMake 0015000]: CMakeFindBinUtils always search for install_name_tool even when cross compiling on OSX Message-ID: <9d0eb7eb4ce66edd2e04a7fb3f582dad@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15000 ====================================================================== Reported By: Florent Castelli Assigned To: ====================================================================== Project: CMake Issue ID: 15000 Category: Modules Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-01 14:33 EDT Last Modified: 2014-07-01 14:33 EDT ====================================================================== Summary: CMakeFindBinUtils always search for install_name_tool even when cross compiling on OSX Description: When cross compiling (in my case for Android) from a Mac, CMakeFindBinUtils.cmake searches for a tool called "install_name_tool" required to make changes to Mach-O binaries (which is totally irrelevant to Android dev). This tool might not be installed (it comes with xcode or command line tools on OSX) and thus CMake will fail to generate a project (it issues a fatal error). This "error" is so pervasive that some android toolchain files actually ensure that install_name_tool is available just to pass this check. Fix would require to change the if(APPLE) on line 71 to if(CMAKE_PLATFORM_HAS_INSTALLNAME) which is set in other files when the tool is provided by the toolchain. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-01 14:33 Florent CastelliNew Issue ====================================================================== From florent.castelli at gmail.com Tue Jul 1 14:48:27 2014 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 1 Jul 2014 20:48:27 +0200 Subject: [cmake-developers] [PATCH] Only search for install_name_tool if the toolchain has it Message-ID: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> When cross compiling, toolchains won't have install_name_tool, which is provided by Xcode and command line tools on OSX. This is a Mach-O specific utility and not required on all platforms. --- Modules/CMakeFindBinUtils.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/CMakeFindBinUtils.cmake b/Modules/CMakeFindBinUtils.cmake index 829b6ff..5b5bda8 100644 --- a/Modules/CMakeFindBinUtils.cmake +++ b/Modules/CMakeFindBinUtils.cmake @@ -68,7 +68,7 @@ endif() # on Apple there really should be install_name_tool -if(APPLE) +if(CMAKE_PLATFORM_HAS_INSTALLNAME) find_program(CMAKE_INSTALL_NAME_TOOL NAMES install_name_tool HINTS ${_CMAKE_TOOLCHAIN_LOCATION}) if(NOT CMAKE_INSTALL_NAME_TOOL) -- 2.0.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Only-search-for-install_name_tool-if-the-toolchain-h.patch Type: application/octet-stream Size: 973 bytes Desc: not available URL: From sdougherty at barracuda.com Tue Jul 1 16:01:48 2014 From: sdougherty at barracuda.com (Steve Dougherty) Date: Tue, 1 Jul 2014 16:01:48 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <20140626150242.GA29055@megas.kitwarein.com> References: <20140626150242.GA29055@megas.kitwarein.com> Message-ID: <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> When I glance at ctest output, even if all tests passed, my eye catches "failed" before noticing the other things, which gives me a start. To make this less likely to happen this colors the test summary green if all tests succeeded and red if not. Although I have attempted to edit the test regular expressions so that they still pass, I'm missing something about matching escape codes, and a third of them fail. From LastTest.log: Start 1: RunCMake 1/1 MemCheck #1: RunCMake ......................... Passed 0.00 sec ESC[32;1m 100% tests passed, 0 tests failed out of 1 ESC[0m Total Test time (real) = 0.00 sec -- Processing memory checking output: Memory checking results: Test time = 0.11 sec ---------------------------------------------------------- Test Fail Reason: Required regular expression not found.Regex=[ 1/1 MemCheck #1: RunCMake \.+ Passed +[0-9]+\.[0-9]+ sec \\033\[32;1m 100% tests passed, 0 tests failed out of 1 .* -- Processing memory checking output:( ) Memory checking results: ((BullseyeCoverage|==)[^ ]* )*$ ] --- Source/CTest/cmCTestTestHandler.cxx | 13 +++++++++++++ Tests/CTestTestMemcheck/CMakeLists.txt | 4 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/Source/CTest/cmCTestTestHandler.cxx b/Source/CTest/cmCTestTestHandler.cxx index f21d166..b256be0 100644 --- a/Source/CTest/cmCTestTestHandler.cxx +++ b/Source/CTest/cmCTestTestHandler.cxx @@ -583,10 +583,23 @@ int cmCTestTestHandler::ProcessHandler() percent = 99; } + if ( failed.size() ) + { + // Bold red foreground + cmCTestLog(this->CTest, HANDLER_OUTPUT, "\033[31;1m"); + } + else + { + // Bold green foreground + cmCTestLog(this->CTest, HANDLER_OUTPUT, "\033[32;1m"); + } cmCTestLog(this->CTest, HANDLER_OUTPUT, std::endl << static_cast(percent + .5) << "% tests passed, " << failed.size() << " tests failed out of " << total << std::endl); + // Reset formatting to default + cmCTestLog(this->CTest, HANDLER_OUTPUT, "\033[0m"); + if(this->CTest->GetLabelSummary()) { this->PrintLabelSummary(); diff --git a/Tests/CTestTestMemcheck/CMakeLists.txt b/Tests/CTestTestMemcheck/CMakeLists.txt index 8984463..c35e1f7 100644 --- a/Tests/CTestTestMemcheck/CMakeLists.txt +++ b/Tests/CTestTestMemcheck/CMakeLists.txt @@ -54,7 +54,7 @@ set(other_tool_output "((${guard_malloc_output}BullseyeCoverage|==)[^\n]*\n)*") string(REPLACE "\r\n" "\n" ctest_and_tool_outputs " 1/1 MemCheck #1: RunCMake \\.+ Passed +[0-9]+\\.[0-9]+ sec -${guard_malloc_lines} +${guard_malloc_lines}\\\\033\\[32;1m 100% tests passed, 0 tests failed out of 1 .* -- Processing memory checking output:( ) @@ -177,7 +177,7 @@ set_tests_properties(CTestTestMemcheckDummyValgrindIgnoreMemcheck PASS_REGULAR_EXPRESSION "\n2/2 Test #2: RunCMakeAgain .*${ctest_and_tool_outputs}$") set_tests_properties(CTestTestMemcheckDummyBC PROPERTIES - PASS_REGULAR_EXPRESSION "\n1/1 MemCheck #1: RunCMake \\.+ Passed +[0-9]+.[0-9]+ sec\n\n100% tests passed, 0 tests failed out of 1\n(.*\n)?Error parsing XML in stream at line 1: no element found\n") + PASS_REGULAR_EXPRESSION "\n1/1 MemCheck #1: RunCMake \\.+ Passed +[0-9]+.[0-9]+ sec\n\\\\033\\[32;1m\n100% tests passed, 0 tests failed out of 1\n(.*\n)?Error parsing XML in stream at line 1: no element found\n") set_tests_properties(CTestTestMemcheckDummyValgrindInvalidSupFile PROPERTIES PASS_REGULAR_EXPRESSION "\nCannot find memory checker suppression file: ${CTEST_ESCAPED_REALPATH_CMAKE_CURRENT_BINARY_DIR}/does-not-exist\n") -- 2.0.1 =========================================================== DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. From irwin at beluga.phys.uvic.ca Tue Jul 1 16:35:23 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 1 Jul 2014 13:35:23 -0700 (PDT) Subject: [cmake-developers] FreeType headers almost there but not quite ... In-Reply-To: References: Message-ID: On 2014-07-01 00:41-0700 Greg Jung wrote: Hi Greg: Thanks for your interest in PLplot. I suspect this is either an issue concerning how you are using the PLplot build system or an issue with that system itself so I plan to follow up on this question on the appropriate list (plplot-devel) for discussing such issues. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From mantis at public.kitware.com Tue Jul 1 17:11:50 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 1 Jul 2014 17:11:50 -0400 Subject: [cmake-developers] [CMake 0015001]: add_custom_command: inconsistent treatment of escaped quotes Message-ID: <4b90f4570ebd0d21d541f2d2b35c5e6e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15001 ====================================================================== Reported By: George Sakhnovsky Assigned To: ====================================================================== Project: CMake Issue ID: 15001 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2014-07-01 17:11 EDT Last Modified: 2014-07-01 17:11 EDT ====================================================================== Summary: add_custom_command: inconsistent treatment of escaped quotes Description: I have an add_custom_command COMMAND line where I want to wrap several of the strings in double quotes. cmake src snippet: add_custom_command( TARGET ${target_name} PRE_BUILD COMMAND "\"$(DevEnvDir)tf\"" history "\"$(SolutionDir)\"" /stopafter:1 /recursive > changeset.dat The generated vcxproj file looks as follows. Note that the escaped double quotes made it through quite literally: \"$(DevEnvDir)tf\" history "$(SolutionDir)" /stopafter:1 /recursive > changeset.dat The desired behavior is to have $(DevEnvDir)tf wrapped in double quotes like so: "$(DevEnvDir)tf" history "$(SolutionDir)" /stopafter:1 /recursive > changeset.dat Why does escaping double quotes work for the second string in the line but not the first? Should this be accomplished differently for the first string because it's the actual command? If this is not a bug, what's the workaround? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-01 17:11 George SakhnovskyNew Issue ====================================================================== From ben.boeckel at kitware.com Wed Jul 2 08:13:00 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 2 Jul 2014 08:13:00 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> References: <20140626150242.GA29055@megas.kitwarein.com> <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> Message-ID: <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> On Tue, Jul 01, 2014 at 16:01:48 -0400, Steve Dougherty wrote: > When I glance at ctest output, even if all tests passed, my eye catches > "failed" before noticing the other things, which gives me a start. > > To make this less likely to happen this colors the test summary green > if all tests succeeded and red if not. > > Although I have attempted to edit the test regular expressions so that > they still pass, I'm missing something about matching escape codes, > and a third of them fail. From LastTest.log: Colors should only be output if we're outputting to a TTY. Pipes or redirections should not be colored (they'll only confuse those who don't recognize the escape sequences). CMake also has color routines already, but I don't know off-hand how accessible they are from CTest code (i.e., might be static functions). --Ben From brad.king at kitware.com Wed Jul 2 09:19:15 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Jul 2014 09:19:15 -0400 Subject: [cmake-developers] [PATCH] Only search for install_name_tool if the toolchain has it In-Reply-To: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> References: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> Message-ID: <53B406D3.9030400@kitware.com> On 07/01/2014 02:48 PM, Florent Castelli wrote: > When cross compiling, toolchains won't have install_name_tool, > which is provided by Xcode and command line tools on OSX. > This is a Mach-O specific utility and not required on all platforms. Applied, thanks: OS X: Only search for install_name_tool if the toolchain has it http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3012d20 -Brad From eike at sf-mail.de Wed Jul 2 09:23:15 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 02 Jul 2014 15:23:15 +0200 Subject: [cmake-developers] =?utf-8?q?=5BPATCH=5D_Only_search_for_install?= =?utf-8?q?=5Fname=5Ftool_if_the_toolchain_has_it?= In-Reply-To: <53B406D3.9030400@kitware.com> References: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> <53B406D3.9030400@kitware.com> Message-ID: Am 02.07.2014 15:19, schrieb Brad King: > On 07/01/2014 02:48 PM, Florent Castelli wrote: >> When cross compiling, toolchains won't have install_name_tool, >> which is provided by Xcode and command line tools on OSX. >> This is a Mach-O specific utility and not required on all platforms. > > Applied, thanks: > > OS X: Only search for install_name_tool if the toolchain has it > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3012d20 Probably also remove the comment in the line before? Eike From brad.king at kitware.com Wed Jul 2 09:24:42 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Jul 2014 09:24:42 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> References: <20140626150242.GA29055@megas.kitwarein.com> <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> Message-ID: <53B4081A.1080205@kitware.com> On 07/02/2014 08:13 AM, Ben Boeckel wrote: > Colors should only be output if we're outputting to a TTY. Pipes or > redirections should not be colored (they'll only confuse those who don't > recognize the escape sequences). CMake also has color routines already, > but I don't know off-hand how accessible they are from CTest code (i.e., > might be static functions). Look for uses of "cmsysTerminal_cfprintf" as an example. See its declaration in "Source/kwsys/Terminal.h.in" also. -Brad From brad.king at kitware.com Wed Jul 2 09:43:06 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Jul 2014 09:43:06 -0400 Subject: [cmake-developers] [PATCH] Only search for install_name_tool if the toolchain has it In-Reply-To: References: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> <53B406D3.9030400@kitware.com> Message-ID: <53B40C6A.4020703@kitware.com> On 07/02/2014 09:23 AM, Rolf Eike Beer wrote: > Am 02.07.2014 15:19, schrieb Brad King: >> OS X: Only search for install_name_tool if the toolchain has it >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3012d20 > > Probably also remove the comment in the line before? Yes, revised: OS X: Only search for install_name_tool if the toolchain has it http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=591a7388 Thanks, -Brad From mantis at public.kitware.com Wed Jul 2 12:38:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 2 Jul 2014 12:38:28 -0400 Subject: [cmake-developers] [CMake 0015002]: GetPrerequisites : fix objdump usage under non english locale Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15002 ====================================================================== Reported By: Olivier Trichet Assigned To: ====================================================================== Project: CMake Issue ID: 15002 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2014-07-02 12:38 EDT Last Modified: 2014-07-02 12:38 EDT ====================================================================== Summary: GetPrerequisites : fix objdump usage under non english locale Description: While cross-compile from linux to win32, objdump is used by GetPrerequisites to find dependency dll. It runs : objdump -p some.exe | grep 'DLL Name:' Under non English locale, the output of objdump can be translated. Thus the matching on 'DLL Name:' does not work. The attached patch fix this issue. Steps to Reproduce: 1) Create the CMakeLists.txt file with : include(GetPrerequisites) # Force the function 'get_prerequisites' to use objdump # (Avoid to setup a crosscompiling env unix -> win32) set(gp_tool "objdump") get_prerequisites("cmake-3.0.0-win32-x86.exe" DEPENDENCIES 0 1 "" "") message("Some dependencies should have been found: ${DEPENDENCIES}") 2) wget http://www.cmake.org/files/v3.0/cmake-3.0.0-win32-x86.exe 3) Choose a non english locale from "locale -a" to to setup the variable LC_ALL 4) "LC_ALL=fr cmake ." => dependency dll not found without patch "LC_ALL=C cmake ." => dependency found ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-02 12:38 Olivier TrichetNew Issue 2014-07-02 12:38 Olivier TrichetFile Added: 0001-GetPrerequisites-ensure-objdump-output-is-not-locale.patch ====================================================================== From mantis at public.kitware.com Wed Jul 2 16:29:57 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 2 Jul 2014 16:29:57 -0400 Subject: [cmake-developers] [CMake 0015003]: depend.make ignores files with the same name Message-ID: <8c89406b2ea7eff5864b099a4d0e3c59@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15003 ====================================================================== Reported By: Ryan Curtin Assigned To: ====================================================================== Project: CMake Issue ID: 15003 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-02 16:29 EDT Last Modified: 2014-07-02 16:29 EDT ====================================================================== Summary: depend.make ignores files with the same name Description: I've attached an interesting project that exposes a bug that is similar (but maybe not identical) to http://public.kitware.com/Bug/view.php?id=9354 . This occurred while working on mlpack ( http://www.mlpack.org/ ) which uses CMake, but I have reduced it to the simplest case I can think of. We have a test file, 'test.cpp', which includes two files 'a.hpp' and 'b.hpp'. The file 'a.hpp' includes 'a/a.hpp' which in turn includes 'impl.hpp' located in the directory a/. The file 'b.hpp' includes 'b/b.hpp' which in turn includes 'impl.hpp' located in the directory b/. Then, the CMake configuration just makes a target 'test' that depends on test.cpp, and ideally CMake should figure out all the header dependencies correctly. However, when CMake is used to configure and build the target, the resulting depend.make file associated with the test target only contains a/impl.hpp and not b/impl.hpp. This means I can make changes to b/impl.hpp and recompile, but CMake does not detect the changes. Unfortunately I am not enough of a CMake expert to provide a patch, but I thought it would at least be useful to reproduce the issue. Steps to Reproduce: 1. unpack attached .tar.gz 2. use CMake to configure it 3. build the test target 4. run ./test, look, the output is complaints 5. modify b/impl.hpp and add vulgarities 6. make test 7. run ./test... no vulgarities! Additional Information: I tried with both CMake 2.8 and 3.0, so it is tested against the latest stable release of CMake in both the 2.x and 3.x branches. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-02 16:29 Ryan Curtin New Issue 2014-07-02 16:29 Ryan Curtin File Added: cmake-test.tar.gz ====================================================================== From mantis at public.kitware.com Wed Jul 2 21:49:36 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 2 Jul 2014 21:49:36 -0400 Subject: [cmake-developers] [CMake 0015004]: string(REGEX REPLACE) doesn't correctly anchor regex with ^ for multiple matches Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15004 ====================================================================== Reported By: Chris Foster Assigned To: ====================================================================== Project: CMake Issue ID: 15004 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-02 21:49 EDT Last Modified: 2014-07-02 21:49 EDT ====================================================================== Summary: string(REGEX REPLACE) doesn't correctly anchor regex with ^ for multiple matches Description: string(REGEX REPLACE) doesn't seem to anchor multiple matches correctly with the ^ symbol - subsequent matches seem to be anchored at the start of the next substring. Steps to Reproduce: Run the following cmake script: ----------- string(REGEX REPLACE "^([^-]*-)" "@\\1#" output "foo-1.2-3") message(STATUS "\"${output}\"") ----------- Output is -- "@foo-#@1.2-http://www.cmake.org/Bug/view.php?id=3" so the pattern has matched twice, whereas it should only match the input string once at the start - the expected output is -- "@foo-http://www.cmake.org/Bug/view.php?id=1.2-3" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-02 21:49 Chris Foster New Issue ====================================================================== From gvjung at gmail.com Thu Jul 3 01:10:43 2014 From: gvjung at gmail.com (Greg Jung) Date: Wed, 2 Jul 2014 22:10:43 -0700 Subject: [cmake-developers] FreeType headers almost there but not quite ... resolved Message-ID: Hi again, I'm re-transmitting this to include the mailing list, trim some and add my final analysis. I went back and was able to run cmake without my modifications, and the build proceeded fine ... oh but with_freetype was set to off, so that doesn't count. The same problem that bothered me when I first dove into the CMAKE system is still pestering me: Freetype library. The module in the plplot distribution works fine for only linux/unix hosts: FIND_PATH(FREETYPE_INCLUDE_DIR freetype/config/ftheader.h /usr/local/include/freetype2 /usr/include/freetype2 ) In MSYS case, /usr/local means nothing to CMAKE. The cmake distribution has a (more inclusive, shotgun) approach and I originally modified some (cmake-2.8).cmake modules to a) find the /MSYS and /mingw anchors and set appropriate values for CMAKE_SYSTEM_PREFIX_PATH, CMAKE _SYSTEM_LIBRARY_PATH, etc. in the MSYS case, b) parse environment variable PKG_CONFIG_PATH and use pkg-config facilities in cmake to hook libraries in. Of course that [b)] is what (plplot)/pkg-config.cmake does so I use that, and lib/pkgconfig/freetype.pc blends well into that system. Today I did some searching of the plplot-developer mailing list archives and found that a working downstream change has been in the plplot trunk since march 2014, that instead of FREETYPE_INCLUDE_DIR to use FREETYPE_INCLUDE_CFLAGS for build commands. So all versiopns 13025+ are good with that. The revised (plplot).freetype.cmake actually constructs INCLUDE_CFLAGS from the INCLUDE_DIRS returned by (cmake-2.8).FindFreeType.cmake. This module (FindFreetype) however is of no use to my configuration because it requires a windows GTKM installation to find a freeetype collection. Instead I am MSYS and stubbornly so, windows is only my backdrop. Hence my (cmake) module revisions discussed above are needed to make it all fly. And it does. I attached my cmake modules I use and additionally, pkg-config.cmake modules slightly modified from the plplot code. freetype.cmake is re-cast so that a prior pick-up of freetype can be used, i.e. freetype2.pc, as i do in the custom code. FindFreetype is called if the option is on but it still hasn't been found. Both cases converge to create _INCLUDE_CFLAGS from INCLUDE_DIRS where the (revised as of 13025) plplot build scripting. I re-tested, and include the cmake-gui chatter (cmake.out) from my revised config. In my enhanced cmake I can find freetype under MSYS, but with the modified procedure (call boiler_plate before including freetype) you can use vanilla cmake. ... The attached files include a cmake.out (cmake-gui configuration chatter) with plplot-5.10.0 using replacement .cmakes as found in the tarball, including the "plplot-specific" directory for the plplot/cmake/modules. I now test my vanilla cmake and attach it as "cmakeold.out". Last-second revision: src/CMakeLists.txt line 244 needs to use FREETYPE_INCLUDE_CFLAGS also. On Tue, Jul 1, 2014 at 1:35 PM, Alan W. Irwin wrote: > On 2014-07-01 00:41-0700 Greg Jung wrote: > > Hi Greg: > > Thanks for your interest in PLplot. > > I suspect this is either an issue concerning how you are using the > PLplot build system or an issue with that system itself so I plan to > follow up on this question on the appropriate list (plplot-devel) for > discussing such issues. > > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake.out Type: application/octet-stream Size: 5269 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newcmakemodules.tar.gz Type: application/x-gzip Size: 41053 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmakeold.out Type: application/octet-stream Size: 9273 bytes Desc: not available URL: From mantis at public.kitware.com Thu Jul 3 05:17:54 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 3 Jul 2014 05:17:54 -0400 Subject: [cmake-developers] [CMake 0015005]: Take in account CPACK_INSTALL_SCRIPT when running `cpack` Message-ID: <56e57b2f1083dfa7760fc7508be9b737@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15005 ====================================================================== Reported By: Alex Turbov Assigned To: ====================================================================== Project: CMake Issue ID: 15005 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-03 05:17 EDT Last Modified: 2014-07-03 05:17 EDT ====================================================================== Summary: Take in account CPACK_INSTALL_SCRIPT when running `cpack` Description: According lines 226-258 of the Source/CPack/cmCPackGenerator.cxx file, there are few ways to preinstall files to be packed: 1) via CPACK_INSTALL_COMMANDS variable [InstallProjectViaInstallCommands() function] 2) CPACK_INSTALL_SCRIPT [InstallProjectViaInstallScript()] 3) CPACK_INSTALLED_DIRECTORIES [InstallProjectViaInstalledDirectories()] 4) and finally CPACK_INSTALL_CMAKE_PROJECTS [InstallProjectViaInstallCMakeProjects()] but Source/CPack/cpack.cxx at line 470 checks only 1,3,4 options! so if my configuration file has only CPACK_INSTALL_SCRIPT variable defined, it doesn't want to run w/ the error: .../Source/CPack/cpack.cxx:479 Please specify build tree of the project that uses CMake using CPACK_INSTALL_CMAKE_PROJECTS, specify CPACK_INSTALL_COMMANDS, or specify CPACK_INSTALLED_DIRECTORIES. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-03 05:17 Alex Turbov New Issue ====================================================================== From ericmberge at gmail.com Thu Jul 3 17:19:32 2014 From: ericmberge at gmail.com (Eric Berge) Date: Thu, 3 Jul 2014 16:19:32 -0500 Subject: [cmake-developers] Dependency Checking Issue with Native HPUX 11iv3 make Message-ID: Please consider this as FYI if you're interested in running cmake on HPUX 11iv3: The nightly HPUX 11iv3 test run get an error in the BuildDepends test ( http://open.cdash.org/index.php?project=CMake). This fails virtually all the time, however, for some reason, a successful run does occasionally happen. This appears to be an issue with the native "make" command on HPUX at least according to the unit tests I've done. On the surface this appears to be an error in the LINK_DEPENDS_NO_SHARED property but that is not the case, the problem is more fundamental. In fact, just about the simplest test case for dependency checking (building a program with a single file) needs to be built twice to recognize that it is up-to-date. My test case ultimately was simply: ------------------------------------------------------------------- cmake_minimum_required(VERSION 2.8.12.2) project(MyBuildDepends) add_executable(prog prog.c) -------------------------------------------------------------------- With this, I run the native "make" command twice and, each time it will re-link "prog": -------------------------------------------------------------------- # cmake .. -- The C compiler identification is HP 6.25.0 -- The CXX compiler identification is HP 6.25.0 -- Check for working C compiler: /bin/cc -- Check for working C compiler: /bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /bin/c++ -- Check for working CXX compiler: /bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/eberge/projects/cmake/BuildDepends-failure/testcase2/build # make Scanning dependencies of target prog [100%] Building C object CMakeFiles/prog.dir/prog.c.o Linking C executable prog [100%] Built target prog # make Linking C executable prog [100%] Built target prog # make [100%] Built target prog # -------------------------------------------------------------------- Actually the odd thing is that it appears to have a "domino effect" where the first "make" builds the .o and links the executable, the 2nd only links the executable, and the last will finally do nothing. Since I had gmake on the system I gave that a try, and gmake works just fine. I'm not really looking for a solution for this, but just in case others run into problems on HPUX 11iv3 I thought it was worth saving you the hours it look me to run this down. For now I plan on setting CMAKE_MAKE_PROGRAM to gmake to allow the nightly 11iv3 tests to run successfully (but we'll see how well that expectation pans out tonight...). I did look around for a potential bugfix for make in HPUX but I didn't find anything but that might be because I don't know how to navigate the HPUX labyrith :-) Eric Berge -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Jul 4 02:42:54 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 4 Jul 2014 02:42:54 -0400 Subject: [cmake-developers] [CMake 0015006]: AUTORCC doesn't work with OBJECT library Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15006 ====================================================================== Reported By: sudakov_ivan Assigned To: ====================================================================== Project: CMake Issue ID: 15006 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-04 02:42 EDT Last Modified: 2014-07-04 02:42 EDT ====================================================================== Summary: AUTORCC doesn't work with OBJECT library Description: I wrote code: "add_library(foo OBJECT foo.cpp foo.rcc)". It doesn't compile by cmake. Can I use AUTORCC with OBJECT library? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-04 02:42 sudakov_ivan New Issue ====================================================================== From raffi.enficiaud at free.fr Fri Jul 4 20:02:01 2014 From: raffi.enficiaud at free.fr (Raffi Enficiaud) Date: Sat, 5 Jul 2014 02:02:01 +0200 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <5347EFBF.7030403@kitware.com> References: <90AF0BC5-0EEE-4B39-9779-6CCA83A63E45@free.fr> <531763EF.60406@kitware.com> <05218E8A-75CB-48E6-84FE-54011F6B8DF9@free.fr> <5318A7DB.8050608@kitware.com> <32646FBF-9528-421E-885C-124ECD50700F@free.fr> <5347EFBF.7030403@kitware.com> Message-ID: Hi, Sorry for the delayed answer. On 11 Apr 2014, at 15:35, Brad King wrote: >> I avoided using the new syntax of cmake 3.x because I am still using 2.8.12 >> and I also would like ppl to get this new package and run it on older versions. > > If it is going to be added upstream it needs to have the appropriate > documentation syntax. You can still use comment blocks starting in > '#' on every line as most modules currently do and it will work with > 2.8.12. Sorry for the misunderstanding. It does use SPHINX syntax. I was mentioning the fact that I cannot use block comments like #[========================================[.rst: .. command:: xxx_do_something #]========================================] because it is not compatible with cmake 2.8. All doc lines are prefixed with # instead. > >> The current solution I am seeing now is to do a test on a cmake >> script that does the job of launching the command and flushing >> the log file onto the console. > > Many of our tests use "cmake -P" to run a cmake script that performs > the test inside. You can use -Dvar=${val} before the -P option to > pass options to the script, such as $. Done: this is the add_matlab_unit_test function. In fact, I think I can remove the log files since they are redundant with the tests logs. What do you think? > >> - Is it ok if we create log files of leave them onto the disk? > > Yes, but they should be inside the CMake build tree so there are > no side effects left when the tree is removed. Cool. This is what it does. > >> two modes for querying the registry: x86 and x64 modes. >> This is not very clear to me what I should do on that: > > The find_library command expands registry values with the view > that matches the target architecture. The find_program command > looks at the matching architecture first and then the other one: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v3.0.0-rc3#l347 > > This is how most of the modules deal with the difference. I'm > not familiar enough with matlab to say what should be done here. Well, this is not exactly what I am doing in fact with this module. I query the registry for all entries below a specific registry key, instead of brute-force checking all the possible keys. Now I am using CMAKE_CL_64 for switching the query on the x86 or x64 mode. > Thanks, > -Brad > I added a function add_matlab_mex that is like a add_library for creating MEX (compiled) extensions. There is an option to this function called REDUCE_VISIBILITY which deals with symbols collision between the library shipped with Matlab and the one the MEX file links to (Unix only). Basically, with this option on, all symbols of the MEX file are hidden, which is more or less what is happening on Windows. I attach to this email the updated files. -------------- next part -------------- A non-text attachment was scrubbed... Name: FindMatlab_TestsRedirect.cmake Type: application/octet-stream Size: 1743 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindMatlab.cmake Type: application/octet-stream Size: 37262 bytes Desc: not available URL: -------------- next part -------------- So far I am not sure how my implementation is compatible with the previous FindMatlab package. The requirements are to define the same variables, right? Is there anything else? BTW, is there any variable that tells the current cmake list, even in function in packages? The add_matlab_unittest is a function calling FindMatlab_TestsRedirect.cmake in script mode. When I use CMAKE_CURRENT_LIST_DIR, it takes the value of the cmake file calling the function. I would like to reference the call to FindMatlab_TestsRedirect.cmake relatively to FindMatlab.cmake. Best, Raffi From mantis at public.kitware.com Sat Jul 5 05:00:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 5 Jul 2014 05:00:02 -0400 Subject: [cmake-developers] [CMake 0015007]: [patch] Imagemagick detection stlli broken with multi-arch imagemagick Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15007 ====================================================================== Reported By: broucari Assigned To: ====================================================================== Project: CMake Issue ID: 15007 Category: Modules Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-07-05 05:00 EDT Last Modified: 2014-07-05 05:00 EDT ====================================================================== Summary: [patch] Imagemagick detection stlli broken with multi-arch imagemagick Description: Imagemagick detection is still broken with cmake. Indeed some headers are installed under arch dependant dir and it need to specify CFLAGS in order to get quantum selection. May be related to http://www.cmake.org/Bug/view.php?id=14012 Reported downstream as: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747907 I have made an untested patch using pkg-config. Please fix it, it lead to multiple FTBFS. Thanks Steps to Reproduce: Download recent imagemagick from debian experimental, and try to compile libtuxcap See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747908 Additional Information: Block newer imagemagick in experimental. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-05 05:00 broucari New Issue 2014-07-05 05:00 broucari File Added: Fix-imagemagick-multiarch ====================================================================== From joubert.sy at gmail.com Sat Jul 5 09:30:07 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Sat, 05 Jul 2014 15:30:07 +0200 Subject: [cmake-developers] [patch] Support for swig 3.0 Message-ID: <53B7FDDF.5090801@gmail.com> Hi all, Please consider this patch that makes swig 3.0 supported by the FindSWIG module. Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-swig-3.0-application.patch Type: text/x-patch Size: 1149 bytes Desc: not available URL: From mantis at public.kitware.com Sat Jul 5 23:09:44 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 6 Jul 2014 04:09:44 +0100 Subject: [cmake-developers] [CMake 0015008]: Fix CMakeExpandImportedTargets to avoid Error on non-existent target in get_target_property. Message-ID: <6d0c3dbbe756fbbb99c5d7b7f1bb4660@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15008 ====================================================================== Reported By: Jean-Christophe Fillion-Robin Assigned To: ====================================================================== Project: CMake Issue ID: 15008 Category: CMake Reproducibility: always Severity: tweak Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-06 04:09 WAT Last Modified: 2014-07-06 04:09 WAT ====================================================================== Summary: Fix CMakeExpandImportedTargets to avoid Error on non-existent target in get_target_property. Description: CMake Warning (dev) at cmake/CMakeExpandImportedTargets.cmake:66 (get_target_property): Policy CMP0045 is not set: Error on non-existent target in get_target_property. Run "cmake --help-policy CMP0045" for policy details. Use the cmake_policy command to set the policy and suppress this warning. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-06 04:09 Jean-Christophe Fillion-RobinNew Issue ====================================================================== From schueller at phimeca.com Sun Jul 6 15:34:21 2014 From: schueller at phimeca.com (Julien Schueller) Date: Sun, 6 Jul 2014 21:34:21 +0200 (CEST) Subject: [cmake-developers] [patch] Support for swig 3.0 In-Reply-To: <53B7FDDF.5090801@gmail.com> References: <53B7FDDF.5090801@gmail.com> Message-ID: <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> This is curious, SWIG does not provide an executable named "swig3.0". Where did you get swig from ? ----- Mail original ----- > De: "Sylvain Joubert" > ?: cmake-developers at cmake.org > Envoy?: Samedi 5 Juillet 2014 15:30:07 > Objet: [cmake-developers] [patch] Support for swig 3.0 > > Hi all, > > Please consider this patch that makes swig 3.0 supported by the FindSWIG > module. > > Sylvain > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Julien Schueller Phimeca Engineering www.phimeca.com From joubert.sy at gmail.com Sun Jul 6 16:43:45 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Sun, 06 Jul 2014 22:43:45 +0200 Subject: [cmake-developers] [patch] Support for swig 3.0 In-Reply-To: <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> References: <53B7FDDF.5090801@gmail.com> <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> Message-ID: <53B9B501.50505@gmail.com> Le 06/07/2014 21:34, Julien Schueller a ?crit : > This is curious, SWIG does not provide an executable named "swig3.0". > Where did you get swig from ? > I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0' package. This package provides the '/usr/bin/swig3.0' executable. From schueller at phimeca.com Mon Jul 7 06:17:59 2014 From: schueller at phimeca.com (Julien Schueller) Date: Mon, 7 Jul 2014 12:17:59 +0200 (CEST) Subject: [cmake-developers] [patch] Support for swig 3.0 In-Reply-To: <53B9B501.50505@gmail.com> References: <53B7FDDF.5090801@gmail.com> <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> <53B9B501.50505@gmail.com> Message-ID: <2058949983.3795548.1404728279560.JavaMail.zimbra@phimeca.com> What's the point on renaming it ? installing multiple versions ? what's the point ? I'd say SWIG is rather a very stable utility. You can safely symlink to /usr/bin/swig. ----- Mail original ----- > De: "Sylvain Joubert" > ?: cmake-developers at cmake.org > Envoy?: Dimanche 6 Juillet 2014 22:43:45 > Objet: Re: [cmake-developers] [patch] Support for swig 3.0 > > Le 06/07/2014 21:34, Julien Schueller a ?crit : > > This is curious, SWIG does not provide an executable named "swig3.0". > > Where did you get swig from ? > > > > I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0' > package. This package provides the '/usr/bin/swig3.0' executable. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Julien Schueller Phimeca Engineering www.phimeca.com From brad.king at kitware.com Mon Jul 7 09:22:21 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 07 Jul 2014 09:22:21 -0400 Subject: [cmake-developers] [patch] Support for swig 3.0 In-Reply-To: <2058949983.3795548.1404728279560.JavaMail.zimbra@phimeca.com> References: <53B7FDDF.5090801@gmail.com> <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> <53B9B501.50505@gmail.com> <2058949983.3795548.1404728279560.JavaMail.zimbra@phimeca.com> Message-ID: <53BA9F0D.9020004@kitware.com> On 07/07/2014 06:17 AM, Julien Schueller wrote: > What's the point on renaming it ? installing multiple versions ? what's the point ? > > ----- Mail original ----- >> I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0' >> package. This package provides the '/usr/bin/swig3.0' executable. This is a very common convention in distro packaging and is supported by many of our find modules. FindSWIG already looks for "swig2.0" so it makes sense to also look for "swig3.0". I've applied the patch: FindSWIG: Add support for swig 3.0 application http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7400695e Thanks, -Brad From brad.king at kitware.com Mon Jul 7 10:51:38 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 07 Jul 2014 10:51:38 -0400 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: References: <90AF0BC5-0EEE-4B39-9779-6CCA83A63E45@free.fr> <531763EF.60406@kitware.com> <05218E8A-75CB-48E6-84FE-54011F6B8DF9@free.fr> <5318A7DB.8050608@kitware.com> <32646FBF-9528-421E-885C-124ECD50700F@free.fr> <5347EFBF.7030403@kitware.com> Message-ID: <53BAB3FA.5080206@kitware.com> Hi Raffi, Thanks for your continuing work on this module. I've made some whitespace and quoting tweaks to the files. See attached updated versions. I also renamed the test helper to not start in "Find" since no one should call find_package(Matlab_TestsRedirect). See further comments below. On 07/04/2014 08:02 PM, Raffi Enficiaud wrote: >> Many of our tests use "cmake -P" to run a cmake script that performs >> the test inside. You can use -Dvar=${val} before the -P option to >> pass options to the script, such as $. > > Done: this is the add_matlab_unit_test function. In fact, I think I can > remove the log files since they are redundant with the tests logs. I see no problem with that, but I'm not familiar with the tools. > I added a function add_matlab_mex that is like a add_library Please make all APIs start in "matlab_". The documentation blocks for each command also need to start in "#.rst:" #.rst: # .. command:: add_matlab_mex or they will not be included in the processed documentation. > for creating MEX (compiled) extensions. There is an option to this > function called REDUCE_VISIBILITY I see that implemented here: > if(HAS_VISIBILITY_INLINE_HIDDEN) > target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility-inlines-hidden") > endif() > if(HAS_VISIBILITY_HIDDEN) > target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility=hidden") > endif() An upstream version of the module should use the builtin features for visibility settings: http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.html http://www.cmake.org/cmake/help/v3.0/prop_tgt/VISIBILITY_INLINES_HIDDEN.html > # set(MATLAB_ADDITIONAL_VERSIONS > # "release_name1" "corresponding_version1" > # "release_name2" "corresponding_version2" > # ... > # ) Rather than relying on matched pairs, perhaps use "=" to separate: # set(MATLAB_ADDITIONAL_VERSIONS # "release_name1=corresponding_version1" # "release_name2=corresponding_version2" ? > I am not sure how my implementation is compatible with the previous > FindMatlab package. The requirements are to define the same variables, > right? Is there anything else? It needs to produce the same result variables and also respond to the old "input" variables (like find_ command cached results) that the old module did. That way existing build scripts can continue to work. > +# * ``MATLAB_USER_ROOT`` the root of the Matlab installation. This is given by the user. This should be documented in its own section of variables that the user can set to control the search. See FindZLIB for example. > + # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to reg does not work > + # from cmake, curiously, as is. The command provides the desired result under the command line though. > + # Fix: this is because "/reg:64" should appended to the command, otherwise it gets on the 32 bits software key (curiously again) This is because it gets the registry view of the calling CMake unless you tell it what view to use. > + find_program(MATLAB_REG_EXE_LOCATION "reg") > + file(TO_NATIVE_PATH ${MATLAB_REG_EXE_LOCATION} MATLAB_REG_EXE_LOCATION) The second line should not be needed. The execute_process command will take care of the path format. > + if((NOT DEFINED MATLAB_USER_ROOT) OR (NOT MATLAB_USER_ROOT)) This can be shortened to if(NOT MATLAB_USER_ROOT) > + if(NOT ${Matlab_PROGRAM}) and this to if(NOT Matlab_PROGRAM) > BTW, is there any variable that tells the current cmake list, > even in function in packages? In the attached version I added set(_FindMatlab_SELF_DIR "${CMAKE_CURRENT_LIST_DIR}") to the top of the file to save the location of the file for re-use inside function calls later. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: MatlabTestsRedirect.cmake Type: text/x-cmake Size: 1739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindMatlab.cmake Type: text/x-cmake Size: 36956 bytes Desc: not available URL: From tim.jenks at eegeo.com Tue Jul 8 08:46:01 2014 From: tim.jenks at eegeo.com (Tim Jenks) Date: Tue, 8 Jul 2014 12:46:01 +0000 (UTC) Subject: [cmake-developers] Who does CMake contract work? References: <531889FF.7040504@kitware.com> Message-ID: > > Kitware has been offering CMake consulting since we created CMake. > Information can be found here: > > http://cmake.org/cmake/help/support.html > > Vince, I also sent you an email off list. This looks like a great > addition to CMake, and we would love to help. > > Thanks. > > -Bill > * snip * > > Modify open source CMake to be able to generate NSight Tegra project files. > > Vince I would also be interested in any information regarding nsight tegra solution generation using cmake. Did anything come of this thread? From mantis at public.kitware.com Wed Jul 9 07:14:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 9 Jul 2014 07:14:51 -0400 Subject: [cmake-developers] [CMake 0015011]: problem to find non-standard ncurses.h location Message-ID: <82a5d3937e85f6eecde21d8e63cc1cee@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15011 ====================================================================== Reported By: hsk Assigned To: ====================================================================== Project: CMake Issue ID: 15011 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-09 07:14 EDT Last Modified: 2014-07-09 07:14 EDT ====================================================================== Summary: problem to find non-standard ncurses.h location Description: i have installed gnu ncurses (and several other libraries) under separate location; os: solaris10, compiler: sunstudio 12.2 building cmake 2.8.x worked using env \ CC=cc \ CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \ CXX=CC \ CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \ LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' \ CPPFLAGS=-I/var/imb/include \ ./bootstrap --prefix=/var/imb; gmake with cmake 3.0, the "gmake" step fails: cmake-3.0.0/Source/CursesDialog/form/form.h", line 46: cannot find include file: and -I/var/imb/include must be explicitly added to CFLAGS / CXXFLAGS for ncurses.h to be found, i.e., i have to use env \ CC=cc \ CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \ CXX=CC \ CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \ LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' \ CPPFLAGS=-I/var/imb/include \ ./bootstrap --prefix=/var/imb; gmake imho, the value of CPPFLAGS should be honoured here ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-09 07:14 hsk New Issue ====================================================================== From tim at klingt.org Wed Jul 9 09:40:54 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 09 Jul 2014 15:40:54 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory Message-ID: cfbundles are currently not installed as directory, but the binary from Contents/MacOS is directly installed to the destination. attached patch fixes the issue. thanks, tim -------------- next part -------------- >From b021da36ec9c72cc6410a95ce81a177a87f6f232 Mon Sep 17 00:00:00 2001 From: Tim Blechmann Date: Wed, 9 Jul 2014 15:33:25 +0200 Subject: [PATCH] InstallTarget: install CFBundles with complete directory --- Source/cmInstallTargetGenerator.cxx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx index 7a39f45..93c0d63 100644 --- a/Source/cmInstallTargetGenerator.cxx +++ b/Source/cmInstallTargetGenerator.cxx @@ -213,6 +213,20 @@ void cmInstallTargetGenerator::GenerateScriptForConfig(std::ostream& os, filesFrom.push_back(from1); filesTo.push_back(to1); } + else if(this->Target->IsCFBundleOnApple()) + { + // Install the whole app bundle directory. + type = cmInstallType_DIRECTORY; + literal_args += " USE_SOURCE_PERMISSIONS"; + + std::string targetNameBase = targetName.substr(0, targetName.find_first_of("/")); + + std::string from1 = fromDirConfig + targetNameBase; + std::string to1 = toDir + targetNameBase; + + filesFrom.push_back(from1); + filesTo.push_back(to1); + } else { bool haveNamelink = false; -- 2.0.1 From brad.king at kitware.com Wed Jul 9 10:02:48 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 10:02:48 -0400 Subject: [cmake-developers] NVidia Nsight Tegra (was: Who does CMake contract work?) In-Reply-To: References: <531889FF.7040504@kitware.com> Message-ID: <53BD4B88.5060508@kitware.com> On 07/08/2014 08:46 AM, Tim Jenks wrote: > I would also be interested in any information regarding nsight tegra > solution generation using cmake. > > Did anything come of this thread? We ended up working with NVIDIA directly and have produced a draft of support for Nsight Tegra with Visual Studio. It is still a work in progress but I've attached the current draft patch series (they apply on master as of 487b6ccd, and perhaps more recent versions too). Limitations of the current draft are documented in patch 0004. With these patches and NVIDIA Nsight Tegra Visual Studio Edition installed, new generator variants are available: Visual Studio 12 2013 Tegra-Android Visual Studio 11 2012 Tegra-Android Visual Studio 10 2010 Tegra-Android A non-default Android NDK toolchain may be selected at the command-line, e.g. cmake -G "Visual Studio 12 2013 Tegra-Android" -T clang-3.4 ... or using a CMAKE_TOOLCHAIN_FILE that sets CMAKE_GENERATOR_TOOLSET. Feedback is welcome. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-VS-Make-MS-tool-specific-options-conditional.patch Type: text/x-diff Size: 10999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-VS-Add-Tegra-Android-platform-variant-of-VS-10-gener.patch Type: text/x-diff Size: 8947 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-VS-Detect-compiler-id-of-Nsight-Tegra-Android-toolch.patch Type: text/x-diff Size: 5832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-VS-Teach-vcxproj-generation-about-the-Tegra-Android-.patch Type: text/x-diff Size: 6096 bytes Desc: not available URL: From brad.king at kitware.com Wed Jul 9 11:09:01 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 11:09:01 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: Message-ID: <53BD5B0D.4000708@kitware.com> On 07/09/2014 09:40 AM, Tim Blechmann wrote: > cfbundles are currently not installed as directory, but the binary from > Contents/MacOS is directly installed to the destination. > > attached patch fixes the issue. Thanks. I do not understand this line: > + std::string targetNameBase = targetName.substr(0, targetName.find_first_of("/")); Why do we need to look for the first slash? Also, look earlier in that function for the blocks starting in: // Handle OSX Bundles. if(this->Target->IsAppBundleOnApple()) and else if(this->Target->IsFrameworkOnApple()) Those cases do special handling for the post-installation tweaks. Is something similar needed here? -Brad From brad.king at kitware.com Wed Jul 9 11:12:14 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 11:12:14 -0400 Subject: [cmake-developers] cost of usage requirements In-Reply-To: <53986BDC.7090707@kitware.com> References: <20140608225611.GC18896@megas.kitwarein.com> <8D151EF9D6FCEA2-26D4-1169@webmail-d299.sysops.aol.com> <20140610171757.GA3906@megas.kitwarein.com> <53986BDC.7090707@kitware.com> Message-ID: <53BD5BCE.2020204@kitware.com> On 06/11/2014 10:46 AM, Brad King wrote: > Here is a sscce:: > > cmake_minimum_required(VERSION 2.8.9) > project(ManyLibs C) > set(LibPrev) > foreach(n RANGE 100) > add_library(Lib${n} SHARED lib.c) > target_link_libraries(Lib${n} LINK_PUBLIC ${LibPrev}) > set(LibPrev Lib${n}) > endforeach() A similar case also appears when building VTKWikiExamples as discussed on the cmake user list here: cmake 3.0 memory usage on VTKWikiExamples http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/49910/focus=49922 Memory usage explodes during generation and CMake sometimes runs out and crashes. -Brad From ben.boeckel at kitware.com Wed Jul 9 11:23:02 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 9 Jul 2014 11:23:02 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BD5B0D.4000708@kitware.com> References: <53BD5B0D.4000708@kitware.com> Message-ID: <20140709152302.GA30351@megas.kitwarein.com> On Wed, Jul 09, 2014 at 11:09:01 -0400, Brad King wrote: > > + std::string targetNameBase = targetName.substr(0, targetName.find_first_of("/")); Not that this is performance-sensitive region, but in the pursuit removing bad patterns to avoid copy/paste issues in the future: std::string targetNameBase = targetName.resize(targetName.find('/')); is better, though the resize might not be doable since there's a check for npos that is necessary if the targetName doesn't have a slash in it. The find_first_of(one_char_string) should definitely be find(one_char) or find_first_of(one_char). Of course, assuming this line survives to the final patch. Thanks, --Ben From tim at klingt.org Wed Jul 9 11:30:46 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 09 Jul 2014 17:30:46 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BD5B0D.4000708@kitware.com> References: <53BD5B0D.4000708@kitware.com> Message-ID: >> cfbundles are currently not installed as directory, but the binary from >> Contents/MacOS is directly installed to the destination. >> >> attached patch fixes the issue. > > Thanks. > > I do not understand this line: > >> + std::string targetNameBase = targetName.substr(0, targetName.find_first_of("/")); > > Why do we need to look for the first slash? targetName is: ${BundleName}${BundleExtension}/Contents/MacOS/${BundleName} we basically want to find ${BundleName}. i did not find any way to determine this information from the Target. > Also, look earlier in that function for the blocks starting in: > > // Handle OSX Bundles. > if(this->Target->IsAppBundleOnApple()) > > and > > else if(this->Target->IsFrameworkOnApple()) > > Those cases do special handling for the post-installation tweaks. > Is something similar needed here? i wonder: which tweaks are they? i've seen the comments, but failed to understand, what kind of post-install tweaks they add, as it is mainly about changing source and destinations. in my use-case it seems to work, but of course i might be missing something ... cheers, tim From brad.king at kitware.com Wed Jul 9 11:44:23 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 11:44:23 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: <53BD5B0D.4000708@kitware.com> Message-ID: <53BD6357.1030108@kitware.com> On 07/09/2014 11:30 AM, Tim Blechmann wrote: >> Why do we need to look for the first slash? > > targetName is: > ${BundleName}${BundleExtension}/Contents/MacOS/${BundleName} Okay, thanks. >> Those cases do special handling for the post-installation tweaks. > > i wonder: which tweaks are they? It's things like running "strip" on the executable file. The line filesTo.push_back(to1); needs to add the path to the executable file, not the directory. The filesTo vector is used only for tweaks and not for generating the main install rules. IIUC we should use std::string to1 = toDir + targetName; for CFBundles to get the location of the installed binary file. Thanks, -Brad From tim at klingt.org Wed Jul 9 11:52:47 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 09 Jul 2014 17:52:47 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BD6357.1030108@kitware.com> References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> Message-ID: >>> Those cases do special handling for the post-installation tweaks. >> >> i wonder: which tweaks are they? > > It's things like running "strip" on the executable file. > > The line > > filesTo.push_back(to1); > > needs to add the path to the executable file, not the directory. > The filesTo vector is used only for tweaks and not for generating > the main install rules. IIUC we should use > > std::string to1 = toDir + targetName; > > for CFBundles to get the location of the installed binary file. ah, i see ... double-checked and this works for me! shall i update the patch? cheers, tim From brad.king at kitware.com Wed Jul 9 12:48:45 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 12:48:45 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> Message-ID: <53BD726D.4030303@kitware.com> On 07/09/2014 11:52 AM, Tim Blechmann wrote: > shall i update the patch? Yes, so that we know the updated version works for what you need. Please also include a change to use Ben's suggestion of targetName.find('/') instead of find_first_of. Thanks, -Brad From konstantin at podsvirov.pro Wed Jul 9 13:30:50 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 09 Jul 2014 21:30:50 +0400 Subject: [cmake-developers] CPack IFW generator Message-ID: <2019241404927050@web7g.yandex.ru> Hello dear developers! And again CPack IFW generator!!! This generator is not part of CMake, but I hope that soon it will become possible. This letter I once again want to awaken interest in the creation of new cross-platform the binary installer is based on Qt Framework Installer tools (http://qt-project.org/doc/qtinstallerframework/index.html) (Sorry for my English. I use a translator) I already appeared here some time ago: http://public.kitware.com/pipermail/cmake-developers/2014-May/010430.html I received some recommendations and considered them. With each commit generator becomes better. As before you can clone the code for the study: git clone git://podsvirov.pro/cmake/cpackifwgenerator.git Or check out the code in your browser: http://git.podsvirov.pro/?p=cmake/cpackifwgenerator.git;a=summary In the Wiki I found an example of creating a binary instalatorow: http://cmake.org/Wiki/CMake:Component_Install_With_CPack My generator also copes with this task. Here's how it looks in Linux and Windows: http://ifw.podsvirov.pro/cmake/cpackifw-componentexample-linux.png http://ifw.podsvirov.pro/cmake/cpackifw-componentexample-windows.png I strive to create the binary installer CMake using a new generator. I already have the achievements. Created installers produce the set of all that was specified in the install(...)but do not create shortcuts. Version of CMake (CPack IFW generator) collected them available for Linux and Windows now: http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-linux-i686.run http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-windows-x64.exe http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-windows-x86.exe Please test these installers and write your comments. It is not excluded that in the folder http://ifw.podsvirov.pro/cmake may be something useful. I've created accounts Mantis and CDash. Git push access to git at cmake.org:cmake.git I do not have. With respect Konstantin Podsvirov From tim at klingt.org Wed Jul 9 14:02:00 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 09 Jul 2014 20:02:00 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BD726D.4030303@kitware.com> References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> <53BD726D.4030303@kitware.com> Message-ID: >> shall i update the patch? > > Yes, so that we know the updated version works for what you need. > Please also include a change to use Ben's suggestion of > > targetName.find('/') > > instead of find_first_of. attached! thanks a lot, tim -------------- next part -------------- >From 18147876fd834a24dcdeca70078c972f84e92866 Mon Sep 17 00:00:00 2001 From: Tim Blechmann Date: Wed, 9 Jul 2014 20:01:11 +0200 Subject: [PATCH] InstallTarget: install CFBundles with complete directory --- Source/cmInstallTargetGenerator.cxx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx index 7a39f45..38d369e 100644 --- a/Source/cmInstallTargetGenerator.cxx +++ b/Source/cmInstallTargetGenerator.cxx @@ -213,6 +213,20 @@ void cmInstallTargetGenerator::GenerateScriptForConfig(std::ostream& os, filesFrom.push_back(from1); filesTo.push_back(to1); } + else if(this->Target->IsCFBundleOnApple()) + { + // Install the whole app bundle directory. + type = cmInstallType_DIRECTORY; + literal_args += " USE_SOURCE_PERMISSIONS"; + + std::string targetNameBase = targetName.substr(0, targetName.find('/')); + + std::string from1 = fromDirConfig + targetNameBase; + std::string to1 = toDir + targetName; + + filesFrom.push_back(from1); + filesTo.push_back(to1); + } else { bool haveNamelink = false; -- 2.0.1 From sdougherty at barracuda.com Wed Jul 9 16:24:51 2014 From: sdougherty at barracuda.com (Steve Dougherty) Date: Wed, 9 Jul 2014 16:24:51 -0400 Subject: [cmake-developers] [PATCH] fix comment typos Message-ID: <1404937491-12660-1-git-send-email-sdougherty@barracuda.com> --- Source/kwsys/Terminal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Source/kwsys/Terminal.c b/Source/kwsys/Terminal.c index 6d7ec41..e13003f 100644 --- a/Source/kwsys/Terminal.c +++ b/Source/kwsys/Terminal.c @@ -104,11 +104,11 @@ void kwsysTerminal_cfprintf(int color, FILE* stream, const char* format, ...) } /*--------------------------------------------------------------------------*/ -/* Detect cases when a stream is definately not interactive. */ +/* Detect cases when a stream is definitely not interactive. */ #if !defined(KWSYS_TERMINAL_ISATTY_WORKS) static int kwsysTerminalStreamIsNotInteractive(FILE* stream) { - /* The given stream is definately not interactive if it is a regular + /* The given stream is definitely not interactive if it is a regular file. */ struct stat stream_stat; if(fstat(fileno(stream), &stream_stat) == 0) @@ -212,7 +212,7 @@ static int kwsysTerminalStreamIsVT100(FILE* stream, int default_vt100, (void)default_tty; return isatty(fileno(stream))? 1:0; #else - /* Check for cases in which the stream is definately not a tty. */ + /* Check for cases in which the stream is definitely not a tty. */ if(kwsysTerminalStreamIsNotInteractive(stream)) { return 0; -- 2.0.1 =========================================================== DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. From sdougherty at barracuda.com Wed Jul 9 16:30:26 2014 From: sdougherty at barracuda.com (Steve Dougherty) Date: Wed, 9 Jul 2014 16:30:26 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <53B4081A.1080205@kitware.com> References: <20140626150242.GA29055@megas.kitwarein.com> <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> <53B4081A.1080205@kitware.com> Message-ID: <53BDA662.90908@barracuda.com> On 07/02/2014 09:24 AM, Brad King wrote: > On 07/02/2014 08:13 AM, Ben Boeckel wrote: >> Colors should only be output if we're outputting to a TTY. Pipes or >> redirections should not be colored (they'll only confuse those who don't >> recognize the escape sequences). CMake also has color routines already, >> but I don't know off-hand how accessible they are from CTest code (i.e., >> might be static functions). > > Look for uses of "cmsysTerminal_cfprintf" as an example. > See its declaration in "Source/kwsys/Terminal.h.in" also. I've attached an implementation that uses cmsysTerminal_cfprintf. Is it acceptable to decouple outputting this line from cmCTest::Log? Currently cmCTestLog is a macro that uses cmCTest::Log, which uses C++ ostreams. Would it be better to move the color logic and manipulation to something shared between Log and cmsysTerminal_cfprintf, and add a Log that can use color? Is it preferable to keep the user-facing string on one line, or break it up for line length? =========================================================== DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-color-test-summary-output.patch Type: text/x-patch Size: 1524 bytes Desc: not available URL: From gvjung at gmail.com Thu Jul 10 00:10:28 2014 From: gvjung at gmail.com (Greg Jung) Date: Wed, 9 Jul 2014 21:10:28 -0700 Subject: [cmake-developers] [CMake 0015011]: problem to find non-standard ncurses.h location In-Reply-To: <82a5d3937e85f6eecde21d8e63cc1cee@public.kitware.com> References: <82a5d3937e85f6eecde21d8e63cc1cee@public.kitware.com> Message-ID: The CMake module scripting is weak regarding the variable that should be taking care of this, CMAKE_SYSTEM_PREFIX_PATH (i.e., /usr; /opt) will be used in find_path (after appending /include) and for find_library(after appending /lib) - according to cmake.html documentation. For my mingw/msys builds I set this and the /include, /lib mostly located in platform/MingW.cmake: ---------------- if(MSYS) # enhance the system prefix path. (picks up /Mingw/lib) find_path( MINGWPATH msys PATH ${CMAKE_USR_PATH}/../../ NO_DEFAULT_PATH) list(APPEND CMAKE_SYSTEM_PREFIX_PATH ${MINGWPATH} ) list(APPEND CMAKE_SYSTEM_INCLUDE_PATH ${MINGWPATH}/include ) list(APPEND CMAKE_SYSTEM_LIBRARY_PATH ${MINGWPATH}/lib ) ------- then LDFLAGS is inspected: ____ set(LDFLAGS "$ENV{LDFLAGS}") if(LDFLAGS) message(STATUS "\n" " inspecting LDFLAGS: ${LDFLAGS}" ) string( REGEX MATCHALL "-L([^\" ]+)" librarylist "${LDFLAGS}" ) foreach(element IN LISTS librarylist) # LDFLAGS is more specific. ------------ etc., leading to message(STATUS " adding system library path: ${library}") list(INSERT CMAKE_SYSTEM_LIBRARY_PATH 0 ${library}) list(INSERT CMAKE_SYSTEM_INCLUDE_PATH 0 ${library}/../include ) ------------------------------------------------------- On Wed, Jul 9, 2014 at 4:14 AM, Mantis Bug Tracker < mantis at public.kitware.com> wrote: > > The following issue has been SUBMITTED. > ====================================================================== > http://public.kitware.com/Bug/view.php?id=15011 > ====================================================================== > Reported By: hsk > Assigned To: > ====================================================================== > Project: CMake > Issue ID: 15011 > Category: (No Category) > Reproducibility: always > Severity: minor > Priority: normal > Status: new > ====================================================================== > Date Submitted: 2014-07-09 07:14 EDT > Last Modified: 2014-07-09 07:14 EDT > ====================================================================== > Summary: problem to find non-standard ncurses.h location > Description: > i have installed gnu ncurses (and several other libraries) under separate > location; os: solaris10, compiler: sunstudio 12.2 > > building cmake 2.8.x worked using > > env \ > CC=cc \ > CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \ > CXX=CC \ > CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \ > LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' > \ > CPPFLAGS=-I/var/imb/include \ > ./bootstrap --prefix=/var/imb; gmake > > with cmake 3.0, the "gmake" step fails: > > cmake-3.0.0/Source/CursesDialog/form/form.h", line 46: cannot find include > file: > > > and -I/var/imb/include must be explicitly added to CFLAGS / CXXFLAGS for > ncurses.h to be found, i.e., i have to use > > env \ > CC=cc \ > CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \ > CXX=CC \ > CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \ > LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' > \ > CPPFLAGS=-I/var/imb/include \ > ./bootstrap --prefix=/var/imb; gmake > > imho, the value of CPPFLAGS should be honoured here > > ====================================================================== > > Issue History > Date Modified Username Field Change > ====================================================================== > 2014-07-09 07:14 hsk New Issue > ====================================================================== > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Thu Jul 10 07:09:07 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 07:09:07 -0400 Subject: [cmake-developers] [CMake 0015012]: Generator expressions provide PLATFORM_ID but its values are not documented Message-ID: <6f38a2b85274f8ba2a216e2c87e70553@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15012 ====================================================================== Reported By: Philipp M?ller Assigned To: ====================================================================== Project: CMake Issue ID: 15012 Category: Documentation Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-10 07:09 EDT Last Modified: 2014-07-10 07:09 EDT ====================================================================== Summary: Generator expressions provide PLATFORM_ID but its values are not documented Description: http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html documents PLATFORM_ID, but does not mention the possible values the variable could have. I suppose the corresponding variable is CMAKE__PLATFORM_ID http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_LANG_PLATFORM_ID.html, but is documented as internal. Removing PLATFORM_ID from generator expressions would be a step backwards since it would remove an important use case, documentation CMAKE__PLATFORM_ID seems the right direction. In general the generator expression documentation could be more explicit about the corresponding variables. Steps to Reproduce: None. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 07:09 Philipp M?ller New Issue ====================================================================== From brad.king at kitware.com Thu Jul 10 10:13:41 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 10:13:41 -0400 Subject: [cmake-developers] [CMake 0015011]: problem to find non-standard ncurses.h location In-Reply-To: References: <82a5d3937e85f6eecde21d8e63cc1cee@public.kitware.com> Message-ID: <53BE9F95.7090101@kitware.com> On 07/10/2014 12:10 AM, Greg Jung wrote: > The CMake module scripting is weak regarding the variable that should be taking care of this, > CMAKE_SYSTEM_PREFIX_PATH (i.e., /usr; /opt) will be used in find_path (after appending /include) > and for find_library(after appending /lib) - according to cmake.html documentation. For my mingw/msys > builds I set this and the /include, /lib mostly located in platform/MingW.cmake: Our issue tracker does not support email-submitted comments. I've copied your comment into the tracker here: http://www.cmake.org/Bug/view.php?id=15011#c36336 Please join discussion over there. Thanks, -Brad From brad.king at kitware.com Thu Jul 10 10:13:48 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 10:13:48 -0400 Subject: [cmake-developers] [PATCH] fix comment typos In-Reply-To: <1404937491-12660-1-git-send-email-sdougherty@barracuda.com> References: <1404937491-12660-1-git-send-email-sdougherty@barracuda.com> Message-ID: <53BE9F9C.2080603@kitware.com> On 07/09/2014 04:24 PM, Steve Dougherty wrote: > --- > Source/kwsys/Terminal.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Thanks. I've applied it to KWSys upstream: Terminal: Fix spelling of 'definitely' in comments http://public.kitware.com/gitweb?p=KWSys.git;a=commitdiff;h=5f28a52b It will be integrated to CMake next time we update our KWSys (which shouldn't be too long). -Brad From brad.king at kitware.com Thu Jul 10 10:13:53 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 10:13:53 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> <53BD726D.4030303@kitware.com> Message-ID: <53BE9FA1.9020600@kitware.com> On 07/09/2014 02:02 PM, Tim Blechmann wrote: > attached! Applied, thanks: OS X: Install CFBundles as complete directories http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=908433bd -Brad From brad.king at kitware.com Thu Jul 10 10:13:58 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 10:13:58 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <53BDA662.90908@barracuda.com> References: <20140626150242.GA29055@megas.kitwarein.com> <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> <53B4081A.1080205@kitware.com> <53BDA662.90908@barracuda.com> Message-ID: <53BE9FA6.2000407@kitware.com> On 07/09/2014 04:30 PM, Steve Dougherty wrote: > I've attached an implementation that uses cmsysTerminal_cfprintf. > > Is it acceptable to decouple outputting this line from cmCTest::Log? Currently > cmCTestLog is a macro that uses cmCTest::Log, which uses C++ ostreams. It will have to go through the log API because HANDLER_OUTPUT does not always go to std::cout. It looks like cmCTest needs to expose a way to determine whether 'StreamOut == &std::cout'. If so, then you could flush cout, write to stdout with cmsysTerminal_cfprintf, and then fflush(stdout). > Would it be better to move the color logic and manipulation to something shared > between Log and cmsysTerminal_cfprintf, and add a Log that can use color? cmsysTerminal is in a separate KWSys library that we import to the Source/kwsys directory. If something were to be shared then it would have to stay in that library. Some refactoring of cfprintf may be needed to fix this issue too: http://www.cmake.org/Bug/view.php?id=12991#c28687 Note that because color in Windows consoles requires state changes instead of using escape sequences it is not possible to achieve a single atomic write with color. > Is it preferable to keep the user-facing string on one line, or break it up for > line length? Unless the numbers are really big I do not see how this summary line can be very long. -Brad From tim at klingt.org Thu Jul 10 11:48:57 2014 From: tim at klingt.org (Tim Blechmann) Date: Thu, 10 Jul 2014 17:48:57 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BE9FA1.9020600@kitware.com> References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> <53BD726D.4030303@kitware.com> <53BE9FA1.9020600@kitware.com> Message-ID: >> attached! > > Applied, thanks: > > OS X: Install CFBundles as complete directories > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=908433bd thanks a lot! i wonder: will this patch make it into 3.0.1? tim From mantis at public.kitware.com Thu Jul 10 12:05:34 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 12:05:34 -0400 Subject: [cmake-developers] [CMake 0015013]: subsystem windowsce is not set for dll only for exes, this makes dll not loadable on wec2013 (wince8) Message-ID: <7691d3a9c33d2c838849e3f413fc5897@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15013 ====================================================================== Reported By: Gunnar Roth Assigned To: ====================================================================== Project: CMake Issue ID: 15013 Category: CMake Reproducibility: always Severity: major Priority: urgent Status: new ====================================================================== Date Submitted: 2014-07-10 12:05 EDT Last Modified: 2014-07-10 12:05 EDT ====================================================================== Summary: subsystem windowsce is not set for dll only for exes, this makes dll not loadable on wec2013 (wince8) Description: the subsystem switch for the linker is only set for executables but not for dlls. this was no problem for ce < wec2013. but wec2013 checks for correct subsystem. you can see this informations using depends.exe from dependancywalker.com Steps to Reproduce: compile a project containg a dll with a wec2013 sdk. this dll will not be loaded on wec2013. Additional Information: this problem can be fixed with this simple patch: --- a\share\cmake-3.0\Modules/Platform/Windows-MSVC.cmake +++ b\share\cmake-3.0\Modules/Platform/Windows-MSVC.cmake @@ -37,12 +37,13 @@ endif() set(WIN32 1) if(CMAKE_SYSTEM_NAME MATCHES "WindowsCE") - set(CMAKE_CREATE_WIN32_EXE "/subsystem:windowsce /entry:WinMainCRTStartup") - set(CMAKE_CREATE_CONSOLE_EXE "/subsystem:windowsce /entry:mainACRTStartup") + set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") + set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") + set(CMAKE_EXE_LINKER_FLAGS_INIT "${CMAKE_EXE_LINKER_FLAGS_INIT} /subsystem:windowsce") set(WINCE 1) else() set(CMAKE_CREATE_WIN32_EXE "/subsystem:windows") set(CMAKE_CREATE_CONSOLE_EXE "/subsystem:console") endif() CMAKE_EXE_LINKER_FLAGS_INIT is inherited by the dll settings but CMAKE_CREATE_WIN32_EXE or CMAKE_CREATE_CONSOLE_EXE is of course not. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 12:05 Gunnar Roth New Issue ====================================================================== From mantis at public.kitware.com Thu Jul 10 12:13:27 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 12:13:27 -0400 Subject: [cmake-developers] [CMake 0015014]: for better release debbuging support for /d2Zi+ option should be added for vs2012 and up Message-ID: <1ff242e6441f7a52feb616e634c5182f@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15014 ====================================================================== Reported By: Gunnar Roth Assigned To: ====================================================================== Project: CMake Issue ID: 15014 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-10 12:13 EDT Last Modified: 2014-07-10 12:13 EDT ====================================================================== Summary: for better release debbuging support for /d2Zi+ option should be added for vs2012 and up Description: since vs2012 the option /d2Zi+ is supported by compiler which created much better debug info for release build and the debugger can actually use it. there is only a slight increase in pdb size. see http://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/ Additional Information: this simple patch add the switch to all projects if the compiler is > 1600 --- a\share\cmake-3.0\Modules/Platform/Windows-MSVC.cmake +++ b\share\cmake-3.0\Modules/Platform/Windows-MSVC.cmake @@ -254,6 +257,11 @@ set(CMAKE_${lang}_FLAGS_INIT "${_PLATFORM_DEFINES}${_PLATFORM_DEFINES_${lang}} /D_WINDOWS /W3${_FLAGS_${lang}}") set(CMAKE_${lang}_FLAGS_DEBUG_INIT "/D_DEBUG /MDd /Zi /Ob0 /Od ${_RTC1}") set(CMAKE_${lang}_FLAGS_RELEASE_INIT "/MD /O2 /Ob2 /D NDEBUG") set(CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT "/MD /Zi /O2 /Ob1 /D NDEBUG") set(CMAKE_${lang}_FLAGS_MINSIZEREL_INIT "/MD /O1 /Ob1 /D NDEBUG") + if(MSVC_VERSION GREATER 1600) + set(CMAKE_${lang}_FLAGS_DEBUG_INIT "${CMAKE_${lang}_FLAGS_DEBUG_INIT} /d2Zi+") + set(CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT "${CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT} /d2Zi+") + endif() + endmacro() ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 12:13 Gunnar Roth New Issue ====================================================================== From brad.king at kitware.com Thu Jul 10 12:56:05 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 12:56:05 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> <53BD726D.4030303@kitware.com> <53BE9FA1.9020600@kitware.com> Message-ID: <53BEC5A5.4060705@kitware.com> On 07/10/2014 11:48 AM, Tim Blechmann wrote: > thanks a lot! i wonder: will this patch make it into 3.0.1? Sure. I rebased the commit back on 3.0.0: OS X: Install CFBundles as complete directories http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3ac67cc -Brad From mantis at public.kitware.com Thu Jul 10 16:10:20 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 16:10:20 -0400 Subject: [cmake-developers] [CMake 0015015]: Bug 0015012 documents the platform Id now but there is no platform I'd for wince defined. Message-ID: <5befb2227dc638fd78d0430d1fa33895@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15015 ====================================================================== Reported By: Gunnar Roth Assigned To: ====================================================================== Project: CMake Issue ID: 15015 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-10 16:10 EDT Last Modified: 2014-07-10 16:10 EDT ====================================================================== Summary: Bug 0015012 documents the platform Id now but there is no platform I'd for wince defined. Description: Is this by intent? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 16:10 Gunnar Roth New Issue ====================================================================== From mantis at public.kitware.com Thu Jul 10 20:19:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 20:19:47 -0400 Subject: [cmake-developers] [CMake 0015016]: FindCUDA creates intermediate objects in wrong place when CUDA_SEPARABLE_COMPILATION is ON. Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15016 ====================================================================== Reported By: Marco Assigned To: ====================================================================== Project: CMake Issue ID: 15016 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-10 20:19 EDT Last Modified: 2014-07-10 20:19 EDT ====================================================================== Summary: FindCUDA creates intermediate objects in wrong place when CUDA_SEPARABLE_COMPILATION is ON. Description: When setting CUDA_SEPARABLE_COMPILATION to ON, if .cu files are not in the same folder of CMakeLists.txt, intermediate linkage objects are generated in the wrong folder, causing a compilation error that, on Visual Studio, looks like this: Cannot open compiler generated file: 'project_path/CMakeFiles/project_name/Debug/project_name_intermediate_link.obj': No such file or directory. Steps to Reproduce: The file attached to this report has a .cu file and a CMakeLists.txt. Generate a Visual Studio solution and try to compile the project to reproduce this bug. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 20:19 Marco New Issue 2014-07-10 20:19 Marco File Added: find_cuda_bug.7z ====================================================================== From vitalii.chernookyi at globallogic.com Fri Jul 11 05:15:25 2014 From: vitalii.chernookyi at globallogic.com (Vitaly Chernooky) Date: Fri, 11 Jul 2014 12:15:25 +0300 Subject: [cmake-developers] Random hang of building process: deedlock in cmake. Message-ID: Hi all! Today I caught again a hang of local building process. I used debugger and strace in steps to catch a bug. so: $ pstree ... | | ??gbs???sh???depanneur???sh???sudo???build???perl ? ? ? ??su???rpmbuild???sh???cmake???gmake ... $ ps ax | grep gmake ... 1105 ? Z 0:00 [gmake] ... $ ps ax | grep cmake ... 760 ? S 0:01 /usr/bin/cmake ... ... $ sudo strace -p 760 [sudo] password for vitalii.chernookyi: Process 760 attached - interrupt to quit select(4, [3], NULL, NULL, NULL^C Process 760 detached $ ls -l /proc/760/fd/3 lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 -> pipe:[1670438] $ ls -l /proc/*/fd/* | grep 'pipe:\[1670438\]' lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 -> pipe:[1670438] l-wx------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:42 /proc/760/fd/4 -> pipe:[1670438] $ sudo gdb -p 760 ... 0x0000000060138543 in ?? () (gdb) bt #0 0x0000000060138543 in ?? () #1 0x000000006004a4ce in ?? () #2 0x000000006004e2fe in ?? () #3 0x0000000060040309 in ?? () #4 0x00000000600039ee in ?? () #5 0x00000000600d9584 in ?? () #6 0x0000000060003f41 in ?? () #7 0x00007fff61dc5e88 in ?? () #8 0x0000000000000000 in ?? () (gdb) quit ... $ So we caught a deedlock. Do anyone have any idea how to fix it? -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalii.chernookyi at globallogic.com Fri Jul 11 05:54:55 2014 From: vitalii.chernookyi at globallogic.com (Vitaly Chernooky) Date: Fri, 11 Jul 2014 12:54:55 +0300 Subject: [cmake-developers] [Dev] Random hang of building process: deedlock in cmake. In-Reply-To: References: Message-ID: Alexander, Yes - you are right. It's just excellent illustration why I hate pipes. So CMake guys can remove this crap from their code and use socketpair() or like instead. \\wbr On Fri, Jul 11, 2014 at 12:33 PM, Kanevskiy, Alexander < alexander.kanevskiy at intel.com> wrote: > On 11/07/14 12:15 , "Vitaly Chernooky" > wrote: > > > This looks like old ?good? bug in qemu that sometimes re-appear in certain > combination of host environment and sources you?re building: > > https://bugs.launchpad.net/qemu/+bug/955379 > > > > > >Hi all! > > > >Today I caught again a hang of local building process. > > > >I used debugger and strace in steps to catch a bug. > > > >so: > > > >$ pstree > >... > > | | ??gbs???sh???depanneur???sh???sudo???build???perl > > ? ? ? > >??su???rpmbuild???sh???cmake???gmake > >... > >$ ps ax | grep gmake > >... > >1105 ? Z 0:00 [gmake] > > > >... > >$ ps ax | grep cmake > >... > > 760 ? S 0:01 /usr/bin/cmake ... > > > >... > >$ sudo strace -p 760 > >[sudo] password for vitalii.chernookyi: > > > > > >Process 760 attached - interrupt to quit > >select(4, [3], NULL, NULL, NULL^C > > > > > >Process 760 detached > >$ ls -l /proc/760/fd/3 > > > >lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 > >-> pipe:[1670438] > > > >$ ls -l /proc/*/fd/* | grep 'pipe:\[1670438\]' > >lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 > >-> pipe:[1670438] > >l-wx------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:42 /proc/760/fd/4 > >-> pipe:[1670438] > > > > > >$ sudo gdb -p 760 > >... > >0x0000000060138543 in ?? () > > > > > >(gdb) bt > >#0 0x0000000060138543 in ?? () > > > > > >#1 0x000000006004a4ce in ?? () > >#2 0x000000006004e2fe in ?? () > > > > > >#3 0x0000000060040309 in ?? () > >#4 0x00000000600039ee in ?? () > > > > > >#5 0x00000000600d9584 in ?? () > >#6 0x0000000060003f41 in ?? () > > > > > >#7 0x00007fff61dc5e88 in ?? () > >#8 0x0000000000000000 in ?? () > > > > > >(gdb) quit > > > > > > > > > >... > >$ > > > > > > > >So we caught a deedlock. > > > >Do anyone have any idea how to fix it? > > > > > >-- > >Vitaly Chernooky | Senior Developer - Product Engineering and Development > >GlobalLogic > >P +380.44.4929695 ext.1136 M +380.98.7920568 S cvv_2k > >www.globallogic.com > > > >http://www.globallogic.com/email_disclaimer.txt > > > > > > > > > > > > > > > -- > Best regards, Alexander Kanevskiy. > > --------------------------------------------------------------------- > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalii.chernookyi at globallogic.com Fri Jul 11 06:04:16 2014 From: vitalii.chernookyi at globallogic.com (Vitaly Chernooky) Date: Fri, 11 Jul 2014 13:04:16 +0300 Subject: [cmake-developers] [Dev] Random hang of building process: deedlock in cmake. In-Reply-To: References: Message-ID: Also it will be good if every body from us will vote for that bug on launchpad. On Fri, Jul 11, 2014 at 12:54 PM, Vitaly Chernooky < vitalii.chernookyi at globallogic.com> wrote: > Alexander, > > Yes - you are right. > > It's just excellent illustration why I hate pipes. > > So CMake guys can remove this crap from their code and use socketpair() or > like instead. > > \\wbr > > > On Fri, Jul 11, 2014 at 12:33 PM, Kanevskiy, Alexander < > alexander.kanevskiy at intel.com> wrote: > >> On 11/07/14 12:15 , "Vitaly Chernooky" >> wrote: >> >> >> This looks like old ?good? bug in qemu that sometimes re-appear in certain >> combination of host environment and sources you?re building: >> >> https://bugs.launchpad.net/qemu/+bug/955379 >> >> >> >> >> >Hi all! >> > >> >Today I caught again a hang of local building process. >> > >> >I used debugger and strace in steps to catch a bug. >> > >> >so: >> > >> >$ pstree >> >... >> > | | ??gbs???sh???depanneur???sh???sudo???build???perl >> > ? ? ? >> >??su???rpmbuild???sh???cmake???gmake >> >... >> >$ ps ax | grep gmake >> >... >> >1105 ? Z 0:00 [gmake] >> > >> >... >> >$ ps ax | grep cmake >> >... >> > 760 ? S 0:01 /usr/bin/cmake ... >> > >> >... >> >$ sudo strace -p 760 >> >[sudo] password for vitalii.chernookyi: >> > >> > >> >Process 760 attached - interrupt to quit >> >select(4, [3], NULL, NULL, NULL^C >> > >> > >> >Process 760 detached >> >$ ls -l /proc/760/fd/3 >> > >> >lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 >> >-> pipe:[1670438] >> > >> >$ ls -l /proc/*/fd/* | grep 'pipe:\[1670438\]' >> >lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 >> >-> pipe:[1670438] >> >l-wx------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:42 /proc/760/fd/4 >> >-> pipe:[1670438] >> > >> > >> >$ sudo gdb -p 760 >> >... >> >0x0000000060138543 in ?? () >> > >> > >> >(gdb) bt >> >#0 0x0000000060138543 in ?? () >> > >> > >> >#1 0x000000006004a4ce in ?? () >> >#2 0x000000006004e2fe in ?? () >> > >> > >> >#3 0x0000000060040309 in ?? () >> >#4 0x00000000600039ee in ?? () >> > >> > >> >#5 0x00000000600d9584 in ?? () >> >#6 0x0000000060003f41 in ?? () >> > >> > >> >#7 0x00007fff61dc5e88 in ?? () >> >#8 0x0000000000000000 in ?? () >> > >> > >> >(gdb) quit >> > >> > >> > >> > >> >... >> >$ >> > >> > >> > >> >So we caught a deedlock. >> > >> >Do anyone have any idea how to fix it? >> > >> > >> >-- >> >Vitaly Chernooky | Senior Developer - Product Engineering and Development >> >GlobalLogic >> >P +380.44.4929695 ext.1136 M +380.98.7920568 S cvv_2k >> >www.globallogic.com >> > >> >http://www.globallogic.com/email_disclaimer.txt >> > >> > >> > >> > >> > >> > >> >> >> -- >> Best regards, Alexander Kanevskiy. >> >> --------------------------------------------------------------------- >> Intel Finland Oy >> Registered Address: PL 281, 00181 Helsinki >> Business Identity Code: 0357606 - 4 >> Domiciled in Helsinki >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> > > > > -- > *Vitaly Chernooky | Senior Developer - Product Engineering and Development* > GlobalLogic > P *+380.44.4929695 ext.1136 <%2B380.44.4929695%20ext.1136>* M *+380.98.7920568 > <%2B380.98.7920568>* S cvv_2k > www.globallogic.com > > http://www.globallogic.com/email_disclaimer.txt > -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalii.chernookyi at globallogic.com Fri Jul 11 06:05:50 2014 From: vitalii.chernookyi at globallogic.com (Vitaly Chernooky) Date: Fri, 11 Jul 2014 13:05:50 +0300 Subject: [cmake-developers] [Dev] Random hang of building process: deedlock in cmake. In-Reply-To: <53BFAE72.7020707@samsung.com> References: <53BFAE72.7020707@samsung.com> Message-ID: Ilya, do you still interested in build logs? I've collected them. \\wbr On Fri, Jul 11, 2014 at 12:29 PM, Ilya Palachev wrote: > Hi, Vitaly. > Maybe your backtrace information will be somehow more useful if you > download and unrpm > "debuginfo" and "debugsource" rpm packages from the repository that you > use as default repository in your ~/.gbs.conf > > If you use native gdb (not in chroot) these RPMs should be unrpm'ed inside > root (/) directory, so that new files > will appear in directories /usr/lib/debug and /usr/src/debug. > > I have already noticed cmake's hanging in our build system for many times > about 2 yours ago. Maybe it's specific for our environment. > > Also the output log of cmake will be useful. Does cmake hangs during the > search of some libraries? > > Best regards, > Ilya Palachev > ------------------------------ > > *From:* Vitaly Chernooky > > *Sent:* Friday, July 11, 2014 1:15PM > *To:* cmake-developers at cmake.org, dev at lists.tizen.org > > *Cc:* Andrii Anisov > > *Subject:* [Dev] Random hang of building process: deedlock in cmake. > > Hi all! > > Today I caught again a hang of local building process. > > I used debugger and strace in steps to catch a bug. > > so: > > $ pstree > ... > | | ??gbs???sh???depanneur???sh???sudo???build???perl > ? ? ? > ??su???rpmbuild???sh???cmake???gmake > ... > $ ps ax | grep gmake > ... > 1105 ? Z 0:00 [gmake] > ... > $ ps ax | grep cmake > ... > 760 ? S 0:01 /usr/bin/cmake ... > ... > $ sudo strace -p 760 > [sudo] password for vitalii.chernookyi: > > > Process 760 attached - interrupt to quit > select(4, [3], NULL, NULL, NULL^C > > > Process 760 detached > $ ls -l /proc/760/fd/3 > > lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 -> > pipe:[1670438] > $ ls -l /proc/*/fd/* | grep 'pipe:\[1670438\]' > lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 > -> pipe:[1670438] > l-wx------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:42 /proc/760/fd/4 -> > pipe:[1670438] > > $ sudo gdb -p 760 > ... > 0x0000000060138543 in ?? () > > > (gdb) bt > #0 0x0000000060138543 in ?? () > > > #1 0x000000006004a4ce in ?? () > #2 0x000000006004e2fe in ?? () > > > #3 0x0000000060040309 in ?? () > #4 0x00000000600039ee in ?? () > > > #5 0x00000000600d9584 in ?? () > #6 0x0000000060003f41 in ?? () > > > #7 0x00007fff61dc5e88 in ?? () > #8 0x0000000000000000 in ?? () > > > (gdb) quit > > > ... > $ > > > So we caught a deedlock. > > Do anyone have any idea how to fix it? > > > -- > *Vitaly Chernooky | Senior Developer - Product Engineering and > Development* > GlobalLogic > P *+380.44.4929695 ext.1136 <%2B380.44.4929695%20ext.1136>* M *+380.98.7920568 > <%2B380.98.7920568>* S cvv_2k > www.globallogic.com > > http://www.globallogic.com/email_disclaimer.txt > > > _______________________________________________ > Dev mailing listDev at lists.tizen.orghttps://lists.tizen.org/listinfo/dev > > > > > -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Jul 11 18:24:20 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 11 Jul 2014 18:24:20 -0400 Subject: [cmake-developers] [CMake 0015017]: Changing compiler/library versions, Finding Packages, and etc. Message-ID: <5564407c8b307f7d248bc460f4b02144@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15017 ====================================================================== Reported By: rhl Assigned To: ====================================================================== Project: CMake Issue ID: 15017 Category: (No Category) Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-11 18:24 EDT Last Modified: 2014-07-11 18:24 EDT ====================================================================== Summary: Changing compiler/library versions, Finding Packages, and etc. Description: Hi, I really enjoy using CMake, it takes a lot of redundancy and hassle out of build systems. Thank you to all developers involved :) I am writing to request the developers to consider making a high level change to the way that the compilers are chosen and changed as well as packages are added. It would be great if there was a way (say within ccmake) to selectively choose which of the many compilers on a system are available, and, when adding packages via find_package, if some list of the available FindXXX.cmake scripts could be made conveniently available. Regularly I am on a system with many compiler choices ( a modern os/x machine with homebrew will have clang by default, but gcc installed on the side potentially, or gcc symlinked to clang) and possibly many library versions. It would be great to be able to selectively choose when running cmake or ccmake which of these libraries/compilers I want to compile/link with based on what cmake is able to find when inspecting the system. On linux with the environment-modules or like program, many many different compilers can be available, many flavors of gcc, icc, clang, etc.. I find it a hassle to have to modify the CMakeLists.txt each time i need to change the compiler and add/remove specific compiler flags. I'm sure you are all busy and i'm not sure if anyone else is interested in this, or some variant of this idea.. At any rate, thanks again for all your hard work. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-11 18:24 rhl New Issue ====================================================================== From mantis at public.kitware.com Sat Jul 12 16:41:49 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Jul 2014 16:41:49 -0400 Subject: [cmake-developers] [CMake 0015018]: Try_run with project and target Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15018 ====================================================================== Reported By: Andrew Aladjev Assigned To: ====================================================================== Project: CMake Issue ID: 15018 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-12 16:41 EDT Last Modified: 2014-07-12 16:41 EDT ====================================================================== Summary: Try_run with project and target Description: "try_compile" has ability to work with complete project and it's target, "try_run" do not. Why? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-12 16:41 Andrew Aladjev New Issue ====================================================================== From mantis at public.kitware.com Mon Jul 14 10:47:07 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 14 Jul 2014 10:47:07 -0400 Subject: [cmake-developers] [CMake 0015020]: Segmentation Fault after writing build files Message-ID: <7fd5977decc1460ef3e83a4f82aa0a30@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15020 ====================================================================== Reported By: k0n3ru Assigned To: ====================================================================== Project: CMake Issue ID: 15020 Category: CMake Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-14 10:47 EDT Last Modified: 2014-07-14 10:47 EDT ====================================================================== Summary: Segmentation Fault after writing build files Description: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff774117f in std::basic_string, std::allocator >::~basic_string() () from /usr/lib64/libstdc++.so.6 (gdb) bt http://www.cmake.org/Bug/view.php?id=0 0x00007ffff774117f in std::basic_string, std::allocator >::~basic_string() () from /usr/lib64/libstdc++.so.6 http://www.cmake.org/Bug/view.php?id=1 0x00000000005f9efa in cmListFileContext::~cmListFileContext() () http://www.cmake.org/Bug/view.php?id=2 0x00000000005f9f55 in void std::_Destroy(cmListFileContext*) () http://www.cmake.org/Bug/view.php?id=3 0x00000000005f9f72 in void std::_Destroy(cmListFileContext*, cmListFileContext*) () http://www.cmake.org/Bug/view.php?id=4 0x00000000005f9fa4 in void std::_Destroy(cmListFileContext*, cmListFileContext*, std::allocator&) () http://www.cmake.org/Bug/view.php?id=5 0x0000000000600813 in std::vector >::~vector() () http://www.cmake.org/Bug/view.php?id=6 0x000000000060086f in cmListFileBacktrace::~cmListFileBacktrace() () http://www.cmake.org/Bug/view.php?id=7 0x000000000070b98b in cmCustomCommand::~cmCustomCommand() () http://www.cmake.org/Bug/view.php?id=8 0x000000000060a075 in void std::_Destroy(cmCustomCommand*) () http://www.cmake.org/Bug/view.php?id=9 0x000000000060a092 in void std::_Destroy(cmCustomCommand*, cmCustomCommand*) () http://www.cmake.org/Bug/view.php?id=10 0x000000000060a0c7 in void std::_Destroy(cmCustomCommand*, cmCustomCommand*, std::allocator&) () http://www.cmake.org/Bug/view.php?id=11 0x000000000060a0f9 in std::vector >::~vector() () http://www.cmake.org/Bug/view.php?id=12 0x000000000060a697 in cmTarget::~cmTarget() () http://www.cmake.org/Bug/view.php?id=13 0x000000000060a894 in std::pair::~pair() () http://www.cmake.org/Bug/view.php?id=14 0x000000000060a903 in __gnu_cxx::new_allocator >::destroy(std::pair*) () http://www.cmake.org/Bug/view.php?id=15 0x000000000060a93a in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_destroy_node(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=16 0x000000000060a9bf in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=17 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=18 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=19 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=20 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=21 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=22 0x000000000060a9f4 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::~_Rb_tree() () http://www.cmake.org/Bug/view.php?id=23 0x000000000060aa4f in std::map, std::allocator > >::~map() () http://www.cmake.org/Bug/view.php?id=24 0x00000000005ebc27 in cmMakefile::~cmMakefile() () http://www.cmake.org/Bug/view.php?id=25 0x000000000078760a in cmLocalGenerator::~cmLocalGenerator() () http://www.cmake.org/Bug/view.php?id=26 0x00000000007948db in cmLocalUnixMakefileGenerator3::~cmLocalUnixMakefileGenerator3() () http://www.cmake.org/Bug/view.php?id=27 0x0000000000743a70 in cmGlobalGenerator::~cmGlobalGenerator() () http://www.cmake.org/Bug/view.php?id=28 0x000000000076485d in cmGlobalUnixMakefileGenerator3::~cmGlobalUnixMakefileGenerator3() () http://www.cmake.org/Bug/view.php?id=29 0x000000000065d9c0 in cmake::~cmake() () http://www.cmake.org/Bug/view.php?id=30 0x00000000005b2194 in do_cmake(int, char**) () http://www.cmake.org/Bug/view.php?id=31 0x00000000005b2297 in main () Additional Information: This backtrace was generated from gdb. I have tried with CMake version 2.8.12.1 and this problem does not appear. Seems all the files have been generated.I was able to build entire project successfully with the generated MakeFile. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-14 10:47 k0n3ru New Issue ====================================================================== From nilsgladitz at gmail.com Mon Jul 14 17:20:59 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 14 Jul 2014 23:20:59 +0200 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <2019241404927050@web7g.yandex.ru> References: <2019241404927050@web7g.yandex.ru> Message-ID: <53C449BB.3070506@gmail.com> On 09.07.2014 19:30, Konstantin Podsvirov wrote: > Hello dear developers! > > And again CPack IFW generator!!! > > This generator is not part of CMake, but I hope that soon it will become possible. > > This letter I once again want to awaken interest in the creation of new cross-platform > the binary installer is based on Qt Framework Installer tools (http://qt-project.org/doc/qtinstallerframework/index.html) > > (Sorry for my English. I use a translator) > > I already appeared here some time ago: > http://public.kitware.com/pipermail/cmake-developers/2014-May/010430.html > > I received some recommendations and considered them. > > With each commit generator becomes better. > > As before you can clone the code for the study: > git clone git://podsvirov.pro/cmake/cpackifwgenerator.git > > Or check out the code in your browser: > http://git.podsvirov.pro/?p=cmake/cpackifwgenerator.git;a=summary > > In the Wiki I found an example of creating a binary instalatorow: > http://cmake.org/Wiki/CMake:Component_Install_With_CPack > > My generator also copes with this task. Here's how it looks in Linux and Windows: > http://ifw.podsvirov.pro/cmake/cpackifw-componentexample-linux.png > http://ifw.podsvirov.pro/cmake/cpackifw-componentexample-windows.png > > I strive to create the binary installer CMake using a new generator. I already have the achievements. > Created installers produce the set of all that was specified in the install(...)but do not create shortcuts. > Version of CMake (CPack IFW generator) collected them available for Linux and Windows now: > http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-linux-i686.run > http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-windows-x64.exe > http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-windows-x86.exe > > Please test these installers and write your comments. Hello again :) Some stuff that remains from my earlier observations: - Lot of commented out code that should be removed. - Unescaped XML content from CMake variables. Some other random stuff I noticed: - CPACK_IFW_BINARYCREATOR_EXECUTABLE_FOUND seems redundant given that find_program() already encodes this in the cache variable. - In the CMake coding conventions class members start upper case. I tried building a CMake installer with the generator again but it failed with: Caught exception: Component version for '/home/ngladitz/src/git/cpackifwgenerator/build/_CPack_Packages/Linux-x86_64/IFW/cmake-3.0.20140709-gd078a-Linux-x86_64/packages/CMake/meta/package.xml' is invalid! 3.0.20140709-gd078a Nils From mantis at public.kitware.com Tue Jul 15 04:47:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Jul 2014 04:47:19 -0400 Subject: [cmake-developers] [CMake 0015021]: misleading header comments in FindHDF5 Message-ID: <9b1bfcc311638a240615ad265ded4b5f@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15021 ====================================================================== Reported By: Joachim Wuttke Assigned To: ====================================================================== Project: CMake Issue ID: 15021 Category: Modules Reproducibility: have not tried Severity: text Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-15 04:47 EDT Last Modified: 2014-07-15 04:47 EDT ====================================================================== Summary: misleading header comments in FindHDF5 Description: - Header component says module takes 'COMPONENTS' argument. Doesn't work for me; what works for me is set( HDF5_FIND_COMPONENTS "CXX" ) include( FindHDF5 ) - Header comment says module will define 'HDF5_CXX_LIBRARIES'. Doesn't work for me; the module only defines 'HDF5_LIBRARIES' ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-15 04:47 Joachim Wuttke New Issue ====================================================================== From daniele.domenichelli at gmail.com Tue Jul 15 04:52:39 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 15 Jul 2014 10:52:39 +0200 Subject: [cmake-developers] RFC fix_Xcode_generator_name topic Message-ID: <53C4EBD7.30809@gmail.com> Hello all, Can anyone with OSX and Xcode check if this commit is correct? http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e475c067 I have no way to test it, but by looking at the code, it looks to me that the name should be Xcode instead of XCode... Thanks, Daniele From steveire at gmail.com Tue Jul 15 07:00:24 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 15 Jul 2014 13:00:24 +0200 Subject: [cmake-developers] cost of usage requirements In-Reply-To: <53BD5BCE.2020204@kitware.com> References: <20140608225611.GC18896@megas.kitwarein.com> <8D151EF9D6FCEA2-26D4-1169@webmail-d299.sysops.aol.com> <20140610171757.GA3906@megas.kitwarein.com> <53986BDC.7090707@kitware.com> <53BD5BCE.2020204@kitware.com> Message-ID: <53C509C8.6090100@gmail.com> On 07/09/2014 05:12 PM, Brad King wrote: > On 06/11/2014 10:46 AM, Brad King wrote: >> Here is a sscce:: >> >> cmake_minimum_required(VERSION 2.8.9) >> project(ManyLibs C) >> set(LibPrev) >> foreach(n RANGE 100) >> add_library(Lib${n} SHARED lib.c) >> target_link_libraries(Lib${n} LINK_PUBLIC ${LibPrev}) >> set(LibPrev Lib${n}) >> endforeach() > A similar case also appears when building VTKWikiExamples > as discussed on the cmake user list here: > > cmake 3.0 memory usage on VTKWikiExamples > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/49910/focus=49922 > > Memory usage explodes during generation and CMake sometimes > runs out and crashes. Is this affected in any way by the recent refactoring with the same motivation? Thanks, Steve. From brad.king at kitware.com Tue Jul 15 09:07:19 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Jul 2014 09:07:19 -0400 Subject: [cmake-developers] RFC fix_Xcode_generator_name topic In-Reply-To: <53C4EBD7.30809@gmail.com> References: <53C4EBD7.30809@gmail.com> Message-ID: <53C52787.2010407@kitware.com> On 07/15/2014 04:52 AM, Daniele E. Domenichelli wrote: > Can anyone with OSX and Xcode check if this commit is correct? > > http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e475c067 > > I have no way to test it, but by looking at the code, it looks to me > that the name should be Xcode instead of XCode... Yes, please merge for testing in 'next'. Thanks, -Brad From daniele.domenichelli at gmail.com Tue Jul 15 09:14:44 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 15 Jul 2014 15:14:44 +0200 Subject: [cmake-developers] RFC fix_Xcode_generator_name topic In-Reply-To: <53C52787.2010407@kitware.com> References: <53C4EBD7.30809@gmail.com> <53C52787.2010407@kitware.com> Message-ID: <53C52944.4000206@gmail.com> On 15/07/14 15:07, Brad King wrote: > Yes, please merge for testing in 'next'. Done, Thanks. Cheers, Daniele From brad.king at kitware.com Tue Jul 15 09:47:54 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Jul 2014 09:47:54 -0400 Subject: [cmake-developers] cost of usage requirements In-Reply-To: <53C509C8.6090100@gmail.com> References: <20140608225611.GC18896@megas.kitwarein.com> <8D151EF9D6FCEA2-26D4-1169@webmail-d299.sysops.aol.com> <20140610171757.GA3906@megas.kitwarein.com> <53986BDC.7090707@kitware.com> <53BD5BCE.2020204@kitware.com> <53C509C8.6090100@gmail.com> Message-ID: <53C5310A.8000108@kitware.com> On 07/15/2014 07:00 AM, Stephen Kelly wrote: > On 07/09/2014 05:12 PM, Brad King wrote: >> Memory usage explodes during generation and CMake sometimes >> runs out and crashes. > > Is this affected in any way by the recent refactoring with the same > motivation? The refactoring so far does not help much directly, but it does reduce some code duplication to make further improvements easier. A small example that is a bit closer to what happens in VTKWikiExamples is: cmake_minimum_required(VERSION 2.8.9) project(ManyLibs C) set(LibPrev) foreach(n RANGE 100) add_library(Lib${n} SHARED lib.c) target_link_libraries(Lib${n} LINK_PUBLIC ${LibPrev}) set(LibPrev Lib${n}) endforeach() foreach(n RANGE 100) add_executable(Exe${n} exe.c) target_link_libraries(Exe${n} ${LibPrev}) endforeach() On my machine: ========= ========= ========= ======== version real user sys ========= ========= ========= ======== 2.8.9 0m1.017s 0m0.912s 0m0.096s 2.8.12.2 0m7.293s 0m7.156s 0m0.120s 3.0.0 0m10.728s 0m10.384s 0m0.128s 487b6ccd 0m20.819s 0m20.724s 0m0.092s 7bc84502 0m11.390s 0m11.296s 0m0.084s ========= ========= ========= ======== The cleanup between 487b6ccd and 7bc84502 got this example back to 3.0-ish time but nothing like 2.8.9. -Brad From mantis at public.kitware.com Tue Jul 15 09:53:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Jul 2014 09:53:51 -0400 Subject: [cmake-developers] [CMake 0015023]: Researchers Find Bacon Sandwich Perfect Cure For A Hangover Message-ID: <982959b7437d8a43c631dfdc76f017e0@www.itk.org> The following issue has been SUBMITTED. ====================================================================== http://www.itk.org/Bug/view.php?id=15023 ====================================================================== Reported By: Melva Jorgensen Assigned To: ====================================================================== Project: CMake Issue ID: 15023 Category: CMakeSetup Reproducibility: have not tried Severity: trivial Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-15 09:53 EDT Last Modified: 2014-07-15 09:53 EDT ====================================================================== Summary: Researchers Find Bacon Sandwich Perfect Cure For A Hangover Description: This is quite a challenge. Coat a bacon (utilize the basic supermarket kind) in a half-cup of brown glucose. I'm a big time bacon eater. Of course, the issue with bacon has always been it is fattening. This really is boiled or baked and then served hot or cold. Some, which includes Bacon, refused to hear. If you don't know where your cholesterol, blood pressure, and blood sugar levels are, this is a advantageous time for a check-up plus blood tests. Chop the stem off and cut the flowerettes into bite sized pieces. Raw, fresh food ingredients offer one of the best basis for a healthy diet. A small object to act as the "bacon." Any small object may be used as the bacon - a small ball or dry erase board eraser are usually easy to find in a classroom setting. The mess is nothing more then a tiny puddle of grease, which may later be saved by diehard foodies that recognize which bacon grease, is as close to paradise because you can get without entering the actual gates. It contains less fat than the conventional bacon from the U.S. Although quiche is connected with the French, plus is in fact a classic French dish, it originally was built in Germany. You are able to eat it right away! Get pitted medjool dates, though this is produced with usual dates furthermore. While we will create healthier food options, most days of the week, we could furthermore enjoy each today and then. The olive oil sticks to the pasta (don't rinse the pasta inside cold water, warm pasta holds the oil plus seasonings better) plus blends all flavors. That was around the time that I was in "Diner." I've heard there is going to be a "Footloose" remake starring Zac Effron. It barely looks fair but, given the method the awards ceremonies are conducted, only 1 normally walks away the winner when there are a quantity of losers, foremost of that are the final contenders for the particular award being given away. Water temperature, salinity, and nearby tides all affect the taste of a oyster. We should be thoughtful to monitor the oven, considering in the event you cook it too lengthy, it might burn. Challenge 5: Not targeting the Right Market. Bacon is one of the many universal foods accessible as it can be served with or added to any kind of edible entr???e. Enjoy delicious deviled eggs with bacon ( http://bacon4.me/ ) yourselves! In buying bacon, it is commonly more economical to purchase the entire side, or the entire center cut, yet when smaller quantities are desired, any amount, either in 1 piece or inside slices, can be bought. The insides of the date are like molten lava. Also you will learn all regarding the different toxicities and just how they affect a wellness. Transfer the bacon onto several paper towels which will soak up the excess grease plus then serve them. Store pre packaged fresh beef the same way, first loosening original wrapper. That is a time-honored spot reserved for "a side of a pig cured and smoked." "But the fat! Safety consultants that conserve the bacon, as well as furthermore save a revenue.Not to mention, that safety consultants can see any safety issues about the website, and may imply the difference between an injury or a death online site. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-15 09:53 Melva JorgensenNew Issue ====================================================================== From mantis at public.kitware.com Tue Jul 15 10:01:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Jul 2014 10:01:09 -0400 Subject: [cmake-developers] [CMake 0015023]: Researchers Find Bacon Sandwich Perfect Cure For A Hangover In-Reply-To: <982959b7437d8a43c631dfdc76f017e0@www.cmake.org> Message-ID: The following issue has been DELETED. ====================================================================== Reported By: Melva Jorgensen Assigned To: ====================================================================== Project: CMake Issue ID: 15023 Category: CMakeSetup Reproducibility: have not tried Severity: trivial Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-15 09:53 EDT Last Modified: 2014-07-15 09:53 EDT ====================================================================== Summary: Researchers Find Bacon Sandwich Perfect Cure For A Hangover Description: This is quite a challenge. Coat a bacon (utilize the basic supermarket kind) in a half-cup of brown glucose. I'm a big time bacon eater. Of course, the issue with bacon has always been it is fattening. This really is boiled or baked and then served hot or cold. Some, which includes Bacon, refused to hear. If you don't know where your cholesterol, blood pressure, and blood sugar levels are, this is a advantageous time for a check-up plus blood tests. Chop the stem off and cut the flowerettes into bite sized pieces. Raw, fresh food ingredients offer one of the best basis for a healthy diet. A small object to act as the "bacon." Any small object may be used as the bacon - a small ball or dry erase board eraser are usually easy to find in a classroom setting. The mess is nothing more then a tiny puddle of grease, which may later be saved by diehard foodies that recognize which bacon grease, is as close to paradise because you can get without entering the actual gates. It contains less fat than the conventional bacon from the U.S. Although quiche is connected with the French, plus is in fact a classic French dish, it originally was built in Germany. You are able to eat it right away! Get pitted medjool dates, though this is produced with usual dates furthermore. While we will create healthier food options, most days of the week, we could furthermore enjoy each today and then. The olive oil sticks to the pasta (don't rinse the pasta inside cold water, warm pasta holds the oil plus seasonings better) plus blends all flavors. That was around the time that I was in "Diner." I've heard there is going to be a "Footloose" remake starring Zac Effron. It barely looks fair but, given the method the awards ceremonies are conducted, only 1 normally walks away the winner when there are a quantity of losers, foremost of that are the final contenders for the particular award being given away. Water temperature, salinity, and nearby tides all affect the taste of a oyster. We should be thoughtful to monitor the oven, considering in the event you cook it too lengthy, it might burn. Challenge 5: Not targeting the Right Market. Bacon is one of the many universal foods accessible as it can be served with or added to any kind of edible entr???e. Enjoy delicious deviled eggs with bacon ( http://bacon4.me/ ) yourselves! In buying bacon, it is commonly more economical to purchase the entire side, or the entire center cut, yet when smaller quantities are desired, any amount, either in 1 piece or inside slices, can be bought. The insides of the date are like molten lava. Also you will learn all regarding the different toxicities and just how they affect a wellness. Transfer the bacon onto several paper towels which will soak up the excess grease plus then serve them. Store pre packaged fresh beef the same way, first loosening original wrapper. That is a time-honored spot reserved for "a side of a pig cured and smoked." "But the fat! Safety consultants that conserve the bacon, as well as furthermore save a revenue.Not to mention, that safety consultants can see any safety issues about the website, and may imply the difference between an injury or a death online site. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-15 09:53 Melva JorgensenNew Issue 2014-07-15 10:01 Brad King Issue Deleted: 0015023 ====================================================================== From mantis at public.kitware.com Wed Jul 16 10:09:58 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Jul 2014 10:09:58 -0400 Subject: [cmake-developers] [CMake 0015026]: Build fails with Cray compiler on Linux Message-ID: <9dc6911598a810fa65fd31b690a9c393@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15026 ====================================================================== Reported By: Chuck Atkins Assigned To: ====================================================================== Project: CMake Issue ID: 15026 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-16 10:09 EDT Last Modified: 2014-07-16 10:09 EDT ====================================================================== Summary: Build fails with Cray compiler on Linux Description: When building with the Cray compiler on Linux (on an XE6 or XE7 such as Titan or Garnet, for example), the CMake curl library fails to build. Steps to Reproduce: 1. Checkout current master on a Cray XE6 or XE7 2. Configure the programming environment to use the cray compilers: # module purge # module load PrgEnv-cray # module load cce 3. Configure and build. The result will fail with: CC-20 craycc: ERROR File = /dev/shm/atkins3/cmake/master/Utilities/cmcurl/hostip.c, Line = 616 The identifier "SIZEOF_in_addr" is undefined. memcpy(addrentry, &num, SIZEOF_in_addr); ^ Total errors detected in /dev/shm/atkins3/cmake/master/Utilities/cmcurl/hostip.c: 1 Additional Information: The error is caused by a workaround for UNICOS. The workaround incorrectly uses the _CRAYC macro to determine if building for UNICOS. This macro will always be defined for the Cray C and C++ compiler regardless of the target platform, even when building for Linux. The correct macro should be _CRAY, which as per Cray documentation is only defined for UNICOS targeted builds. Attached is a patch with a fix. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-16 10:09 Chuck Atkins New Issue 2014-07-16 10:09 Chuck Atkins File Added: 0001-Fix-a-build-failure-with-the-Cray-compiler-on-Linux.patch ====================================================================== From daniele.domenichelli at gmail.com Wed Jul 16 11:55:17 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Wed, 16 Jul 2014 17:55:17 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree Message-ID: <53C6A065.7010201@gmail.com> Hello all, Please review the topic CMakePackageConfigHelpers_build_tree. This patch adds an option BUILD_TREE to configure_package_config_file. At the moment it is complicated to generate config files both for install and build tree, usually combined with "export(TARGETS)" and "install(EXPORT)", using configure_package_config_file, and it will require to tweak the build tree variables to always use absolute paths, or the generated config file will be broken. You can generate valid config files, but in the build tree the relative paths will always be calculated compared to CMAKE_INSTALL_PREFIX, and this does not make sense, and also generates config files with very long lists of "../../../" and difficult to read. The BUILD_TREE option instructs configure_package_config_file to consider paths that are not absolute as relative to the CMAKE_BINARY_DIR directory instead of relative to the CMAKE_INSTALL_PREFIX` directory. This makes a lot easier to generate 2 different config files, one for the build directory and one to install with the package. * CMakePackageConfigHelpers: Remove unused variable: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=7d7bb039 * CMakePackageConfigHelpers: restructure documentation and document commands: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=a8e70768 * CMakePackageConfigHelpers: Add BUILD_TREE option: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=d64849af * CMakePackageConfigHelpers: Add unit tests for BUILD_TREE option: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=3d3695ca Cheers, Daniele From mantis at public.kitware.com Wed Jul 16 21:46:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Jul 2014 21:46:04 -0400 Subject: [cmake-developers] [CMake 0015027]: Failure to find GTK Message-ID: <038aec60f2e8b92e8da7288c43387e39@cmake.org> The following issue has been SUBMITTED. ====================================================================== http://cmake.org/Bug/view.php?id=15027 ====================================================================== Reported By: Luc J. Bourhis Assigned To: ====================================================================== Project: CMake Issue ID: 15027 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-16 21:46 EDT Last Modified: 2014-07-16 21:46 EDT ====================================================================== Summary: Failure to find GTK Description: In the process of building cmake on that version of MacOS 10.9, I get the following failures {{{ CMake Error at Modules/FindGTK2.cmake:181 (file): file STRINGS file "/Library/Frameworks/Gtk.framework/Headers/gtk/gtk/gtkversion.h" cannot be read. Call Stack (most recent call first): Modules/FindGTK2.cmake:796 (_GTK2_GET_VERSION) Tests/CMakeLists.txt:1197 (find_package) }}} There is a file /Library/Frameworks/Gtk.framework/Headers/gtk/gtkversion.h on my system. Steps to Reproduce: 1. Install MacPorts 2. Issue "port install cmake" Additional Information: I was advised by the MacPorts maintainer to report the bug upstream. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-16 21:46 Luc J. Bourhis New Issue ====================================================================== From konstantin at podsvirov.pro Thu Jul 17 03:33:01 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Jul 2014 11:33:01 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <53C449BB.3070506@gmail.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> Message-ID: <2681081405582381@web7g.yandex.ru> Hi Nils, and other developers! 15.07.2014, 01:21, "Nils Gladitz" : > Hello again :) > Some stuff that remains from my earlier observations: > - A Lot of commented out code that should be removed. I do this work sometimes > Is Unescaped XML content from CMake variables. Now I use cmXMLSafe in several places > Some other random stuff I noticed: > - CPACK_IFW_BINARYCREATOR_EXECUTABLE_FOUND seems redundant given that > find_program() already encodes this in the cache variable. I think you're right and I'll get rid of this variable in the near future. But as long as the variable is still alive. > - In the CMake coding conventions class members start uppercase. The names of the methods I write with a capital letter, but the property names with a small letter as in the base class cmCpackGenerator. > I tried building a CMake installer with the generator again but it > failed with: > Caught exception: Component version for > '/home/ngladitz/src/git/cpackifwgenerator/build/_CPack_Packages/Linux-x86_64/IFW/cmake-3.0.20140709-gd078a-Linux-x86_64/packages/CMake/meta/package.xml' > is invalid! 3.0.20140709-gd078a Now I fixed it. Should work. Regards From konstantin at podsvirov.pro Thu Jul 17 03:57:59 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Jul 2014 11:57:59 +0400 Subject: [cmake-developers] =?koi8-r?b?Q1BhY2sgSUZXIMfFzsXSwdTP0g==?= Message-ID: <3923551405583879@web23m.yandex.ru> Hello fans of CMake and Windows! I want to present the online installer CMake for 32-bit and 64-bit versions of Windows. And immediately the binaries: http://ifw.podsvirov.pro/cmake/cmake-master-windows-32bit-online.exe http://ifw.podsvirov.pro/cmake/cmake-master-windows-64bit-online.exe The installer will install CMake from an online repository and create shortcuts in the start menu. The composition of the labels is the same as that of the NSIS installer. But there is a difference: the Uninstaller allows not only to delete it may update CMake. The content of the installed package matches the 'master' branch source code + the CPack IFW generator. CMake well done: he build and package himself :-) I don't promise daily updates, but once a week I'll try to put a fresh build. Regards, Konstantin Podsvirov From konstantin at podsvirov.pro Thu Jul 17 04:11:48 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Jul 2014 12:11:48 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <3923551405583879@web23m.yandex.ru> References: <3923551405583879@web23m.yandex.ru> Message-ID: <6963841405584708@web29h.yandex.ru> 17.07.2014, 12:04, "Konstantin Podsvirov" : > Hello fans of CMake and Windows! > > I want to present the online installer CMake for 32-bit and 64-bit versions of Windows. All well and good, but the title of the previous writing containing Russian characters. Sorry :-) just Russian is my native language. It was a typo. The installers I presented are test and may contain errors. If you have questions or suggestions, please write to the list or to me personally. Regards, Konstantin Podsvirov From mantis at public.kitware.com Thu Jul 17 06:23:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 17 Jul 2014 06:23:47 -0400 Subject: [cmake-developers] [CMake 0015028]: CMake build error on QNX Message-ID: <75c413d5038cfb1015bd72003156ed56@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15028 ====================================================================== Reported By: Bob E. Assigned To: ====================================================================== Project: CMake Issue ID: 15028 Category: CMake Reproducibility: always Severity: minor Priority: high Status: new ====================================================================== Date Submitted: 2014-07-17 06:23 EDT Last Modified: 2014-07-17 06:23 EDT ====================================================================== Summary: CMake build error on QNX Description: cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx:3682: error: 'SA_RESTART' was not declared in this scope cc: /usr/qnx650/host/qnx6/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 make[2]: *** [Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.cxx.o] Error 1 Steps to Reproduce: Make Cmake from sources. Additional Information: QNX not support SA_RESTART signal: qnx6\usr\include\signal.h /* #define SA_RESTART 0x0040 (not supported yet) */ /* Restart the kernel call on signal return */ In ProcessUNIX.c this error was resolved earlier. Patch correct it in SystemInformation.cxx ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-17 06:23 Bob E. New Issue 2014-07-17 06:23 Bob E. File Added: SystemInformation.cxx.QNX.path ====================================================================== From brad.king at kitware.com Thu Jul 17 10:33:28 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Jul 2014 10:33:28 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53C6A065.7010201@gmail.com> References: <53C6A065.7010201@gmail.com> Message-ID: <53C7DEB8.2020304@kitware.com> On 07/16/2014 11:55 AM, Daniele E. Domenichelli wrote: > Please review the topic CMakePackageConfigHelpers_build_tree. > > This patch adds an option BUILD_TREE to configure_package_config_file. The changes look good to me, though I'd appreciate feedback from others who have worked on this module before. In the documentation formatting commit, I see blocks like: > +# .. command:: configure_package_config_file > +# > +# Create a config file for a project:: The definition of the command should be in an indented block so that reST knows it is part of the explicit markup block. Thanks, -Brad From mantis at public.kitware.com Fri Jul 18 15:17:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 18 Jul 2014 15:17:51 -0400 Subject: [cmake-developers] [CMake 0015029]: Segmentation fault handling packages (infinite loop, ?perhaps fills up memory?) Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15029 ====================================================================== Reported By: darlingm Assigned To: ====================================================================== Project: CMake Issue ID: 15029 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-18 15:17 EDT Last Modified: 2014-07-18 15:17 EDT ====================================================================== Summary: Segmentation fault handling packages (infinite loop, ?perhaps fills up memory?) Description: Loading gdb for cmake and the associated dropped core file gives: Program terminated with signal SIGSEGV, Segmentation fault. http://www.cmake.org/Bug/view.php?id=0 0x0000003646e576b0 in _IO_vfscanf_internal () from /lib64/libc.so.6 (gdb) bt http://www.cmake.org/Bug/view.php?id=0 0x0000003646e576b0 in _IO_vfscanf_internal () from /lib64/libc.so.6 http://www.cmake.org/Bug/view.php?id=1 0x0000003646e62eb5 in vsscanf () from /lib64/libc.so.6 http://www.cmake.org/Bug/view.php?id=2 0x0000003646e5dfe8 in sscanf () from /lib64/libc.so.6 http://www.cmake.org/Bug/view.php?id=3 0x00000000007b89d1 in cmFindPackageCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=4 0x00000000007c5b35 in cmCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=5 0x00000000006c80ba in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=6 0x00000000006c901e in cmMakefile::ReadListFile(char const*, char const*, std::string*, bool) () http://www.cmake.org/Bug/view.php?id=7 0x00000000007bce56 in cmFindPackageCommand::ReadListFile(char const*, cmFindPackageCommand::PolicyScopeRule) () http://www.cmake.org/Bug/view.php?id=8 0x00000000007bb531 in cmFindPackageCommand::FindModule(bool&) () http://www.cmake.org/Bug/view.php?id=9 0x00000000007ba1d4 in cmFindPackageCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=10 0x00000000007c5b35 in cmCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=11 0x00000000006c80ba in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=12 0x00000000006c901e in cmMakefile::ReadListFile(char const*, char const*, std::string*, bool) () http://www.cmake.org/Bug/view.php?id=13 0x00000000007bce56 in cmFindPackageCommand::ReadListFile(char const*, cmFindPackageCommand::PolicyScopeRule) () http://www.cmake.org/Bug/view.php?id=14 0x00000000007bb531 in cmFindPackageCommand::FindModule(bool&) () ........... this InitialPass(http://www.cmake.org/Bug/view.php?id=3)->FindModule(http://www.cmake.org/Bug/view.php?id=8) repeats ........... http://www.cmake.org/Bug/view.php?id=31413 0x00000000007ba1d4 in cmFindPackageCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31414 0x00000000007c5b35 in cmCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31415 0x00000000006c80ba in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31416 0x00000000006c901e in cmMakefile::ReadListFile(char const*, char const*, std::string*, bool) () http://www.cmake.org/Bug/view.php?id=31417 0x00000000006b1ac4 in cmLocalGenerator::ReadInputFile() () http://www.cmake.org/Bug/view.php?id=31418 0x00000000006b163e in cmLocalGenerator::Configure() () http://www.cmake.org/Bug/view.php?id=31419 0x00000000008b33c7 in cmLocalUnixMakefileGenerator3::Configure() () http://www.cmake.org/Bug/view.php?id=31420 0x00000000006ccdfa in cmMakefile::ConfigureSubDirectory(cmLocalGenerator*) () http://www.cmake.org/Bug/view.php?id=31421 0x00000000006cd224 in cmMakefile::AddSubDirectory(char const*, char const*, bool, bool, bool) () http://www.cmake.org/Bug/view.php?id=31422 0x000000000079b462 in cmAddSubDirectoryCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31423 0x00000000007c5b35 in cmCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31424 0x00000000006c80ba in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31425 0x00000000006c901e in cmMakefile::ReadListFile(char const*, char const*, std::string*, bool) () http://www.cmake.org/Bug/view.php?id=31426 0x00000000006b1ac4 in cmLocalGenerator::ReadInputFile() () http://www.cmake.org/Bug/view.php?id=31427 0x00000000006b163e in cmLocalGenerator::Configure() () http://www.cmake.org/Bug/view.php?id=31428 0x00000000008b33c7 in cmLocalUnixMakefileGenerator3::Configure() () http://www.cmake.org/Bug/view.php?id=31429 0x000000000087edea in cmGlobalGenerator::Configure() () http://www.cmake.org/Bug/view.php?id=31430 0x000000000089bca2 in cmGlobalUnixMakefileGenerator3::Configure() () http://www.cmake.org/Bug/view.php?id=31431 0x000000000076657e in cmake::ActualConfigure() () http://www.cmake.org/Bug/view.php?id=31432 0x0000000000765ec2 in cmake::Configure() () http://www.cmake.org/Bug/view.php?id=31433 0x0000000000766d5c in cmake::Run(std::vector > const&, bool) () http://www.cmake.org/Bug/view.php?id=31434 0x0000000000681031 in do_cmake(int, char const* const*) () http://www.cmake.org/Bug/view.php?id=31435 0x00000000006808b5 in main () Steps to Reproduce: Extract attached codeTestPackages.tar.gz. mkdir build && cd build && cmake .. Additional Information: I'm attempting to use packages in my build system for the first time. I have no doubt I've done something wrong in the CMakeLists.txt files or FindLIB.cmake file, but I've caused CMake to segmentation fault with a very small reduced case. (Entire project is 41 lines.) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-18 15:17 darlingm New Issue 2014-07-18 15:17 darlingm File Added: codeTestPackages.tar.gz ====================================================================== From daniel at pfeifer-mail.de Sun Jul 20 05:22:21 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Sun, 20 Jul 2014 11:22:21 +0200 Subject: [cmake-developers] LZMA support Message-ID: Hi, In my liblzma branch (https://github.com/purpleKarrot/CMake/commits/liblzma), I did the following: * add the liblzma source from XZ Utils * make it compile with CMake (by adding CMakeLists.txt etc.) * make it compile in VC6 (by porting the source from C99 to C90) * make cmlibarchive use cmliblzma (using cm_lzma.h) * add cpack generators for .7z and .tar.xz This should solve the following issues: http://www.cmake.org/Bug/view.php?id=13072 http://www.cmake.org/Bug/view.php?id=13515 http://www.cmake.org/Bug/view.php?id=14504 http://www.cmake.org/Bug/view.php?id=14519 Please review, comment, pull. Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sun Jul 20 13:16:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 20 Jul 2014 13:16:47 -0400 Subject: [cmake-developers] [CMake 0015030]: Error messages from configure_file do not show the root of the problem Message-ID: <918ee35a25c78920bbcba49715983b70@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15030 ====================================================================== Reported By: Christopher Yeleighton Assigned To: ====================================================================== Project: CMake Issue ID: 15030 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-20 13:16 EDT Last Modified: 2014-07-20 13:16 EDT ====================================================================== Summary: Error messages from configure_file do not show the root of the problem Description: In general, when a system-level exception happens, the exception should be reported via a system facility like perror. I currently get: /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake(1491): configure_file(${kde_cmake_module_dir}/kde4_cmake_uninstall.cmake.in ${CMAKE_BINARY_DIR}/cmake_uninstall.cmake @ONLY ) CMake Error at /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:1491 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): /usr/share/cmake/Modules/FindKDE4.cmake:95 (find_package) CMakeLists.txt:30 (FIND_PACKAGE) This is not enough to identify the cause of the failure. Steps to Reproduce: mkdir -p b/cmake_uninstall.cmake/kde4_cmake_uninstall.cmake.in && cd b && cmake ../libkexiv2-4.13.1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-20 13:16 Christopher YeleightonNew Issue ====================================================================== From daniele.domenichelli at gmail.com Mon Jul 21 04:54:27 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 21 Jul 2014 10:54:27 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53C7DEB8.2020304@kitware.com> References: <53C6A065.7010201@gmail.com> <53C7DEB8.2020304@kitware.com> Message-ID: <53CCD543.5040207@gmail.com> On 17/07/14 16:33, Brad King wrote: >> > +# .. command:: configure_package_config_file >> > +# >> > +# Create a config file for a project:: > The definition of the command should be in an indented block so > that reST knows it is part of the explicit markup block. I indented the whole command block, can you please have a look if that's what you meant? Or is it just the "brief description" of the command that should be indented? Thanks. Daniele From steveire at gmail.com Mon Jul 21 08:23:43 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 21 Jul 2014 14:23:43 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree References: <53C6A065.7010201@gmail.com> Message-ID: Daniele E. Domenichelli wrote: > You can generate valid config files, but in the build tree the relative > paths will always be calculated compared to CMAKE_INSTALL_PREFIX, and > this does not make sense, and also generates config files with very long > lists of "../../../" and difficult to read. Can you give a more-concrete example of what the problem is? Is this relating to a missing target property somehow? Which paths do you need to specify? Thanks, Steve. From brad.king at kitware.com Mon Jul 21 10:17:03 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Jul 2014 10:17:03 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53CCD543.5040207@gmail.com> References: <53C6A065.7010201@gmail.com> <53C7DEB8.2020304@kitware.com> <53CCD543.5040207@gmail.com> Message-ID: <53CD20DF.707@kitware.com> On 07/21/2014 04:54 AM, Daniele E. Domenichelli wrote: > I indented the whole command block, can you please have a look if that's > what you meant? Or is it just the "brief description" of the command > that should be indented? I think just the signature summary is enough. Section headers can be used if we need a higher-level organization. Also please review the style guidelines: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style In particular, self-references should be plain inline literals: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style-referencing-cmake-domain-objects Thanks, -Brad From nilsgladitz at gmail.com Mon Jul 21 10:38:39 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 21 Jul 2014 16:38:39 +0200 Subject: [cmake-developers] CMake 3.0 COMPILE_DEFINITIONS_ Documentation Message-ID: <53CD25EF.5020708@gmail.com> With CMP0043 the COMPILE_DEFINITIONS_ properties are ignored. This currently doesn't seem to be reflected in the documentation of the properties themselves. Should the documentation for those properties be deleted (I think I would personally prefer that) or extended to show that they may not have any effect when requiring 3.0 (the policy is set to NEW)? Nils From brad.king at kitware.com Mon Jul 21 10:55:17 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Jul 2014 10:55:17 -0400 Subject: [cmake-developers] CMake 3.0 COMPILE_DEFINITIONS_ Documentation In-Reply-To: <53CD25EF.5020708@gmail.com> References: <53CD25EF.5020708@gmail.com> Message-ID: <53CD29D5.6050703@kitware.com> On 07/21/2014 10:38 AM, Nils Gladitz wrote: > Should the documentation for those properties be deleted (I think I > would personally prefer that) or extended to show that they may not have > any effect when requiring 3.0 (the policy is set to NEW)? The latter, please. See the intro paragraph in export_library_dependencies for example: Help/command/export_library_dependencies.rst Thanks, -Brad From daniele.domenichelli at gmail.com Mon Jul 21 11:12:57 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 21 Jul 2014 17:12:57 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> Message-ID: <53CD2DF9.70601@gmail.com> On 21/07/14 14:23, Stephen Kelly wrote: > Can you give a more-concrete example of what the problem is? I have a project that is similar to this small example: --- CMakeLists.txt cmake_minimum_required(VERSION 2.8.12) project(FOO NONE) set(FOO_VERSION 0.0.1) include(${CMAKE_CURRENT_LIST_DIR}/CMakePackageConfigHelpers.cmake) set(FOO_INSTALL_CMAKE_DIR "share/FOO/cmake") set(FOO_BUILD_ABSOLUTE_DIR "${CMAKE_BINARY_DIR}/share/FOO/absolute") set(FOO_INSTALL_ABSOLUTE_DIR "${CMAKE_INSTALL_PREFIX}/share/FOO/absolute") set(FOO_BUILD_RELATIVE_DIR "share/FOO/relative") set(FOO_INSTALL_RELATIVE_DIR "share/FOO/relative") #--------- BUILD TREE set(FOO_ABSOLUTE_DIR ${FOO_BUILD_ABSOLUTE_DIR}) set(FOO_RELATIVE_DIR ${FOO_BUILD_RELATIVE_DIR}) # FOOConfig.cmake (build tree) configure_package_config_file(FOOConfig.cmake.in "FOOConfig.cmake" INSTALL_DESTINATION "${CMAKE_BINARY_DIR}" PATH_VARS FOO_ABSOLUTE_DIR FOO_RELATIVE_DIR NO_CHECK_REQUIRED_COMPONENTS_MACRO BUILD_TREE) #--------- INSTALLED set(FOO_ABSOLUTE_DIR ${FOO_INSTALL_ABSOLUTE_DIR}) set(FOO_RELATIVE_DIR ${FOO_INSTALL_RELATIVE_DIR}) # FOOConfig.cmake (installed) configure_package_config_file(FOOConfig.cmake.in "FOOConfigInstall.cmake" INSTALL_DESTINATION "${FOO_INSTALL_CMAKE_DIR}" PATH_VARS FOO_ABSOLUTE_DIR FOO_RELATIVE_DIR NO_CHECK_REQUIRED_COMPONENTS_MACRO) install(FILES ${CMAKE_BINARY_DIR}/${CMAKE_FILES_DIRECTORY}/FOOConfigInstall.cmake DESTINATION ${FOO_INSTALL_CMAKE_DIR} RENAME FOOConfig.cmake) --- FOOConfig.cmake.in set(FOO_VERSION @FOO_VERSION@) @PACKAGE_INIT@ set_and_check(FOO_ABSOLUTE_DIR "@PACKAGE_FOO_ABSOLUTE_DIR@") set_and_check(FOO_RELATIVE_DIR "@PACKAGE_FOO_RELATIVE_DIR@") The project is supposed to work both from build tree (using export(TARGETS)) and from the install tree (using install(EXPORT)). The file FOOConfigInstall.cmake is perfect and can be relocated as expected. The file FOOConfig.cmake for the build tree contains --- [...] get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../usr/local" ABSOLUTE) [...] set_and_check(FOO_ABSOLUTE_DIR "/share/FOO/absolute") set_and_check(FOO_RELATIVE_DIR "${PACKAGE_PREFIX_DIR}/share/FOO/relative") --- in PACKAGE_PREFIX_DIR, obviously, the length list of "/.." depends on the folder where the package is built. "/usr/local" is the prefix and it makes no sense in the file for the build directory. The path passed using a variable containing an _absolute path_ is _correct_, but it uses the absolute path to the build directory. The path passed using a variable containing a _relative path_ is _wrong_ and it contains a path relative to the install directory. If the package was not installed this path is invalid. This means that all the paths should be passed as absolute paths or the generated file will be invalid. With my patch applied and passing "BUILD_TREE" to the configure_package_config_file call, the generated file becomes: --- [...] get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/" ABSOLUTE) [...] set_and_check(FOO_ABSOLUTE_DIR "${PACKAGE_PREFIX_DIR}/share/FOO/absolute") set_and_check(FOO_RELATIVE_DIR "${PACKAGE_PREFIX_DIR}/share/FOO/relative") --- This removes all the absolute paths from the file (This is not necessary for using the package in the build tree, since I believe that it's not going to be relocated, but I still think it is a good thing), and very important, it allows you to pass relative paths as PATH_VARS and get the same behaviour in both cases. Cheers, Daniele From daniele.domenichelli at gmail.com Mon Jul 21 11:38:31 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 21 Jul 2014 17:38:31 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53CD20DF.707@kitware.com> References: <53C6A065.7010201@gmail.com> <53C7DEB8.2020304@kitware.com> <53CCD543.5040207@gmail.com> <53CD20DF.707@kitware.com> Message-ID: <53CD33F7.8040206@gmail.com> On 21/07/14 16:17, Brad King wrote: > On 07/21/2014 04:54 AM, Daniele E. Domenichelli wrote: >> I indented the whole command block, can you please have a look if that's >> what you meant? Or is it just the "brief description" of the command >> that should be indented? > > I think just the signature summary is enough. Section headers > can be used if we need a higher-level organization. Done. > Also please review the style guidelines: > > http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style > > In particular, self-references should be plain inline literals: Done. Cheers, Daniele From brad.king at kitware.com Mon Jul 21 13:23:38 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Jul 2014 13:23:38 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53CD33F7.8040206@gmail.com> References: <53C6A065.7010201@gmail.com> <53C7DEB8.2020304@kitware.com> <53CCD543.5040207@gmail.com> <53CD20DF.707@kitware.com> <53CD33F7.8040206@gmail.com> Message-ID: <53CD4C9A.8070009@kitware.com> On 07/21/2014 11:38 AM, Daniele E. Domenichelli wrote: > Done. Thanks. Please squash in something like the patch below. -Brad diff --git a/Modules/CMakePackageConfigHelpers.cmake b/Modules/CMakePackageConfigHelpers.cmake index 24b5b74..54ceb54 100644 --- a/Modules/CMakePackageConfigHelpers.cmake +++ b/Modules/CMakePackageConfigHelpers.cmake @@ -8,7 +8,8 @@ # Adds the :command:`configure_package_config_file()` and # :command:`write_basic_package_version_file()` commands. # -# +# Generating a Package Configuration File +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # # .. command:: configure_package_config_file # @@ -104,10 +105,10 @@ # When using the ``NO_CHECK_REQUIRED_COMPONENTS_MACRO`` option, this macro is # not generated into the ``FooConfig.cmake`` file. # -# For an example see below the documentation for -# :command:`write_basic_package_version_file()`. -# +# See the `Example Generating Package Files`_ below. # +# Generating a Package Version File +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # # .. command:: write_basic_package_version_file # @@ -154,6 +155,8 @@ # :command:`configure_file()` on them yourself, but they can be used as starting # point to create more sophisticted custom ``ConfigVersion.cmake`` files. # +# Example Generating Package Files +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # # Example using both :command:`configure_package_config_file` and # ``write_basic_package_version_file()``: From steveire at gmail.com Mon Jul 21 15:04:32 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 21 Jul 2014 21:04:32 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> Message-ID: Daniele E. Domenichelli wrote: > On 21/07/14 14:23, Stephen Kelly wrote: >> Can you give a more-concrete example of what the problem is? > > The project is supposed to work both from build tree (using > export(TARGETS)) and from the install tree (using install(EXPORT)). Your example is too abstract. What is the meaning of the paths? What is the problem which can be solved only with CMakePackageConfigHelpers and can't be solved (currently) another way? Is there a first-class feature CMake could learn to make this stuff easier? Here is why I am asking: The documentation at http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages does not use CMakePackageConfigHelpers because for 'modern' packages, paths such as include directories are encoded into imported targets. Then the complete FooConfig.cmake file is: include(CMakeFindDependencyMacro) find_dependency(Stats 2.6.4) include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake") include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake") and it works as both a build-location package and an install-location package, without using CMakePackageConfigHelpers. That is assuming the ClimbingStatsMacros.cmake can be generated in or copied to the build location. That is an easy assumption to make, because it is easy to do such generation or copying. So, I am trying to find out: When using 'modern cmake', is there a remaining need for CMakePackageConfigHelpers? Thanks, Steve. From brad.king at kitware.com Mon Jul 21 16:07:08 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Jul 2014 16:07:08 -0400 Subject: [cmake-developers] LZMA support In-Reply-To: References: Message-ID: <53CD72EC.3010608@kitware.com> On 07/20/2014 05:22 AM, Daniel Pfeifer wrote: > * add the liblzma source from XZ Utils > * make it compile with CMake (by adding CMakeLists.txt etc.) > * make it compile in VC6 (by porting the source from C99 to C90) > * make cmlibarchive use cmliblzma (using cm_lzma.h) > * add cpack generators for .7z and .tar.xz Wonderful, thanks! I restructured the topic a bit to make it easier to update the liblzma version in the future. I also added references to the issue numbers to the commit messages. I've temporarily published an 'add-liblzma' branch to our topic stage at . After some further manual testing I will merge it to 'next'. Thanks, -Brad From daniele.domenichelli at gmail.com Tue Jul 22 04:28:19 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 22 Jul 2014 10:28:19 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> Message-ID: <53CE20A3.7090502@gmail.com> On 21/07/14 21:04, Stephen Kelly wrote: >>> Can you give a more-concrete example of what the problem is? >> >> The project is supposed to work both from build tree (using >> export(TARGETS)) and from the install tree (using install(EXPORT)). > > Your example is too abstract. What is the meaning of the paths? I have at least a couple of different cases where I would like to be able to do this. The first case is a folder that is appended to CMAKE_MODULE_PATH, and that containing CMake files that can optionally be included by projects using this package. The second case is a path to a folder containing "data" files installed by the library (that usually go in /share/), and that other projects should be able to use. In both cases I need to pass a path to the project, not to include a file. The files that the projects need to use are not in ${CMAKE_CURRENT_LIST_DIR} (relative to the config files) and the relative path is different, since for the build tree the cmake config files are in ${CMAKE_BINARY_DIR} (as expected for example by the package registry), while for the install tree the config files are in some of the directory searched by find_package (depending on the OS). > What is the problem which can be solved only with CMakePackageConfigHelpers > and can't be solved (currently) another way? Is there a first-class feature > CMake could learn to make this stuff easier? CMakePackageConfigHelpers _can_ already solve this problem, but you have to pass _absolute_ paths to configure_package_config_file, and that is different from everywhere else in CMake. > The documentation at > > http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages > > does not use CMakePackageConfigHelpers because for 'modern' packages, paths > such as include directories are encoded into imported targets. Does this mean that configure_package_config_file is going to be deprecated and should not be used for new packages? If that's the case, maybe the documentation should mention it. Anyway, even when creating targets in a modern way, I still believe that it is a very useful module when you need to pass paths that cannot be encoded into imported targets. Cheers, Daniele From steveire at gmail.com Tue Jul 22 04:53:03 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Jul 2014 10:53:03 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> Message-ID: Daniele E. Domenichelli wrote: > The first case is a folder that is appended to CMAKE_MODULE_PATH, and > that containing CMake files that can optionally be included by projects > using this package. I still find this an odd user interface. You provide a variable FOO_MODULE_PATH or something and document that users should add that to their CMAKE_MODULE_PATH after invoking find_package? Then what? The user needs to know which files they can include(). Do you leave the user to run ls to find out what's there or do you document them for your package? Instead of all that, you could provide and document variables (ala QT_USE_FILE) which the users pass directly to include(). I would find that a better user interface and less fragile. > The second case is a path to a folder containing "data" files installed > by the library (that usually go in /share/), and that > other projects should be able to use. I guess if you have a particular structure in the source tree, you might not want to symlink/replicate it to the build tree. That arises for qml files for example. However, usually I have chosen the symlink/copy route. As you can see here, the CMakePackageConfigHelpers is only needed for 'backward compatibility' provision of the INCLUDE_DIRS variable, which wouldn't be added in new code: https://github.com/KDAB/KDSoap/blob/master/CMakeLists.txt#L92 https://github.com/KDAB/KDSoap/blob/master/KDSoapConfig.cmake.in > and the > relative path is different, since for the build tree the cmake config > files are in ${CMAKE_BINARY_DIR} (as expected for example by the package > registry) Some other places you can have the cmake config file for the build tree: ${CMAKE_BINARY_DIR}/cmake ${CMAKE_BINARY_DIR}/ ${CMAKE_BINARY_DIR}//cmake ${CMAKE_BINARY_DIR}/cmake/ ${CMAKE_BINARY_DIR}/lib/cmake/ ${CMAKE_BINARY_DIR}/lib/cmake Depending on whether you're going for 'cleanliness' or similarity to the installed layout etc. >> The documentation at >> >> http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages >> >> does not use CMakePackageConfigHelpers because for 'modern' packages, >> paths such as include directories are encoded into imported targets. > > Does this mean that configure_package_config_file is going to be > deprecated and should not be used for new packages? No, it does not mean that. It means I was trying to find out why you need it. My current understanding is that the things it does can also be done other ways (and better ways I think as with the variables for include() above). > I still believe that it is a very useful module > when you need to pass paths that cannot be encoded into imported targets. I was trying to find out if that points us to a gap in the first-class features provided by cmake. Thanks, Steve. From daniele.domenichelli at gmail.com Tue Jul 22 06:48:44 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 22 Jul 2014 12:48:44 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> Message-ID: <53CE418C.9090507@gmail.com> On 22/07/14 10:53, Stephen Kelly wrote: > Daniele E. Domenichelli wrote: > >> The first case is a folder that is appended to CMAKE_MODULE_PATH, and >> that containing CMake files that can optionally be included by projects >> using this package. > > I still find this an odd user interface. > > You provide a variable FOO_MODULE_PATH or something and document that users > should add that to their CMAKE_MODULE_PATH after invoking find_package? Then > what? The user needs to know which files they can include(). Do you leave > the user to run ls to find out what's there or do you document them for your > package? Not exactly, the folder is appended to CMAKE_MODULE_PATH in the config file... The user can include one of the modules in the folder, but he does not need to do it, since the modules enable some extra feature that the user might not want. He just needs to know the name of the module, so it's not different from knowing the name of a variable... > Instead of all that, you could provide and document variables (ala > QT_USE_FILE) which the users pass directly to include(). I would find that a > better user interface and less fragile. Sorry, I'm still not convinced by this... The "QT_USE_FILE" variable will have the same issue with relative paths and will have to be passed as absolute path to configure_package_config_file(), or am I missing something? >> The second case is a path to a folder containing "data" files installed >> by the library (that usually go in /share/), and that >> other projects should be able to use. > > I guess if you have a particular structure in the source tree, you might not > want to symlink/replicate it to the build tree. That arises for qml files > for example. However, usually I have chosen the symlink/copy route. Symlinks are not really an option, because it works on unix only, and we need to support windows as well. Also I think that in one of our cases copy might be not the best options, since some of these files are large binary blobs, and therefore a copy is quite expensive, but I'll have to check if that is necessary... Another issue with copying the file is that the file is copied at CMake time, not a build time, and cmake is not triggered and therefore the copy is not performed at build time if the file is modified and the user just runs make (or "build" for visual studio and other IDEs). By the way, is there a reason why file(COPY) does not have an option to copy the file only if the file(s) is(are) different. I had a few cases where I had to use "execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different" because file(COPY) would trigger an unnecessary rebuild. Since you were asking if CMake misses some important feature, I believe that a very useful feature to have would be to be able to have an option for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the install tree in the binary directory, but at build time, and only if the destination file is missing or is different from the source. Or maybe, using the export(FILES/PROGRAMS/DIRECTORY), like for the new export(EXPORT) command... > As you can see here, the CMakePackageConfigHelpers is only needed for > 'backward compatibility' provision of the INCLUDE_DIRS variable, which > wouldn't be added in new code: Backwards compatibility is, in my opinion, another valid use case... Of course you could get the INCLUDE_DIRS using get_property inside the config file, but there is still some case uncovered, i.e. if you don't have libraries in your package (for example for a header only library). >> and the >> relative path is different, since for the build tree the cmake config >> files are in ${CMAKE_BINARY_DIR} (as expected for example by the package >> registry) > > Some other places you can have the cmake config file for the build tree: > > ${CMAKE_BINARY_DIR}/cmake > ${CMAKE_BINARY_DIR}/ > ${CMAKE_BINARY_DIR}//cmake > ${CMAKE_BINARY_DIR}/cmake/ > ${CMAKE_BINARY_DIR}/lib/cmake/ > ${CMAKE_BINARY_DIR}/lib/cmake > > Depending on whether you're going for 'cleanliness' or similarity to the > installed layout etc. I wasn't aware of this, thanks for pointing it out... Maybe this needs some more documentation... I couldn't find anything about in export[1] and cmake-packages.7[2], and find_package[3] says: CMake constructs a set of possible installation prefixes for the package. Under each prefix several directories are searched for a configuration file. The build directory is unlikely to be constructed as an "installation prefix", therefore I thought that these paths were not checked for a build tree. Does this mean that if I set the _DIR environment variable to the CMAKE_BINARY_DIR of my package, CMake will look into these folders as well? This is what our users are used to do and it will not be easy to change their behaviour, also because this is quite useful for testing different builds. [1]http://www.cmake.org/cmake/help/git-master/command/export.html [2]http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html [3]http://www.cmake.org/cmake/help/git-master/command/find_package.htm >> Does this mean that configure_package_config_file is going to be >> deprecated and should not be used for new packages? > > No, it does not mean that. It means I was trying to find out why you need > it. My current understanding is that the things it does can also be done > other ways (and better ways I think as with the variables for include() > above). Anyway, conceptually one should recreate the install tree inside the build tree, and then generate just one config file using configure_package_config_file and use it both for build and install, is this correct? Cheers, Daniele From steveire at gmail.com Tue Jul 22 07:44:45 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Jul 2014 13:44:45 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> Message-ID: Daniele E. Domenichelli wrote: > Sorry, I'm still not convinced by this... The "QT_USE_FILE" variable > will have the same issue with relative paths and will have to be passed > as absolute path to configure_package_config_file(), or am I missing > something? Are you missing the assumption that its location is constant relative to the config file? That makes ${CMAKE_CURRENT_LIST_DIR} appropriate. >>> The second case is a path to a folder containing "data" files installed >>> by the library (that usually go in /share/), and that >>> other projects should be able to use. >> >> I guess if you have a particular structure in the source tree, you might >> not want to symlink/replicate it to the build tree. That arises for qml >> files for example. However, usually I have chosen the symlink/copy route. > > Symlinks are not really an option I wrote 'symlink/replicate'. > Another issue with copying the file is that the file is copied at CMake > time, not a build time, and cmake is not triggered and therefore the > copy is not performed at build time if the file is modified and the user > just runs make (or "build" for visual studio and other IDEs). CMake re-runs (as of a recent cmake version) if the input to configure_file changes. > > > By the way, is there a reason why file(COPY) does not have an option to > copy the file only if the file(s) is(are) different. configure_file(COPY_ONLY) does that. file(COPY_IF_DIFFERENT) would just do the same thing but would be more discoverable and might be a good idea. > Since you were asking if CMake misses some important feature, I believe > that a very useful feature to have would be to be able to have an option > for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the > install tree in the binary directory Yes, seems like something worth investigating. > , but at build time, and only if the > destination file is missing or is different from the source. > > Or maybe, using the export(FILES/PROGRAMS/DIRECTORY), like for the new > export(EXPORT) command... It might be worth filing a bug to record the full idea. >>> and the >>> relative path is different, since for the build tree the cmake config >>> files are in ${CMAKE_BINARY_DIR} (as expected for example by the package >>> registry) >> >> Some other places you can have the cmake config file for the build tree: >> >> ${CMAKE_BINARY_DIR}/cmake >> ${CMAKE_BINARY_DIR}/ >> ${CMAKE_BINARY_DIR}//cmake >> ${CMAKE_BINARY_DIR}/cmake/ >> ${CMAKE_BINARY_DIR}/lib/cmake/ >> ${CMAKE_BINARY_DIR}/lib/cmake >> >> Depending on whether you're going for 'cleanliness' or similarity to the >> installed layout etc. > > I wasn't aware of this, thanks for pointing it out... Maybe this needs > some more documentation... Actually, are you talking about export(PACKAGE)? I don't really know anything about that. > The build directory is unlikely to be constructed as an "installation > prefix", therefore I thought that these paths were not checked for a > build tree. Setting the CMAKE_PREFIX_PATH to contain the build dir would do it. > Does this mean that if I set the _DIR environment variable to > the CMAKE_BINARY_DIR of my package, CMake will look into these folders > as well? No, I don't think so. You would have to set it to the exact dir afaik. > Anyway, conceptually one should recreate the install tree inside the > build tree, and then generate just one config file using > configure_package_config_file and use it both for build and install, is > this correct? In my preference, there should be no need to generate the config file, except to copy it from the source tree to the build tree. Then the content of that file is the same, yes. My preference. Thanks, Steve. From mantis at public.kitware.com Tue Jul 22 08:36:46 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 22 Jul 2014 08:36:46 -0400 Subject: [cmake-developers] [CMake 0015031]: visual studio 2012 generator ampersand escaping Message-ID: <6d2773a4cc588f6878f378df6db4d336@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15031 ====================================================================== Reported By: mscott Assigned To: ====================================================================== Project: CMake Issue ID: 15031 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-22 08:36 EDT Last Modified: 2014-07-22 08:36 EDT ====================================================================== Summary: visual studio 2012 generator ampersand escaping Description: The Visual Studio 2012 generator does not seem to escape ampersands in source file paths correctly, resulting in the generated project XML containing errors and being un-openable with Visual Studio. I tested the same config with the Visual Studio 2008 generator and did not encounter the same issue. When looking at the generated XML, in VS2008 the '&' character is replaced by '&'. Steps to Reproduce: Create a target whose sources includes a file path with the '&' character, then run cmake specifying VS2012 as the generator, open the created solution and notice that it cannot open the target project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-22 08:36 mscott New Issue ====================================================================== From mantis at public.kitware.com Tue Jul 22 09:43:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 22 Jul 2014 09:43:05 -0400 Subject: [cmake-developers] [CMake 0015032]: Binary and source path not handled properly if path does not contain a sub-directory but "drive letter" only Message-ID: <2ece6cb8bb48d91eef874dede3f8b970@www.itk.org> The following issue has been SUBMITTED. ====================================================================== http://www.itk.org/Bug/view.php?id=15032 ====================================================================== Reported By: Gerald Hofmann Assigned To: ====================================================================== Project: CMake Issue ID: 15032 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-22 09:43 EDT Last Modified: 2014-07-22 09:43 EDT ====================================================================== Summary: Binary and source path not handled properly if path does not contain a sub-directory but "drive letter" only Description: If building in a binary directory that is on root level of a "drive letter" the binary path name is not handled properly. Src directory handling also affected, but workaround available. Steps to Reproduce: - Open terminal and cd to a root level build directory (e.g. network share mapped to a server based platform specific build dir) - Issue "cmake-gui s:" (assuming s: points to the src dir) - Find binary dir preset with training backslash. src dir has no training backslash. - Re-select src directory from "browse source" and find the training backslash added First error occourence: ======================= - Try to configure for any generator. CMake Error at s://CMakeLists.txt:42 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory "s:/foo" is not a subdirectory of "s:/". => Looks strange. Error message is not correct. All dirs are in place. - Apply work-around by removing training backslash in source directory (keep it for the bin directory) - Re-configure -> works Extended error occourence: ========================== - Removing the backslash from src dir seemingly works. Run generate. - Find Makefile not working - Makefiles containing wrong build targets # The main all target all: cmake_check_build_system $(CMAKE_COMMAND) -E cmake_progress_start U:\CMakeFiles U:\CMakeFiles\progress.marks $(MAKE) -f CMakeFiles\Makefile2 /nologo -$(MAKEFLAGS) U:\\all $(CMAKE_COMMAND) -E cmake_progress_start U:\CMakeFiles 0 .PHONY : all => "all" target is prefixed by the binary dir drive letter. Makefile is not usable. Manually removing the "U:\\" prefix from the target name will fix the Makefile. All other entries seem to be correct. Additional Information: Probably introduced in late 2.8.x releases Worked in 2.8.2, found during update to 2.8.12 / 3.0.0 Workaround: Always use subdirectory for the binary dir. Make sure there is no training slash in src and bin directory entry. Probable explanation: Path names are not split up properly. cmake seems to expext *no training slash* for src/bin path names (GUI or cl). If selected dir is on root level, internal splitting fails, probably because the parser is looking for a backslash to separate drive letter and relative bin path components. Adding a trailing slash will cure configure stage processing, but bin directory handling is broken by this "enforced" parsing. *** Windoze console path names == root of all evil.... *** ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-22 09:43 Gerald Hofmann New Issue ====================================================================== From daniele.domenichelli at gmail.com Tue Jul 22 10:42:57 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 22 Jul 2014 16:42:57 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> Message-ID: <53CE7871.1080605@gmail.com> On 22/07/14 13:44, Stephen Kelly wrote: >> Does this mean that if I set the _DIR environment variable to >> the CMAKE_BINARY_DIR of my package, CMake will look into these folders >> as well? > > No, I don't think so. You would have to set it to the exact dir afaik. Actually I tested it, and CMake actually finds the package both if the package is using export(PACKAGE) or if the user sets the _DIR or the CMAKE_PREFIX_PATH environment variables, but it does not work when passing the _DIR cmake variable (i.e. cmake -D_DIR=), that needs to be the correct path to the config files... Unfortunately that's part of the workflow commonly used here to test different builds, and I don't think that I'll be allowed to change the workflow of a quite large team in this way... It is more likely that I'll have to live with "old-style" config files in the main CMAKE_BINARY_DIR, with different relative paths compared to the one installed (or with absolute paths). Also until now I always had the impression that the config file for the build tree should be in the CMAKE_BINARY_DIR folder, see for example http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file where it creates the config file for the build tree in this way: configure_file(FooBarConfig.cmake.in "${PROJECT_BINARY_DIR}/FooBarConfig.cmake" @ONLY) The ultimate solution that I can think about is to have a config file and a version file in CMAKE_BINARY_DIR that just include the real config and version files, but that sounds a little bit weird to me, even though I tested it and it works as expected... So I could have a config file (either configured, or static) in the correct relative folder, and generate the fake ones in this way: file(WRITE "${CMAKE_BINARY_DIR}/FOOConfig.cmake" "include(\${CMAKE_CURRENT_LIST_DIR}//FOOConfig.cmake)\n") file(WRITE "${CMAKE_BINARY_DIR}/FOOConfigVersion.cmake" "include(${CMAKE_CURRENT_LIST_DIR}//FOOConfigVersion.cmake)\n") What do you think, would this be an acceptable solution in a "modern CMake" style? Cheers, Daniele From konstantin at podsvirov.pro Wed Jul 23 04:38:38 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 23 Jul 2014 12:38:38 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <3923551405583879@web23m.yandex.ru> References: <3923551405583879@web23m.yandex.ru> Message-ID: <3104551406104718@web10h.yandex.ru> Update as of July 23, available! 17.07.2014, 12:04, "Konstantin Podsvirov" : > Hello fans of CMake and Windows! > > I want to present the online installer CMake for 32-bit and 64-bit versions of Windows. > > And immediately the binaries: > > http://ifw.podsvirov.pro/cmake/cmake-master-windows-32bit-online.exe > > http://ifw.podsvirov.pro/cmake/cmake-master-windows-64bit-online.exe > > The installer will install CMake from an online repository and create shortcuts in the start menu. > The composition of the labels is the same as that of the NSIS installer. If you have already used these installers then just click "Start Menu -> CMake -> Uninstall" , then click "Update components" and click "Next" ... Added new features CPack IFW generator. Now you can specify one or more license file for a group of components or for a particular component. As before the source code is available here: http://git.podsvirov.pro/?p=cmake/cpackifwgenerator.git;a=summary HTML version of the documentation is available here: http://ifw.podsvirov.pro/cmake/doc/cmake-3.0/html Note the documentation of the module CPackIFW: http://ifw.podsvirov.pro/cmake/doc/cmake-3.0/html/module/CPackIFW.html Download the source code and collect it yourself or use installers for Windows or Linux http://ifw.podsvirov.pro/cmake). If there is a need to create an online installers with the possibility of renewal for Linux, then contact me and I will make them. Encouraged to read and test the code and share their comments. My purpose here to CPack IFW generator became a part of the project CMake!!! (Sorry for my English, I use a translator) Regards, Konstantin Podsvirov From mantis at public.kitware.com Wed Jul 23 04:56:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 23 Jul 2014 04:56:11 -0400 Subject: [cmake-developers] [CMake 0015034]: target_link_libraries omits some dependencies Message-ID: <59e64381a8ad99d9aeae1040c179b861@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15034 ====================================================================== Reported By: Glenn Coombs Assigned To: ====================================================================== Project: CMake Issue ID: 15034 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-23 04:56 EDT Last Modified: 2014-07-23 04:56 EDT ====================================================================== Summary: target_link_libraries omits some dependencies Description: The target_link_libraries command fails to add the specified linker option under some conditions. Steps to Reproduce: Save the example CMakeLists.txt file attached to this ticket and then run these commands: mkdir build cd build cmake .. make VERBOSE=yes The link command generated for my_lib_shared is as follows: gcc -fPIC -shared -Wl,-soname,libmy_lib_shared.so -o libmy_lib_shared.so CMakeFiles/my_lib_shared.dir/my_lib_shared.c.o libsome_lib_1.a -Wl,-whole-archive libsome_lib_3.a -Wl,-no-whole-archive libsome_lib_2.a -Wl,-whole-archive libsome_lib_4.a libsome_lib_5.a which is incorrect. The lib4 line should include a -no-whole-archive option on the end. If you comment line 25 and uncomment line 26 in the CMakeLists.txt then the correct output is generated: gcc -fPIC -shared -Wl,-soname,libmy_lib_shared.so -o libmy_lib_shared.so CMakeFiles/my_lib_shared.dir/my_lib_shared.c.o libsome_lib_1.a -Wl,-whole-archive libsome_lib_3.a -Wl,-no-whole-archive libsome_lib_2.a -Wl,-whole-archive libsome_lib_4.a -Wl,-Qy,-no-whole-archive libsome_lib_5.a For some reason the -no-whole-archive is omitted unless another option precedes it. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-23 04:56 Glenn Coombs New Issue 2014-07-23 04:56 Glenn Coombs File Added: CMakeLists.txt ====================================================================== From nick at astrant.net Wed Jul 23 08:00:12 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 23 Jul 2014 14:00:12 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. Message-ID: Hey guys, With this https://github.com/NickNick/cmake-dependency-waiting code here, why do b wait for a and c wait for b to be build? The object files could all be build in parallel right? Not doing it is making my distcc-cluster less and less useful the more nodes I add. Is there a way to fix or work around this? Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Wed Jul 23 08:16:42 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 23 Jul 2014 08:16:42 -0400 (EDT) Subject: [cmake-developers] LZMA support Message-ID: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> Wow! Fantastic! Thanks to Daniel, great work on this contribution... This is a ton of tedious work, but it will be very useful. Thank you *very much*. Two minor comments -- in the commit at the tip of this topic: http://public.kitware.com/gitweb?p=stage/cmake.git;a=commitdiff;h=5201fb2e62fb06609b02c83278da6546561a9e9f I think the extensions should be alphabetized, and they should also include "7z" so folks can use the typically smaller 7z files with ExternalProject as well. Would you like me to amend and update the topic? Or would you mind doing the minor edit for that? BTW, I just submitted an Experimental dashboard for this topic using ninja and the VS2012 compiler on Windows 8.1, and it was all green: http://open.cdash.org/buildSummary.php?buildid=3420600 Thanks, David C. From brad.king at kitware.com Wed Jul 23 08:36:53 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 08:36:53 -0400 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: Message-ID: <53CFAC65.5000000@kitware.com> On 07/23/2014 08:00 AM, Nick Overdijk wrote: > With this https://github.com/NickNick/cmake-dependency-waiting code here, why do b wait for a and c wait for b to be build? The object files could all be build in parallel right? Not doing it is making my distcc-cluster less and less useful the more nodes I add. Is there a way to fix or work around > this? See here: http://www.cmake.org/Bug/view.php?id=14726#c35021 http://www.cmake.org/Bug/view.php?id=14726#c35023 -Brad From nick at astrant.net Wed Jul 23 08:58:07 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 23 Jul 2014 14:58:07 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: <53CFAC65.5000000@kitware.com> References: <53CFAC65.5000000@kitware.com> Message-ID: Thanks for the quick reply, but what if c needs b and b needs a? Adding "INTERFACE" will then break the build of course, right, since b isn't really linked to a... Or am I mistaken? On Wed, Jul 23, 2014 at 2:36 PM, Brad King wrote: > On 07/23/2014 08:00 AM, Nick Overdijk wrote: > > With this https://github.com/NickNick/cmake-dependency-waiting code > here, why do b wait for a and c wait for b to be build? The object files > could all be build in parallel right? Not doing it is making my > distcc-cluster less and less useful the more nodes I add. Is there a way to > fix or work around > > this? > > See here: > > http://www.cmake.org/Bug/view.php?id=14726#c35021 > http://www.cmake.org/Bug/view.php?id=14726#c35023 > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at astrant.net Wed Jul 23 09:07:19 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 23 Jul 2014 15:07:19 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> Message-ID: Oh wait, since a is in the interface of b, b will always be accompanied by a, even though it's not a dependency. Is that how it works? On Wed, Jul 23, 2014 at 2:58 PM, Nick Overdijk wrote: > Thanks for the quick reply, but what if c needs b and b needs a? Adding > "INTERFACE" will then break the build of course, right, since b isn't > really linked to a... Or am I mistaken? > > > On Wed, Jul 23, 2014 at 2:36 PM, Brad King wrote: > >> On 07/23/2014 08:00 AM, Nick Overdijk wrote: >> > With this https://github.com/NickNick/cmake-dependency-waiting code >> here, why do b wait for a and c wait for b to be build? The object files >> could all be build in parallel right? Not doing it is making my >> distcc-cluster less and less useful the more nodes I add. Is there a way to >> fix or work around >> > this? >> >> See here: >> >> http://www.cmake.org/Bug/view.php?id=14726#c35021 >> http://www.cmake.org/Bug/view.php?id=14726#c35023 >> >> -Brad >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 23 09:14:20 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 09:14:20 -0400 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> Message-ID: <53CFB52C.3090500@kitware.com> On 07/23/2014 09:07 AM, Nick Overdijk wrote: > Oh wait, since a is in the interface of b, b will always be > accompanied by a, even though it's not a dependency. > Is that how it works? Yes. If B is a static library then it does not really link so its dependencies are only ever used transitively when something else links to B. If B really links as a shared library though then see the following. If target B links to target A then CMake will not compile objects in B until A is done. As explained in my previous link this is because we allow A to contain custom commands that generate headers used by B. The VS and Xcode IDE build systems offer only this granularity since they organize compilation and linking rules of a single target together. The Makefile generator was designed this way too. Only the Ninja generator has a chance of increasing parallelism if the extra ordering dependencies were dropped. We've thought about how to do extra analysis to determine when there is no such custom command to drop them but have not implemented anything yet. You might be able to use OBJECT libraries to increase parallelism for all generators and with no changes to CMake: set(CMAKE_POSITION_INDEPENDENT_CODE ON) add_library(Aobjs OBJECT a1.c a2.c) add_library(Bobjs OBJECT b1.c b2.c) add_library(Cobjs OBJECT c1.c c2.c) set(dummy_c dummy.c) # needed for VS 6 and Xcode add_library(A SHARED $ ${dummy_c}) add_library(B SHARED $ ${dummy_c}) add_library(C SHARED $ ${dummy_c}) target_link_libraries(B PUBLIC A) target_link_libraries(C PUBLIC B) This way the object compilations will be completely independent of one another and of the linking and ordering dependencies. -Brad From nick at astrant.net Wed Jul 23 09:19:05 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 23 Jul 2014 15:19:05 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: <53CFB52C.3090500@kitware.com> References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> Message-ID: Crystal clear. Another layer of indirection eh? I'll see if I can work with that... Thanks for the explanation. On Wed, Jul 23, 2014 at 3:14 PM, Brad King wrote: > On 07/23/2014 09:07 AM, Nick Overdijk wrote: > > Oh wait, since a is in the interface of b, b will always be > > accompanied by a, even though it's not a dependency. > > Is that how it works? > > Yes. If B is a static library then it does not really link so > its dependencies are only ever used transitively when something > else links to B. If B really links as a shared library though > then see the following. > > If target B links to target A then CMake will not compile objects > in B until A is done. As explained in my previous link this is > because we allow A to contain custom commands that generate > headers used by B. The VS and Xcode IDE build systems offer only > this granularity since they organize compilation and linking rules > of a single target together. The Makefile generator was designed > this way too. Only the Ninja generator has a chance of increasing > parallelism if the extra ordering dependencies were dropped. We've > thought about how to do extra analysis to determine when there is > no such custom command to drop them but have not implemented anything > yet. > > You might be able to use OBJECT libraries to increase parallelism > for all generators and with no changes to CMake: > > set(CMAKE_POSITION_INDEPENDENT_CODE ON) > add_library(Aobjs OBJECT a1.c a2.c) > add_library(Bobjs OBJECT b1.c b2.c) > add_library(Cobjs OBJECT c1.c c2.c) > set(dummy_c dummy.c) # needed for VS 6 and Xcode > add_library(A SHARED $ ${dummy_c}) > add_library(B SHARED $ ${dummy_c}) > add_library(C SHARED $ ${dummy_c}) > target_link_libraries(B PUBLIC A) > target_link_libraries(C PUBLIC B) > > This way the object compilations will be completely independent > of one another and of the linking and ordering dependencies. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 23 10:43:20 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 10:43:20 -0400 Subject: [cmake-developers] LZMA support In-Reply-To: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> Message-ID: <53CFCA08.1090605@kitware.com> On 07/23/2014 08:16 AM, David Cole wrote: > Thanks to Daniel, great work on this contribution... This is a ton of > tedious work, but it will be very useful. Thank you *very much*. +1 I've merged the topic to 'next' for testing, but without the CPack or ExternalProject pieces. Likely some more portability fixes will be required after testing on the dashboard. Once that is clean I will add the other changes again on top of the revised topic. > Two minor comments -- in the commit at the tip of this topic: For reference, that change is to ExternalProject with hunks like: - if(filename MATCHES "(\\.|=)(bz2|tar\\.gz|tgz|zip)$") + if(filename MATCHES "(\\.|=)(xz|bz2|tar\\.gz|tgz|zip)$") > I think the extensions should be alphabetized, and they should also > include "7z" so folks can use the typically smaller 7z files with > ExternalProject as well. Thanks. Actually I think adding "xz" is incorrect anyway. We support compressed tarballs, not arbitrary compressed files. Therefore the list should be 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip correct? -Brad From nilsgladitz at gmail.com Wed Jul 23 10:46:59 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 23 Jul 2014 16:46:59 +0200 Subject: [cmake-developers] LZMA support In-Reply-To: <53CFCA08.1090605@kitware.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> Message-ID: <53CFCAE3.2060200@gmail.com> On 23.07.2014 16:43, Brad King wrote: > Therefore the list should be > > 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip > > correct? > bz2 -> tar\\.bz2 as well while you are at it(?) Nils From eike at sf-mail.de Wed Jul 23 10:48:13 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 23 Jul 2014 16:48:13 +0200 Subject: [cmake-developers] LZMA support In-Reply-To: <53CFCA08.1090605@kitware.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> Message-ID: Am 23.07.2014 16:43, schrieb Brad King: > On 07/23/2014 08:16 AM, David Cole wrote: >> Thanks to Daniel, great work on this contribution... This is a ton of >> tedious work, but it will be very useful. Thank you *very much*. > > +1 > > I've merged the topic to 'next' for testing, but without the CPack > or ExternalProject pieces. Likely some more portability fixes > will be required after testing on the dashboard. Once that is clean > I will add the other changes again on top of the revised topic. > >> Two minor comments -- in the commit at the tip of this topic: > > For reference, that change is to ExternalProject with hunks like: > > - if(filename MATCHES "(\\.|=)(bz2|tar\\.gz|tgz|zip)$") > + if(filename MATCHES "(\\.|=)(xz|bz2|tar\\.gz|tgz|zip)$") > >> I think the extensions should be alphabetized, and they should also >> include "7z" so folks can use the typically smaller 7z files with >> ExternalProject as well. > > Thanks. Actually I think adding "xz" is incorrect anyway. We > support compressed tarballs, not arbitrary compressed files. > Therefore the list should be > > 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip > > correct? Well, then it should be tar.bz2, too. And since this is a regex anyway: 7z|tar\\.bz2|tar\\.[gx]z|t[xg]z|zip Eike From dlrdave at aol.com Wed Jul 23 11:23:33 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 23 Jul 2014 11:23:33 -0400 (EDT) Subject: [cmake-developers] LZMA support In-Reply-To: References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> Message-ID: <8D174A1337641BD-1AC8-15048@webmail-va102.sysops.aol.com> >> Thanks. Actually I think adding "xz" is incorrect anyway. We >> support compressed tarballs, not arbitrary compressed files. >> Therefore the list should be >> >> 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip >> >> correct? > > Well, then it should be tar.bz2, too. And since this is a regex anyway: > > 7z|tar\\.bz2|tar\\.[gx]z|t[xg]z|zip Yes, correct. I still like the original "list all the extensions separately and explicitly" technique rather than "'simplifying' the regex" -- because the first one is an "easier to parse as a human being" regex. Also, it's "more greppable" if somebody is looking for .gz or .xz or tgz or txz. D From mantis at public.kitware.com Wed Jul 23 13:54:12 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 23 Jul 2014 13:54:12 -0400 Subject: [cmake-developers] [CMake 0015035]: Build time file copy_if_different Message-ID: <6a98e9280853afeaa932fc86fff8b0f1@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15035 ====================================================================== Reported By: Daniele E. Domenichelli Assigned To: ====================================================================== Project: CMake Issue ID: 15035 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-23 13:54 EDT Last Modified: 2014-07-23 13:54 EDT ====================================================================== Summary: Build time file copy_if_different Description: As a follow up to this thread[1], we agreed that in order to create a project that other project can use both from the install and build tree, in some cases it is a good idea to replicate the installation tree or part of it inside the build directory, so that the relative paths are the same when the package is used from the build tree or from the installation. [1]http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10492 file(COPY) copies the file is copied at CMake time, not a build time, and cmake is not triggered when the original file is modified, and therefore the copy is not performed at build time if the file is modified and the just runs make (or "build" for visual studio and other IDEs). Also file(COPY) does not have an option to copy the file only if the file(s) is(are) different and could trigger an unnecessary rebuild. execute_process(COMMAND "${CMAKE_COMMAND} -E copy_if_different") does not trigger unnecessary builds, but it is still in the configure phase configure_file(COPYONLY) still copies the file in the configure phase, but it will trigger a cmake run if the original file was modified. Nonetheless it has a few disadvantages: * It's less discoverable than file(COPY) * It can copy just one file at the time, therefore it is not easy to reproduce an install tree * It triggers a cmake run, that will slow down the build * The files to configure might be the product of some build step and therefore not available during the configure step. At the moment (as far as I know) the only way to do it is to use add_custom_command to execute some external CMake script that runs "${CMAKE_COMMAND} -E copy_if_different", but this require a lot of work to handle the file level and target level dependencies correctly. It would be very useful to be able to copy files at build time only if different, without triggering a cmake run, and with a syntax similar to the install command. I suggest to implement one of the following ideas: * Have an option for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the install tree in the binary directory, but at build time, and only if the destination file is missing or is different from the source. * Add some modes to the export() command, for example export(FILES/PROGRAMS/DIRECTORY), with the same signature of install(FILES/PROGRAMS/DIRECTORY), and that replicates the behaviour of this command but at build time and in in the similar way as export(EXPORT) replicates the behaviour of install(EXPORT) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-23 13:54 Daniele E. DomenichelliNew Issue ====================================================================== From brad.king at kitware.com Wed Jul 23 14:39:17 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 14:39:17 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> Message-ID: <53D00155.5000002@kitware.com> On 07/22/2014 07:44 AM, Stephen Kelly wrote: > Daniele E. Domenichelli wrote: >> By the way, is there a reason why file(COPY) does not have an option to >> copy the file only if the file(s) is(are) different. > > configure_file(COPY_ONLY) does that. file(COPY_IF_DIFFERENT) would just do > the same thing but would be more discoverable and might be a good idea. Our file(INSTALL) command used by scripts for "make install" at one time did do a copy-if-different but for incremental re-installations it spent a very long time comparing content. It was decided instead to make the re-copy decision based only on the file timestamp comparison. This makes it very fast. The file(COPY) command is just a binding to file(INSTALL) that does not print status messages and has slightly different defaults. The file(COPY) command already has many keyword options, so a new COPY_IF_DIFFERENT to request the time-consuming comparison could be added. >> Since you were asking if CMake misses some important feature, I believe >> that a very useful feature to have would be to be able to have an option >> for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the >> install tree in the binary directory > > Yes, seems like something worth investigating. I don't think we need to have a build tree, install-in-build-tree, and install-tree all managed by a single build tree. Things like INSTALL_RPATH do not make sense when there are two possible "install" locations. An install-in-build-tree directory is not easily defined in multi-config generators. If you want to test installation then set CMAKE_INSTALL_PREFIX to $build/prefix or something and use the normal "make install" target. Some projects also arrange their layout within the build tree to look like the install tree by setting CMAKE_RUNTIME_OUTPUT_DIRECTORY[_] and related variables appropriately. Returning to CMakePackageConfigHelpers, I work on several projects that provide one Config.cmake file in the build tree and one in the install tree. They are generated by hand. I do not use CMakePackageConfigHelpers. IMO it is good for getting projects started without having to learn all the details. For mature projects that want to do fancy things like supporting applications from the build tree, manual generation of the package configuration files becomes worthwhile. -Brad From konstantin at podsvirov.pro Wed Jul 23 14:59:44 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 23 Jul 2014 22:59:44 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <3104551406104718@web10h.yandex.ru> References: <3923551405583879@web23m.yandex.ru> <3104551406104718@web10h.yandex.ru> Message-ID: <6560191406141984@web27m.yandex.ru> CPack IFW generator built an online installer itself on Linux! 23.07.2014, 12:39, "Konstantin Podsvirov" : > Update as of July 23, available! The installer for 64-bit versions of Linux are available here: http://ifw.podsvirov.pro/cmake/cmake-master-linux-64bit-online.run Encouraged to test and write your own reviews. As before, I will try to build updates once a week. Regards, Konstantin Podsvirov From brad.king at kitware.com Wed Jul 23 16:44:09 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 16:44:09 -0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <2681081405582381@web7g.yandex.ru> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> Message-ID: <53D01E99.3090905@kitware.com> On 07/17/2014 03:33 AM, Konstantin Podsvirov wrote: > Now I fixed it. Should work. Thanks for this contribution! I finally made time to look over the changes and integrate them. Overall, very nice work. I squashed your history down to a single commit, fixed newlines, fixed indentation, fixed long lines, and made couple minor portability tweaks. The new draft commit is: CPack: Add an "IFW" generator for Qt Framework Installer http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9006316 You can compare it to your last commit (3c506bd2) with: git diff 3c506bd2 a9006316 -w --color-words=. to see that there are almost no non-whitespace changes. I also added a slightly larger portability change: CPackIFW: Replace use of strftime with cmTimestamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a943d41d but I'm not set up to test it. Please fetch from our repo to try out these versions to make sure I didn't break anything. These draft commits are now in 'next' for upstream testing. Thanks! -Brad From mathieu.marache at gmail.com Thu Jul 24 03:57:56 2014 From: mathieu.marache at gmail.com (Mathieu MARACHE) Date: Thu, 24 Jul 2014 09:57:56 +0200 Subject: [cmake-developers] [patch] Qt plugins are missing when deploying Message-ID: I added two plugins qnativewifi and qtga that where missing in FindQt4.cmake and thus where not deployed with DeployQt4.cmake although they were mentioned in the plugins parameters. This is a patch is against current master but could well be back ported to earlier versions since this file has slightly changed thanks -- n?????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-nativewifi-and-qtga-plugins.patch Type: application/octet-stream Size: 2470 bytes Desc: not available URL: From mantis at public.kitware.com Thu Jul 24 05:48:01 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 24 Jul 2014 05:48:01 -0400 Subject: [cmake-developers] [CMake 0015036]: "make --question" always returns 1 Message-ID: <079a36c52269e1672afc107b5bdf2528@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15036 ====================================================================== Reported By: Simon Ask Ulsnes Assigned To: ====================================================================== Project: CMake Issue ID: 15036 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-24 05:48 EDT Last Modified: 2014-07-24 05:48 EDT ====================================================================== Summary: "make --question" always returns 1 Description: In my project, I'm relying on the build system being able to answer the question whether or not the source tree has been updated or not. Currently, Makefiles generated by CMake do not support this usage for one reason or another. The exit code of "make --question" should be 0 if all targets (or the specified target) are up to date, and nonzero if changes have been made. However, CMake-generated Makefiles always indicate that changes have been made, which results in nontrivial work being executed unnecessarily. Steps to Reproduce: 1. Create simple project with a single source file and a CMakeLists.txt 2. Create the Makefile with `cmake .` 3. Run `make`. 4. Run `make --question`. 5. Observe that the exit code is 1 instead of 0, even though the source file was not updated between steps 3 and 4. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-24 05:48 Simon Ask UlsnesNew Issue ====================================================================== From mantis at public.kitware.com Thu Jul 24 09:11:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 24 Jul 2014 09:11:47 -0400 Subject: [cmake-developers] [CMake 0015037]: given a cpp file, how to know what target it's built and where is the flags.make is placed Message-ID: <87648039c2ef18534583ffdafea701c2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15037 ====================================================================== Reported By: chen bin Assigned To: ====================================================================== Project: CMake Issue ID: 15037 Category: CMake Reproducibility: always Severity: major Priority: immediate Status: new ====================================================================== Date Submitted: 2014-07-24 09:11 EDT Last Modified: 2014-07-24 09:11 EDT ====================================================================== Summary: given a cpp file, how to know what target it's built and where is the flags.make is placed Description: assume the generator is GNU make. how to know what executable or library is built from the build directory *by my software*? the executable or library is built through the rule "add_executable" or "add_library" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-24 09:11 chen bin New Issue ====================================================================== From nick at astrant.net Thu Jul 24 17:47:19 2014 From: nick at astrant.net (Nick Overdijk) Date: Thu, 24 Jul 2014 23:47:19 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> Message-ID: I'm using target_include_directories of A to get some include directories into B well, so I can't use target_link_libraries(A INTERFACE B), and I can't seem to use the OBJECT-way neither since B's sources won't compile without A's INTERFACE_INCLUDE_DIRECTORIES... Any suggestions? On Wed, Jul 23, 2014 at 3:19 PM, Nick Overdijk wrote: > Crystal clear. Another layer of indirection eh? I'll see if I can work > with that... Thanks for the explanation. > > > On Wed, Jul 23, 2014 at 3:14 PM, Brad King wrote: > >> On 07/23/2014 09:07 AM, Nick Overdijk wrote: >> > Oh wait, since a is in the interface of b, b will always be >> > accompanied by a, even though it's not a dependency. >> > Is that how it works? >> >> Yes. If B is a static library then it does not really link so >> its dependencies are only ever used transitively when something >> else links to B. If B really links as a shared library though >> then see the following. >> >> If target B links to target A then CMake will not compile objects >> in B until A is done. As explained in my previous link this is >> because we allow A to contain custom commands that generate >> headers used by B. The VS and Xcode IDE build systems offer only >> this granularity since they organize compilation and linking rules >> of a single target together. The Makefile generator was designed >> this way too. Only the Ninja generator has a chance of increasing >> parallelism if the extra ordering dependencies were dropped. We've >> thought about how to do extra analysis to determine when there is >> no such custom command to drop them but have not implemented anything >> yet. >> >> You might be able to use OBJECT libraries to increase parallelism >> for all generators and with no changes to CMake: >> >> set(CMAKE_POSITION_INDEPENDENT_CODE ON) >> add_library(Aobjs OBJECT a1.c a2.c) >> add_library(Bobjs OBJECT b1.c b2.c) >> add_library(Cobjs OBJECT c1.c c2.c) >> set(dummy_c dummy.c) # needed for VS 6 and Xcode >> add_library(A SHARED $ ${dummy_c}) >> add_library(B SHARED $ ${dummy_c}) >> add_library(C SHARED $ ${dummy_c}) >> target_link_libraries(B PUBLIC A) >> target_link_libraries(C PUBLIC B) >> >> This way the object compilations will be completely independent >> of one another and of the linking and ordering dependencies. >> >> -Brad >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Jul 25 07:05:39 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 25 Jul 2014 07:05:39 -0400 Subject: [cmake-developers] [CMake 0015038]: Linking $ into a static library is broken with Xcode 6 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15038 ====================================================================== Reported By: Jamie Kirkpatrick Assigned To: ====================================================================== Project: CMake Issue ID: 15038 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-25 07:05 EDT Last Modified: 2014-07-25 07:05 EDT ====================================================================== Summary: Linking $ into a static library is broken with Xcode 6 Description: Trying to use $ to link an object target into a static library is broken with Xcode 6 because it uses separate flags for linking static libraries. Steps to Reproduce: - Create an object library target with a source file compiled in. - Create a static library that links the object library in. - Create a binary that uses something from the original source file and links the static library in. - Compiling will result in undefined symbols. Additional Information: Previously the OTHER_LDFLAGS variable was respected but now it uses OTHER_LIBTOOLFLAGS which breaks things because the old variable was used to specify the list of extra object files to link into the static library target. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-25 07:05 Jamie KirkpatrickNew Issue ====================================================================== From daniele.domenichelli at gmail.com Fri Jul 25 09:54:59 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Fri, 25 Jul 2014 15:54:59 +0200 Subject: [cmake-developers] Install in Build Tree [Was: Topic CMakePackageConfigHelpers_build_tree] In-Reply-To: <53D00155.5000002@kitware.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> Message-ID: <53D261B3.4000702@gmail.com> [Changing subject in order to keep the conversation separate] On 23/07/14 20:39, Brad King wrote: >>> Since you were asking if CMake misses some important feature, I believe >>> that a very useful feature to have would be to be able to have an option >>> for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the >>> install tree in the binary directory >> >> Yes, seems like something worth investigating. > > I don't think we need to have a build tree, install-in-build-tree, and > install-tree all managed by a single build tree. Things like > INSTALL_RPATH do not make sense when there are two possible "install" > locations. An install-in-build-tree directory is not easily defined > in multi-config generators. Sorry, maybe I didn't explain the problem properly, there are no "build tree", "install-in-build-tree", and "install-tree", but only "build tree" and "install-tree" I'm not referring to the installation of "TARGETS" (for which the rpath and CMAKE_RUNTIME_OUTPUT_DIRECTORY[_] and related variables are enough), I'm referring to the "data files" (i.e. whatever usually goes to /share) that may or may not be generated by cmake or by the build step (not as target but as configure_file or as a product of some command) and are usually installed with "install(FILES/PROGRAMS/DIRECTORY)". These files might not be related to a target, therefore it might not make sense to "add" them to a target and install them with the install(TARGET) call (like you could do with PUBLIC_HEADERs and similar). I think there are good reasons for copying the files, for example: * Your program expects to find the data files in a certain relative path or with a certain tree structure and you have some good reason for not keeping them with the same structure in the source folder. * You have some files that are coming from the source tree but some are generated by CMake or produced during the build and the program expects to find all of them in the same folder. If these files are not in the expected place, the build tree might not be usable, and the installation step would be required to use your project. > If you want to test installation then set CMAKE_INSTALL_PREFIX to > $build/prefix or something and use the normal "make install" target. What I want to be able to do is not test the installation, but to be able to use the library from the build tree. Using an installation for testing different builds is more complicated, because you will have to set a different CMAKE_INSTALL_PREFIX and to run the install phase every time you make a change. Finally it will require to set LD_LIBRARY_PATH environment variable, or to set CMAKE_SKIP_INSTALL_RPATH cmake variable to FALSE. > Some projects also arrange their layout within the build tree to look > like the install tree by setting CMAKE_RUNTIME_OUTPUT_DIRECTORY[_] > and related variables appropriately. That's exactly what I would like to be able to do, but for "data files" as well, and at the moment that is possible, but not in an easy way. Cheers, Daniele From daniele.domenichelli at gmail.com Fri Jul 25 10:00:42 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Fri, 25 Jul 2014 16:00:42 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D00155.5000002@kitware.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> Message-ID: <53D2630A.1030106@gmail.com> On 23/07/14 20:39, Brad King wrote: > Returning to CMakePackageConfigHelpers, I work on several projects > that provide one Config.cmake file in the build tree and one > in the install tree. They are generated by hand. I do not use > CMakePackageConfigHelpers. IMO it is good for getting projects > started without having to learn all the details. For mature projects > that want to do fancy things like supporting applications from the > build tree, manual generation of the package configuration files > becomes worthwhile. Sorry if I insist, but I still don't understand why not allowing to be able to use CMakePackageConfigHelpers for the build tree, and I still cannot find a valid alternative therefore I'll do a last desperate defence of my patch to try to convince you and Steve. ;) I think that it is good for new projects to be able to use the build tree before actually testing the installation of the project, as this will speed up the development process. From my experience, the installation step is finalized later in the creation step of a library. 'configure_package_config_file()' allows you to do whatever you want in your input config file, exactly like 'configure_file()', but it is still very helpful for handling relative paths correctly. I agree that "perfect" config files should not contain paths, but I believe that if no paths should be in the config file, then 'configure_package_config_file()' does not make not much sense neither for mature nor new projects (except for simplify the handling of components) and perhaps should be deprecated or replaced by something else. On the other hand if paths are acceptable be in the config files (as relative paths), then I don't see why generating them in the same way both for build and install tree shouldn't be allowed, and I believe that there are several valid use cases where the paths are required. I work too on several projects that provide one Config.cmake file in the build tree and one for the installation, but they use paths, and the paths in the installed files are absolute. I'm working on porting them to a "modern" CMake style, but I cannot suddenly drop compatibility with older versions, and I cannot drop the path variables from the config files. Moreover I cannot push the dependency on the latest CMake and I'm stuck with 2.8.9, that misses several of the new features required for a full "modern" CMake style are still missing, thus the paths are necessary. Therefore for now I'm trying to port them to use relative paths, in order to simplify the creation of the installers for Windows, and this led to trying to port them from configure_file() to configure_package_config_file(). Unfortunately I cannot but drop compatibility with having a working build tree. The result is that I had to choose between these options (I couldn't find any other option, but I'm still open to different solution if you can think one): 1) Not using CMakePackageConfigHelpers and keep using configure_file with the absolute paths 2) Using two different input files and two different calls. 3) Pay very good attention to pass only absolute path to configure_package_config_file, and keep an "ugly" config file in the build directory with PACKAGE_PREFIX_DIR pointing to the CMAKE_INSTALL_PREFIX, and the variables with absolute path. As I mentioned before, this works, but it is error prone because using relative path will result in a broken config file. 4) Use a hack like (this actually works, but it looks horrible to me and require an explaination comment wherever you use it...) set(_CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}") set(CMAKE_INSTALL_PREFIX "${CMAKE_BINARY_DIR}") configure_package_config_file(...) set(CMAKE_INSTALL_PREFIX "${_CMAKE_INSTALL_PREFIX}") unset(_CMAKE_INSTALL_PREFIX) 5) Ship a modified version of CMakePackageConfigHelpers with my project. All these options seem bad to me, therefore I went for the "cleanest" solution, i.e. get the patch merged upstream, in order to ship with my projects the update "official" CMakePackageConfigHelpers module that I will remove when I can finally depend on the version that will contain the patched version. Anyway, if I still didn't convince you, at least now nobody can say I didn't try... ;) Do you want me to drop the patch and push the restructured documentation in a new topic? Cheers, Daniele P.S. Sorry for the long mail From norman-k-williams at uiowa.edu Fri Jul 25 17:05:38 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Fri, 25 Jul 2014 21:05:38 +0000 Subject: [cmake-developers] CMake, Ninja generator, and ExternalProjects Message-ID: I?ve been using the Ninja generator on Linux and OS X lately, because it handles command output during parallel builds better. But big ?SuperBuild? projects ? Slicer being exhibit A ? which builds using the CMake ExternalProjects Module, have a couple of annoyances. 1. Since Ninja buffers command output, you won?t see the output of an ExternalProject build until it?s completed. This can take considerable time for larger projects. 2. Ninja gets the number of processes from the OS, and executes that many processes, even if it?s been called from another instance of Ninja. It doesn?t have GnuMake?s process pool and inter-instance communication. Cmake could generate ninja build files that would address these problems, somewhat. Ninja has a ?l flag that won?t start new jobs if the load is greater than . There?s also the ?console pool? facility that would allow ExternalProject builds to display output, though that would get back to the Gmake issue of different processes interleaving output. Obviously, Ninja could be fixed to behave better when run recursively, either by implementing Gmake style intra-instance communication. But I?m not sure that fits their design and performance goals. I?ve raised it on the Ninja list? Perhaps I?m simply bumping up against the limits of the ExternalProject module ? since ExternalProjects are essentially walled off from their parent Cmake projects and can be built according to any recipe, it may be too much to hope for much in the way of Ninja project optimization. ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sun Jul 27 04:07:13 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 27 Jul 2014 04:07:13 -0400 Subject: [cmake-developers] [CMake 0015039]: CMake linked against libc++ on OS X 10.7 cuts lines at 1024 characters Message-ID: <81ec632e427199cfe72b1973df041515@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15039 ====================================================================== Reported By: Mojca Miklavec Assigned To: ====================================================================== Project: CMake Issue ID: 15039 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-27 04:07 EDT Last Modified: 2014-07-27 04:07 EDT ====================================================================== Summary: CMake linked against libc++ on OS X 10.7 cuts lines at 1024 characters Description: As already reported (http://public.kitware.com/pipermail/cmake-developers/2014-June/010712.html) building CMake on OS X 10.7 against libc++ fails because some lines are cut at 1024 characters when reading from link.txt. If I manually execute a couple of commands that have been "cut", the build eventually succeeds, but the resulting cmake binary is "useless" because any project that requires lines longer than 1024 characters to compile code, fails to build as well. Steps to Reproduce: Compile CMake on OS X 10.7 using CC='/usr/bin/clang' CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libc++' Additional Information: Brad King wrote: The lines are read here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmcmd.cxx;hb=v3.0.0#l988 using the GetLineFromStream helper: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/SystemTools.cxx;hb=v3.0.0#l4157 Note the buffer size is 1024. Something must go wrong with the stream state to make it look like EOL or EOF to this code. Ben Boeckel wrote: The proper way to read lines from a file using iostream is: std::string line; while (std::getline(istr, line)) { // use line } Unfortunately, it looks like there's unavoidable extra logic in there. Maybe we could do: #ifdef BROKEN_STREAMS // crutch code #else // sanity #endif ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-27 04:07 Mojca Miklavec New Issue ====================================================================== From mantis at public.kitware.com Sun Jul 27 04:29:40 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 27 Jul 2014 04:29:40 -0400 Subject: [cmake-developers] [CMake 0015040]: CMake needs to support building against "/" on OS X with a deployment target set Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15040 ====================================================================== Reported By: Mojca Miklavec Assigned To: ====================================================================== Project: CMake Issue ID: 15040 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-27 04:29 EDT Last Modified: 2014-07-27 04:29 EDT ====================================================================== Summary: CMake needs to support building against "/" on OS X with a deployment target set Description: CMake doesn't allow setting -DCMAKE_OSX_DEPLOYMENT_TARGET="10.8" together with -DCMAKE_OSX_SYSROOT="/". According to an Apple engineer that's a problem/flaw. See also the whole discussion at https://trac.macports.org/ticket/44125 (If you are able to CC others, please add 'jeremyhu' at macports . org to this ticket.) I'm attaching his patch that is currently being used in MacPorts: https://trac.macports.org/browser/trunk/dports/devel/cmake/files/patch-Modules-Platform-Darwin.cmake.diff?rev=122338 Steps to Reproduce: Run cmake -DCMAKE_OSX_DEPLOYMENT_TARGET="10.8" -DCMAKE_OSX_SYSROOT="/" ... on any CMake-based project. The build always fails, complaining that CMAKE_OSX_SYSROOT should also be set. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-27 04:29 Mojca Miklavec New Issue 2014-07-27 04:29 Mojca Miklavec File Added: patch-Modules-Platform-Darwin.cmake.diff ====================================================================== From mantis at public.kitware.com Mon Jul 28 09:08:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 28 Jul 2014 09:08:11 -0400 Subject: [cmake-developers] [CMake 0015042]: Add CPACK_PACKAGE_COMPONENT_NAME that naming component packages gets more flexible Message-ID: <5894fae9699cdca888547190956de1e9@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15042 ====================================================================== Reported By: Lucas Betschart Assigned To: ====================================================================== Project: CMake Issue ID: 15042 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-28 09:08 EDT Last Modified: 2014-07-28 09:08 EDT ====================================================================== Summary: Add CPACK_PACKAGE_COMPONENT_NAME that naming component packages gets more flexible Description: If I build my -dev package with cpack COMPONENT flag, it get this: opentxs-0.93.0-1.x86_64-dev.tar.gz (I add the version and system to the name), but I'd like to have opentxs-dev-0.93.0-1.x86_64.tar.gz Please add CPACK_PACKAGE_COMPONENT_NAME as a variable so one can use that in the package file name. So I could do something like this: set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_COMPONENT_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_PACKAGE_RELEASE}.${CMAKE_SYSTEM_PROCESSOR}") Thx! Additional Information: In your source: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CPack/cmCPackGenerator.cxx;h=9336bedecad9ab0f0a6354cfe5597f670fb971f0;hb=HEAD#l1427 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-28 09:08 Lucas BetschartNew Issue ====================================================================== From brad.king at kitware.com Mon Jul 28 09:44:01 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 09:44:01 -0400 Subject: [cmake-developers] [patch] Qt plugins are missing when deploying In-Reply-To: References: Message-ID: <53D653A1.9070905@kitware.com> On 07/24/2014 03:57 AM, Mathieu MARACHE wrote: > I added two plugins qnativewifi and qtga that where missing in FindQt4.cmake Applied, thanks: FindQt4: Add nativewifi and qtga plugins http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b5052b0 -Brad From brad.king at kitware.com Mon Jul 28 10:02:23 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 10:02:23 -0400 Subject: [cmake-developers] Install in Build Tree In-Reply-To: <53D261B3.4000702@gmail.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D261B3.4000702@gmail.com> Message-ID: <53D657EF.9000800@kitware.com> On 07/25/2014 09:54 AM, Daniele E. Domenichelli wrote: >> Some projects also arrange their layout within the build tree to look >> like the install tree by setting CMAKE_RUNTIME_OUTPUT_DIRECTORY[_] >> and related variables appropriately. > > That's exactly what I would like to be able to do, but for "data files" > as well, and at the moment that is possible, but not in an easy way. Okay, that clarifies things. The proposal in 15035 makes more sense now. FYI, CMake solves this problem for locating its own resources when running in the build tree by looking for a file relative to the executable whose content tells it where to find the resources directly out of the source tree: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSystemTools.cxx;hb=v3.0.0#l2187 -Brad From brad.king at kitware.com Mon Jul 28 10:11:39 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 10:11:39 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D2630A.1030106@gmail.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> Message-ID: <53D65A1B.3000202@kitware.com> On 07/25/2014 10:00 AM, Daniele E. Domenichelli wrote: > Sorry if I insist, but I still don't understand why not allowing to be > able to use CMakePackageConfigHelpers for the build tree I didn't mean to imply that the patch is not acceptable. After the revisions to the documentation from our discussion in another branch of this thread I think it is ready for testing in 'next'. -Brad From brad.king at kitware.com Mon Jul 28 10:19:28 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 10:19:28 -0400 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> Message-ID: <53D65BF0.8090106@kitware.com> On 07/24/2014 05:47 PM, Nick Overdijk wrote: > I'm using target_include_directories of A to get some include > directories into B well, so I can't use > target_link_libraries(A INTERFACE B), Can you clarify this with sample code please? > and I can't seem to use the OBJECT-way neither since B's sources > won't compile without A's INTERFACE_INCLUDE_DIRECTORIES... Usage requirements were designed with target_link_libraries as the main way to propagate them, but OBJECT libraries do not allow use with target_link_libraries. This is an open problem with the design of the two features. See also discussion here: http://www.cmake.org/Bug/view.php?id=14970 -Brad From brad.king at kitware.com Mon Jul 28 11:00:07 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 11:00:07 -0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <53D01E99.3090905@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> Message-ID: <53D66577.2050506@kitware.com> On 07/23/2014 04:44 PM, Brad King wrote: > These draft commits are now in 'next' for upstream testing. After squashing in one fixup for building with CMake < 2.8.9 this feature is now in master: CPack: Add an "IFW" generator for Qt Framework Installer http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=44850a26 CPackIFW: Replace use of strftime with cmTimestamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=73b336c9 Help: Add notes for topic 'cpack-ifw-generator' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b9be4d21 -Brad From daniele.domenichelli at gmail.com Mon Jul 28 11:07:41 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 28 Jul 2014 17:07:41 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D65A1B.3000202@kitware.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> <53D65A1B.3000202@kitware.com> Message-ID: <53D6673D.9080109@gmail.com> On 28/07/14 16:11, Brad King wrote: > On 07/25/2014 10:00 AM, Daniele E. Domenichelli wrote: >> Sorry if I insist, but I still don't understand why not allowing to be >> able to use CMakePackageConfigHelpers for the build tree > > I didn't mean to imply that the patch is not acceptable. After the > revisions to the documentation from our discussion in another branch > of this thread I think it is ready for testing in 'next'. Sorry, I misunderstood your email! I applied the changes you requested to the documentation, rebased, and merged to next for testing. Thanks, Daniele From mantis at public.kitware.com Mon Jul 28 11:20:41 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 28 Jul 2014 11:20:41 -0400 Subject: [cmake-developers] [CMake 0015043]: How to convert Visual Studio .props file into cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.gccxml.org/Bug/view.php?id=15043 ====================================================================== Reported By: Ravi Raman Assigned To: ====================================================================== Project: CMake Issue ID: 15043 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-07-28 11:20 EDT Last Modified: 2014-07-28 11:20 EDT ====================================================================== Summary: How to convert Visual Studio .props file into cmake Description: Hello, We are using CMake 3.0 on Windows. Our main objective is to convert Microsoft Visual Studio built solution to CMake 3.0 solution. In the process of doing so, we have come across many Visual Studio property files (.props) which get included in the Visual Studio project files (.vcxproj) files. For example in a Visual Studio project file , the Property file (test.props) gets included as follows: To achieve the same thing, in the CMakeLists file we are using the following command: set_target_properties(testproj PROPERTIES VS_PROPERTY_SHEETS "${TestCfg}/test.props") Note that we have set TestCfg appropriately in one of the .cmake files that we include in our CMakeLists.txt The cmake build is successful and the cmake VCX project also gets created. But that vcx project does not contain the entry of the test.props file. Please let us know what we are missing or doing wrong. Also, is there any other way to include .props files in cmake. Any help in this regard would be appreciated. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-28 11:20 Ravi Raman New Issue ====================================================================== From mantis at public.kitware.com Mon Jul 28 11:32:30 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 28 Jul 2014 11:32:30 -0400 Subject: [cmake-developers] [CMake 0015044]: How to convert existing Visual Studio .targets file to cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.gccxml.org/Bug/view.php?id=15044 ====================================================================== Reported By: Ravi Raman Assigned To: ====================================================================== Project: CMake Issue ID: 15044 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-07-28 11:32 EDT Last Modified: 2014-07-28 11:32 EDT ====================================================================== Summary: How to convert existing Visual Studio .targets file to cmake Description: Hello, We are using CMake 3.0 on Windows. Our main objective is to convert Microsoft Visual Studio built solution to CMake 3.0 solution. In the process of doing so, we have come across many Visual Studio targets files (files with extension .targets) which get included in the Visual Studio project files (.vcxproj) files. For example in a Visual Studio project file , the targets file (test.targets) gets included as follows: To achieve the same thing, in the CMakeLists file we are using the following command: add_custom_targets() with the appropriate target name "test" Please let us know if this is the correct way to convert existing Visual Studio .targets files to cmake ? If this is incorrect, please let us know how to achieve it with a simple example. Thanks. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-28 11:32 Ravi Raman New Issue ====================================================================== From nilsgladitz at gmail.com Tue Jul 29 03:31:41 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 29 Jul 2014 09:31:41 +0200 Subject: [cmake-developers] CMAKE_${lang}_COMPILER_LINKER_OPTION_FLAG_EXECUTABLE Message-ID: <53D74DDD.6070006@gmail.com> While looking for places to add my new CMAKE_${lang}_LINKER_SUPPORTS_PDB I found the following in Windows-df.cmake: set(CMAKE_${lang}_COMPILER_LINKER_OPTION_FLAG_EXECUTABLE "/link") It looks suspicious because I don't think "lang" is actually set in that context. The only mention of "LINKER_OPTION_FLAG" seems to be Source/cmNinjaNormalTargetGenerator.cxx Nils From mantis at public.kitware.com Tue Jul 29 07:42:59 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 29 Jul 2014 07:42:59 -0400 Subject: [cmake-developers] [CMake 0015045]: FindCUDA.cmake passes directory COMPILE_DEFINITIONS to nvcc without handling generator expressions Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15045 ====================================================================== Reported By: Nils Gladitz Assigned To: James Bigler ====================================================================== Project: CMake Issue ID: 15045 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2014-07-29 07:42 EDT Last Modified: 2014-07-29 07:42 EDT ====================================================================== Summary: FindCUDA.cmake passes directory COMPILE_DEFINITIONS to nvcc without handling generator expressions Description: A colleague noticed this while using UseQt4.cmake which since 3.0 contains: set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$>:QT_NO_DEBUG>) To recreate the old behaviour generator expressions could be stripped with the new string(GENEX_STRIP) or perhaps even expanded with file(GENERATE). Steps to Reproduce: cmake_minimum_required(VERSION 3.0) set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$>:NOT_FOO> ) find_package(CUDA REQUIRED) cuda_add_library(empty empty.cu) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-29 07:42 Nils Gladitz New Issue 2014-07-29 07:42 Nils Gladitz Status new => assigned 2014-07-29 07:42 Nils Gladitz Assigned To => James Bigler ====================================================================== From brad.king at kitware.com Tue Jul 29 09:54:59 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Jul 2014 09:54:59 -0400 Subject: [cmake-developers] CMAKE_${lang}_COMPILER_LINKER_OPTION_FLAG_EXECUTABLE In-Reply-To: <53D74DDD.6070006@gmail.com> References: <53D74DDD.6070006@gmail.com> Message-ID: <53D7A7B3.3000505@kitware.com> On 07/29/2014 03:31 AM, Nils Gladitz wrote: > While looking for places to add my new CMAKE_${lang}_LINKER_SUPPORTS_PDB > I found the following in Windows-df.cmake: > > set(CMAKE_${lang}_COMPILER_LINKER_OPTION_FLAG_EXECUTABLE "/link") > > It looks suspicious because I don't think "lang" is actually set in that > context. > > The only mention of "LINKER_OPTION_FLAG" seems to be > Source/cmNinjaNormalTargetGenerator.cxx Running "git log -p -S_COMPILER_LINKER_OPTION_FLAG_" one can see how that was added to help with Ninja+MSVC and then refactored away later. Please drop both locations. Thanks, -Brad From konstantin at podsvirov.pro Tue Jul 29 13:47:14 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 29 Jul 2014 21:47:14 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <53D66577.2050506@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> Message-ID: <599601406656034@web5j.yandex.ru> Hello Developers! The topic 'cpack-ifw-generator' now in the branch 'master'. 28.07.2014, 18:58, "Brad King" : > After squashing in one fixup for building with CMake < 2.8.9 > this feature is now in master... This is good news for me and I hope for others. I hope the IFW generator have been users and fans. I have some news and changes. The source code is now available here: http://git.podsvirov.pro/?p=kitware/cmake.git Changes on the subject CPack IFW generator now in the branch 'cpack-ifw-generator'. You can clone code for the study: git clone -b cpack-ifw-generator git://podsvirov.pro/kitware/cmake.git Wish to check the generator in action you can use online-installer for your platform: Linux 32bit: http://ifw.podsvirov.pro/cmake/cmake-ifw-linux-32bit-online.run Linux 64bit: http://ifw.podsvirov.pro/cmake/cmake-ifw-linux-64bit-online.run Windows 32bit: http://ifw.podsvirov.pro/cmake/cmake-ifw-windows-32bit-online.exe Windows 64bit: http://ifw.podsvirov.pro/cmake/cmake-ifw-windows-64bit-online.exe (Unfortunately I don't have a device's Mac OS, and I can't test the code here) Presents online installers install CMake with the latest developments on the topic 'cpack-ifw-generator'. Note that the installer created using CPack IFW gererator and demonstrate his work. Updates go out about once a week. Last update on 28 July: - added some configuration variables for package installation information about the owner and tasks of the logo and icons for the installer. As before the HTML version of the documentation is available here: http://ifw.podsvirov.pro/cmake/doc/cmake-3.0/html Urge to try CPack IFW generator and write your feedback and suggestion to the mailing list or to me personally. Once again, thank Brad for his help in promoting the topic 'cpack-ifw-generator'. (Sorry for my English, I use a translator) Regards, Konstantin Podsvirov From nick at astrant.net Wed Jul 30 05:31:14 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 30 Jul 2014 11:31:14 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: <53D65BF0.8090106@kitware.com> References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> <53D65BF0.8090106@kitware.com> Message-ID: Here's the sample code: https://github.com/NickNick/cmake-interface-includes/commits/master . The second commit breaks the build. I sort of understand why it does, but that means I can't use the "INTERFACE"-trick, so to say, even with static libraries. Thanks for linking the other bug. On Mon, Jul 28, 2014 at 4:19 PM, Brad King wrote: > On 07/24/2014 05:47 PM, Nick Overdijk wrote: > > I'm using target_include_directories of A to get some include > > directories into B well, so I can't use > > target_link_libraries(A INTERFACE B), > > Can you clarify this with sample code please? > > > and I can't seem to use the OBJECT-way neither since B's sources > > won't compile without A's INTERFACE_INCLUDE_DIRECTORIES... > > Usage requirements were designed with target_link_libraries as > the main way to propagate them, but OBJECT libraries do not allow > use with target_link_libraries. This is an open problem with the > design of the two features. See also discussion here: > > http://www.cmake.org/Bug/view.php?id=14970 > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 30 09:16:48 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 09:16:48 -0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <599601406656034@web5j.yandex.ru> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> Message-ID: <53D8F040.1000505@kitware.com> On 07/29/2014 01:47 PM, Konstantin Podsvirov wrote: > I have some news and changes. > > The source code is now available here: > http://git.podsvirov.pro/?p=kitware/cmake.git New changes applied here: CPackIFW: Document cpack_ifw_configure_component DEPENDS option http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2340001 CPackIFW: Add package configuration variables http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7511b7f Thanks, -Brad From brad.king at kitware.com Wed Jul 30 09:32:46 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 09:32:46 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D6673D.9080109@gmail.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> <53D65A1B.3000202@kitware.com> <53D6673D.9080109@gmail.com> Message-ID: <53D8F3FE.2020005@kitware.com> On 07/28/2014 11:07 AM, Daniele E. Domenichelli wrote: > I applied the changes you requested to the documentation, rebased, and > merged to next for testing. Thanks. While reviewing the commits in 'next' again I realized that assuming paths are relative to CMAKE_BINARY_DIR may not be correct. Some projects may be nested inside others, and the CMAKE_BINARY_DIR may not be the proper location for a nested project. Instead the BUILD_TREE option should be followed by another argument specifying the base for relative paths, i.e. the in-build-tree prefix. -Brad From mantis at public.kitware.com Wed Jul 30 09:42:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 30 Jul 2014 09:42:22 -0400 Subject: [cmake-developers] [CMake 0015046]: visual studio configuration sometimes switches from x64 to win32 Message-ID: <77733e37feb1474c202e807afee3e32f@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15046 ====================================================================== Reported By: tim blechmann Assigned To: ====================================================================== Project: CMake Issue ID: 15046 Category: CMake Reproducibility: sometimes Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-30 09:42 EDT Last Modified: 2014-07-30 09:42 EDT ====================================================================== Summary: visual studio configuration sometimes switches from x64 to win32 Description: i'm configuring my windows/64bit builds using the "Visual Studio 12 2013 Win64" generator. however sometimes when running cmake on this existing build folder, the configuration switches from x64 to win32 (likewise the generator is switched to "Visual Studio 12 2013"). while i have seen this a couple of time on different machines, i haven't been able to find a reproducer. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-30 09:42 tim blechmann New Issue ====================================================================== From brad.king at kitware.com Wed Jul 30 09:58:05 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 09:58:05 -0400 Subject: [cmake-developers] LZMA support In-Reply-To: <53CFCA08.1090605@kitware.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> Message-ID: <53D8F9ED.40900@kitware.com> On 07/23/2014 10:43 AM, Brad King wrote: > I've merged the topic to 'next' for testing, but without the CPack > or ExternalProject pieces. Likely some more portability fixes > will be required after testing on the dashboard. Once that is clean > I will add the other changes again on top of the revised topic. This is all now in master as of commit 6370c90f. I've updated issues 13072, 13515, 14504, and 14519 accordingly. Thanks! -Brad From konstantin at podsvirov.pro Wed Jul 30 10:30:17 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 30 Jul 2014 18:30:17 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <53D8F040.1000505@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> Message-ID: <20851406730617@web26j.yandex.ru> Hi guys! 30.07.2014, 17:15, "Brad King" : > New changes applied here: > > CPackIFW: Document cpack_ifw_configure_component DEPENDS option > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2340001 > > CPackIFW: Add package configuration variables > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7511b7f Thank You Brad! The code is now in the branch 'next' so soon it will get to 'master' :-) Regards, Konstantin Podsvirov From brad.king at kitware.com Wed Jul 30 10:51:53 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 10:51:53 -0400 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> <53D65BF0.8090106@kitware.com> Message-ID: <53D90689.8000706@kitware.com> On 07/30/2014 05:31 AM, Nick Overdijk wrote: > https://github.com/NickNick/cmake-interface-includes/commits/master Thanks. For reference, the summary is: cmake_minimum_required(VERSION 2.8.12) project(FOO CXX) add_library(foo foo/foo.cpp) target_include_directories(foo INTERFACE foo) add_library(bar bar/bar.cpp) target_link_libraries(bar foo) # reduces parallel compilation #target_link_libraries(bar INTERFACE foo) # compiles bar without foo reqs With CMake 3.0 you might be able to hack something up with INTERFACE libraries, but that will increase complexity. The INTERFACE workaround commented out in the above example is really only good when no usage requirements need to be propagated. Otherwise, I think you're stuck with the reduced parallelism until CMake can be taught to detect when it is safe to drop such dependencies as I explained earlier. FWIW, I've been building large projects this way for years and rarely been bothered by this. Usually each library has so many sources that parallelism within each target is enough. -Brad From nick at astrant.net Wed Jul 30 11:09:05 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 30 Jul 2014 17:09:05 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: <53D90689.8000706@kitware.com> References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> <53D65BF0.8090106@kitware.com> <53D90689.8000706@kitware.com> Message-ID: True, I was just bothered by it when we got distcc running with a good amount of cores. Thanks for your effort. :) I'll try and make something with the things I've learned (I'm thinking of making some functions that propagate usage requirements yet link with INTERFACE or something along those lines, of course only usable for static libs). On Wed, Jul 30, 2014 at 4:51 PM, Brad King wrote: > On 07/30/2014 05:31 AM, Nick Overdijk wrote: > > https://github.com/NickNick/cmake-interface-includes/commits/master > > Thanks. For reference, the summary is: > > cmake_minimum_required(VERSION 2.8.12) > project(FOO CXX) > add_library(foo foo/foo.cpp) > target_include_directories(foo INTERFACE foo) > add_library(bar bar/bar.cpp) > target_link_libraries(bar foo) # reduces parallel compilation > #target_link_libraries(bar INTERFACE foo) # compiles bar without foo reqs > > With CMake 3.0 you might be able to hack something up with INTERFACE > libraries, but that will increase complexity. > > The INTERFACE workaround commented out in the above example is really > only good when no usage requirements need to be propagated. Otherwise, > I think you're stuck with the reduced parallelism until CMake can be > taught to detect when it is safe to drop such dependencies as I > explained earlier. FWIW, I've been building large projects this way > for years and rarely been bothered by this. Usually each library has > so many sources that parallelism within each target is enough. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman-k-williams at uiowa.edu Wed Jul 30 11:06:13 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Wed, 30 Jul 2014 15:06:13 +0000 Subject: [cmake-developers] adding command line flags for CMAKE_MAKE_PROGRAM Message-ID: I was trying to get ExternalProjects generated with the Ninja generator to do a better job of handling multiple CPUs and load, so I tried the na?ve solution below. I needed to add flags to the program named in CMAKE_MAKE_PROGRAM. This is difficult because CMAKE_MAKE_PROGRAM is a string; I can pass it as part of an ExternalProjects? CMAKE_ARGS, but then the resulting build tries to run ?/usr/bin/ninja ?j 32? as the command, instead of adding ?j 32 to ninja?s command line. Any ideas, or am I asking for a CMAKE_MAKE_PROGRAM_FLAGS command? Or to modify the generator? the only alternative is to explicitly set the BUILD_COMMAND for every ExternalProject_add command. #------------------------------ # For ninja generator, propagate ninja flags #------------------------------ if(CMAKE_GENERATOR MATCHES ".*Ninja.*") if(NOT DEFINED PROCESSOR_COUNT) # Unknown: set(PROCESSOR_COUNT 1) # Linux: if(CMAKE_SYSTEM_NAME MATCHES ".*Linux.*") set(cpuinfo_file "/proc/cpuinfo") if(EXISTS "${cpuinfo_file}") file(STRINGS "${cpuinfo_file}" procs REGEX "^processor.: [0-9]+$") list(LENGTH procs PROCESSOR_COUNT) endif() # Mac: elseif(APPLE) find_program(cmd_sys_pro "system_profiler") if(cmd_sys_pro) execute_process(COMMAND ${cmd_sys_pro} OUTPUT_VARIABLE info) string(REGEX REPLACE "^.*Total Number Of Cores: ([0-9]+).*$" "\\1" PROCESSOR_COUNT "${info}") endif() # Windows: elseif(WIN32) set(PROCESSOR_COUNT "$ENV{NUMBER_OF_PROCESSORS}") endif() endif() set(CMAKE_MAKE_PROGRAM ${CMAKE_MAKE_PROGRAM} -l ${PROCESSOR_COUNT}) endif() ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 30 11:35:47 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 11:35:47 -0400 Subject: [cmake-developers] ExternalProject: adding command line flags for CMAKE_MAKE_PROGRAM In-Reply-To: References: Message-ID: <53D910D3.1030209@kitware.com> On 07/30/2014 11:06 AM, Williams, Norman K wrote: > I was trying to get ExternalProjects generated with the Ninja > generator to do a better job of handling multiple CPUs and load, > so I tried the na?ve solution below. For reference in the archives, your previous post about this was here: CMake, Ninja generator, and ExternalProjects http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10543 > I needed to add flags to the program named in CMAKE_MAKE_PROGRAM. The relevant part of the ExternalProject module source is the block that constructs the default BUILD_COMMAND when not using a Makefile generator: # Drive the project with "cmake --build". get_target_property(cmake_command ${name} _EP_CMAKE_COMMAND) if(cmake_command) set(cmd "${cmake_command}") else() set(cmd "${CMAKE_COMMAND}") endif() set(args --build ${binary_dir} --config ${CMAKE_CFG_INTDIR}) At build time, "cmake --build" loads the CMAKE_MAKE_PROGRAM from the CMakeCache.txt of the build tree, at least for the Ninja generator. When running "cmake --build" by hand one can specify additional args: cmake --build . -- $ExtraArgs Everything after the "--" option will be given to the native tool. Perhaps one could add a special-case here when cmake_generator is "Ninja" to extend the "cmake --build" command with th needed options to ninja. > the only alternative is to explicitly set the BUILD_COMMAND for > every ExternalProject_add command. That would also work with existing CMake releases, but would have to be conditional on the generator in use. -Brad From daniele.domenichelli at gmail.com Wed Jul 30 11:57:59 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Wed, 30 Jul 2014 17:57:59 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D8F3FE.2020005@kitware.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> <53D65A1B.3000202@kitware.com> <53D6673D.9080109@gmail.com> <53D8F3FE.2020005@kitware.com> Message-ID: <53D91607.6090300@gmail.com> Hello Brad, On 30/07/14 15:32, Brad King wrote: > Thanks. While reviewing the commits in 'next' again I realized > that assuming paths are relative to CMAKE_BINARY_DIR may not be > correct. Some projects may be nested inside others, and the > CMAKE_BINARY_DIR may not be the proper location for a nested > project. Instead the BUILD_TREE option should be followed by > another argument specifying the base for relative paths, i.e. > the in-build-tree prefix. Ok, looks reasonable but I have a few questions... I never used multiple project calls, so I don't know how it works, would PROJECT_BINARY_DIR be an appropriate replacement for CMAKE_BINARY_DIR? configure_package_config_file has an INSTALL_DESTINATION argument, I was assuming that one would pass that if the destination isn't of the config file isn't CMAKE_BINARY_DIR. In this way if INSTALL_DESTINATION is a relative path, it will consider it relative to CMAKE_BINARY_DIR, like other places in CMake. How would you like me to handle this argument? Should INSTALL_DESTINATION always be relative to CMAKE_BINARY_DIR or should it be relative to BUILD_TREE? Maybe BUILD_TREE is no longer an appropriate name if you can set it to any folder, maybe RELATIVE_DIR or something similar would be more appropriate? Cheers, Daniele From brad.king at kitware.com Wed Jul 30 13:23:18 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 13:23:18 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D91607.6090300@gmail.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> <53D65A1B.3000202@kitware.com> <53D6673D.9080109@gmail.com> <53D8F3FE.2020005@kitware.com> <53D91607.6090300@gmail.com> Message-ID: <53D92A06.80102@kitware.com> On 07/30/2014 11:57 AM, Daniele E. Domenichelli wrote: > I never used multiple project calls, so I don't know how it works, would > PROJECT_BINARY_DIR be an appropriate replacement for CMAKE_BINARY_DIR? No, because we don't know if the most-nested project() call is the right one either. > Should INSTALL_DESTINATION always be relative to CMAKE_BINARY_DIR or > should it be relative to BUILD_TREE? The purpose of INSTALL_DESTINATION is to help the generated file compute the installation prefix relative to itself. Therefore it needs to be treated relative to the same place all other paths will be treated relative to. This is BUILD_TREE when the option is specified. > Maybe BUILD_TREE is no longer an appropriate name if you can set it to > any folder, maybe RELATIVE_DIR or something similar would be more > appropriate? The purpose of the BUILD_TREE option is now to specify a different value to be used anywhere ${CMAKE_INSTALL_PREFIX} is now. I think the name "INSTALL_PREFIX" may be best. This approach generalizes the feature even to the case of preparing a package config file for a prefix besides the current value of CMAKE_INSTALL_PREFIX even when it really will be installed. Basically in the implementation you can replace any occurence of ${CMAKE_INSTALL_PREFIX} with a ${installPrefix} local that is set to either CMAKE_INSTALL_PREFIX or the value of the INSTALL_PREFIX option. -Brad From mantis at public.kitware.com Wed Jul 30 13:30:38 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 30 Jul 2014 13:30:38 -0400 Subject: [cmake-developers] [CMake 0015047]: BundleUtilities' fixup_bundle does not check to see if two libs are the same up to symlinks Message-ID: <7cc31c44d67811d6f81e6ca476284a00@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15047 ====================================================================== Reported By: Jordi Guti?rrez Hermoso Assigned To: ====================================================================== Project: CMake Issue ID: 15047 Category: Modules Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-30 13:30 EDT Last Modified: 2014-07-30 13:30 EDT ====================================================================== Summary: BundleUtilities' fixup_bundle does not check to see if two libs are the same up to symlinks Description: I'm using cmake's BundleUtilities to create an app bundle. I am using homebrew's wxmac package to create an application of my own. With wxmac, my binary links (amongst other things) to /usr/local/lib/libwx_baseu-3.0.dylib /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib But /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib itself also links to libwx_baseu-3.0.dylib, but not to the symlink in /usr/local/lib but to the original in /usr/local/Cellar which actually has a longer but compatible version name: libwx_baseu-3.0.0.1.0.dylib (note the extra dots in the version number). Of course, the 3.0.0.1.0 library is the same as the 3.0 library, as the latter is jus a symlink to the former. Thus BundleUtilities thinks that there is a dependency of a dependency and copies the libwx_baseu library twice, once for 3.0 and again for 3.0.0.1.0 and sets the path twice in my binary. This creates a segfaulty executable. :-( Steps to Reproduce: It's a bit complicated to easily reproduce this. Basically, use fixup_bundle, create a library that links both to foo.dylib and bar.dylib, and make sure that bar.dylib is a symlink to baz.dylib and that foo.dylib itself links to baz. In ASCII art: binary | \ | \ foo bar ..... baz | | \_________________/ where the dots indicate a filesystem symlink and the solid lines indicate dynamic library linking. Additional Information: (aside: homebrew sets up symlinks in /usr/local/lib that point to the actual wxmac libraries in /usr/local/Cellar/wxmac/3.0.1, similar to how most GNU/Linux systems handle /usr/lib and /usr/local/lib ) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-30 13:30 Jordi Guti?rrez HermosoNew Issue ====================================================================== From mantis at public.kitware.com Wed Jul 30 15:05:21 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 30 Jul 2014 21:05:21 +0200 Subject: [cmake-developers] [CMake 0015048]: Semicolon in AIX compiler warning FAIL_REFEX causes it to match other output Message-ID: <82b3f25d7a114c133952dfb74135eec2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15048 ====================================================================== Reported By: Erik Lindahl Assigned To: ====================================================================== Project: CMake Issue ID: 15048 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-30 21:05 CEST Last Modified: 2014-07-30 21:05 CEST ====================================================================== Summary: Semicolon in AIX compiler warning FAIL_REFEX causes it to match other output Description: In CMakeCheckCompilerFlagCommonPatterns.cmake of CMake-3.0, the FAIL_REGEX string for AIX contains a semicolon. This appears to cause the string to be split in two entries (since CMake uses semicolon as a separator for lists). Since the part after the semicolon is merely the word "ignored", any compiler producing that word in the output will have a failure triggered. Steps to Reproduce: We found this when using the Intel 12.1.0 compiler on Windows HPC 2008 since that emits the linker warning "LINK : warning LNK4224: /INCREMENTAL:YES is no longer supported; ignored", which caused the above test to trigger for the "ignored" word. Additional Information: Suggest to replace semicolon with a period to match any character in the regular expression. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-30 21:05 Erik Lindahl New Issue ====================================================================== From daniel at pfeifer-mail.de Wed Jul 30 15:42:56 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 30 Jul 2014 21:42:56 +0200 Subject: [cmake-developers] LZMA support In-Reply-To: <53D8F9ED.40900@kitware.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> <53D8F9ED.40900@kitware.com> Message-ID: 2014-07-30 15:58 GMT+02:00 Brad King : > On 07/23/2014 10:43 AM, Brad King wrote: > > I've merged the topic to 'next' for testing, but without the CPack > > or ExternalProject pieces. Likely some more portability fixes > > will be required after testing on the dashboard. Once that is clean > > I will add the other changes again on top of the revised topic. > > This is all now in master as of commit 6370c90f. I've updated > issues 13072, 13515, 14504, and 14519 accordingly. > Great! I think we should add packaging options like 'CPACK_BINARY_7Z' to 'Modules/CPack.cmake'. Maybe the options should be reordered alphabetically, to make it obvious where to add new package generators. By the way: CPACK_BINARY_IFW should be added to the 'mark_as_advanced' list too. cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CPack.patch Type: text/x-patch Size: 3610 bytes Desc: not available URL: From brad.king at kitware.com Wed Jul 30 16:01:22 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 16:01:22 -0400 Subject: [cmake-developers] LZMA support In-Reply-To: References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> <53D8F9ED.40900@kitware.com> Message-ID: <53D94F12.1030304@kitware.com> On 07/30/2014 03:42 PM, Daniel Pfeifer wrote: > I think we should add packaging options like 'CPACK_BINARY_7Z' to 'Modules/CPack.cmake'. Thanks. Patch applied: CPack: Add lzma-compressed package options http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d93e099 > Maybe the options should be reordered alphabetically, to make it obvious where to add new package generators. Yes, this can be done as a follow-up to the other changes. > By the way: CPACK_BINARY_IFW should be added to the 'mark_as_advanced' list too. Yes, thanks. CPack: Mark CPACK_BINARY_IFW option as advanced http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cabc2cd -Brad From mantis at public.kitware.com Wed Jul 30 16:53:34 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 30 Jul 2014 22:53:34 +0200 Subject: [cmake-developers] [CMake 0015049]: Add detection for Fujitsu compilers Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15049 ====================================================================== Reported By: Erik Lindahl Assigned To: ====================================================================== Project: CMake Issue ID: 15049 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-30 22:53 CEST Last Modified: 2014-07-30 22:53 CEST ====================================================================== Summary: Add detection for Fujitsu compilers Description: Fujitsu users their own compilers (based on an old version of Clang) on K. By default the CMake compiler IDs are set to Unknown, but when using the GNU compatibility flags the Fujitsu compiler adds the _GNUC_ define (bad), although it is not really 100% compatible with GCC-4.1.2. To work around this we manually set the compiler IDs to "Fujitsu", but it is probably a good idea to have this in the default distribution too, which the two attached patches accomplish (tested). Unfortunately the version cannot be extracted from the source level. If you want that, it can be detected from the output with the -V flag. Examples: klogin9$ fccpx -V fccpx: Fujitsu C/C++ Compiler Driver Version 1.2.0 P-id: L30000-07 (Jul 30 2013 08:58:18) K-1.2.0-15 klogin9$ FCCpx -V FCCpx: Fujitsu C/C++ Compiler Driver Version 1.2.0 P-id: L30000-07 (Jul 30 2013 08:58:18) K-1.2.0-15 klogin9$ frtpx -V frtpx: Fujitsu Fortran Driver Version 1.2.0 P-id: L30000-07 (Jul 30 2013 08:57:22) K-1.2.0-15 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-30 22:53 Erik Lindahl New Issue 2014-07-30 22:53 Erik Lindahl File Added: Fujitsu.patch ====================================================================== From bill.hoffman at kitware.com Wed Jul 30 18:10:36 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 30 Jul 2014 18:10:36 -0400 Subject: [cmake-developers] scan-build of CMake Message-ID: <53D96D5C.3080506@kitware.com> I am working on scan-build integration with ctest/CDash and did a build of CMake. The results show up in the warning section of the build: http://open.cdash.org/viewBuildError.php?type=1&buildid=3429991 I excluded a few things in STL, but the rest of this might be worth looking at if anyone has the time. :) -Bill From mantis at public.kitware.com Thu Jul 31 03:49:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 31 Jul 2014 09:49:22 +0200 Subject: [cmake-developers] [CMake 0015050]: Enable OpenMP flag detection with Fujitsu compilers Message-ID: <73bdc7dfc87c0fc0b3891daa8f3cd88a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15050 ====================================================================== Reported By: Erik Lindahl Assigned To: ====================================================================== Project: CMake Issue ID: 15050 Category: CMake Reproducibility: N/A Severity: feature Priority: low Status: new ====================================================================== Date Submitted: 2014-07-31 09:49 CEST Last Modified: 2014-07-31 09:49 CEST ====================================================================== Summary: Enable OpenMP flag detection with Fujitsu compilers Description: The Fujitsu compilers use the flag "-KopenMP" to enable OpenMP, which presently isn't checked by CMake. The attached patch to FindOpenMP.cmake adds it. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-31 09:49 Erik Lindahl New Issue 2014-07-31 09:49 Erik Lindahl File Added: FindOpenMP.cmake.patch ====================================================================== From mantis at public.kitware.com Thu Jul 31 05:24:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 31 Jul 2014 11:24:11 +0200 Subject: [cmake-developers] [CMake 0015051]: Detect more fujitsu compiler warnings Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15051 ====================================================================== Reported By: Erik Lindahl Assigned To: ====================================================================== Project: CMake Issue ID: 15051 Category: CMake Reproducibility: N/A Severity: feature Priority: low Status: new ====================================================================== Date Submitted: 2014-07-31 11:24 CEST Last Modified: 2014-07-31 11:24 CEST ====================================================================== Summary: Detect more fujitsu compiler warnings Description: The attached patch to CMakeCheckCompilerFlagCommonPatterns.cmake adds detection for incorrect suboptions with the Fujitsu compilers. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-31 11:24 Erik Lindahl New Issue 2014-07-31 11:24 Erik Lindahl File Added: CMakeCheckCompilerFlagCommonPatterns.cmake.patch ====================================================================== From nilsgladitz at gmail.com Thu Jul 31 06:55:01 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 31 Jul 2014 12:55:01 +0200 Subject: [cmake-developers] configure_file() missing output file regeneration Message-ID: <53DA2085.2010908@gmail.com> The output file regeneration introduced in ad502502 and refined by 38571f2c does not seem to work with the visual studio (tested 2010, reportedly also 2012) and Ninja generators. I merged the topic "output-tracking" which extends the RunCMake.configure_file test to find out where it actually does/does not work. I have since then found 9465242d which apparently already tried to fix this for Ninja. Nils From brad.king at kitware.com Thu Jul 31 09:12:41 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 31 Jul 2014 09:12:41 -0400 Subject: [cmake-developers] configure_file() missing output file regeneration In-Reply-To: <53DA2085.2010908@gmail.com> References: <53DA2085.2010908@gmail.com> Message-ID: <53DA40C9.7010709@kitware.com> On 07/31/2014 06:55 AM, Nils Gladitz wrote: > I merged the topic "output-tracking" which extends the > RunCMake.configure_file test to find out where it actually does/does not > work. No need for that. Just do "git grep GetOutputFiles" and you will see that no generators even query that except Makefile and Ninja. Therefore Xcode and VS generators are missing this support. -Brad From nilsgladitz at gmail.com Thu Jul 31 09:12:44 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 31 Jul 2014 15:12:44 +0200 Subject: [cmake-developers] configure_file() missing output file regeneration In-Reply-To: <53DA40C9.7010709@kitware.com> References: <53DA2085.2010908@gmail.com> <53DA40C9.7010709@kitware.com> Message-ID: <53DA40CC.1040303@gmail.com> On 07/31/2014 03:12 PM, Brad King wrote: > On 07/31/2014 06:55 AM, Nils Gladitz wrote: >> I merged the topic "output-tracking" which extends the >> RunCMake.configure_file test to find out where it actually does/does not >> work. > > No need for that. Just do "git grep GetOutputFiles" and you will > see that no generators even query that except Makefile and Ninja. > Therefore Xcode and VS generators are missing this support. Are they intentionally left out? Nils From brad.king at kitware.com Thu Jul 31 09:38:10 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 31 Jul 2014 09:38:10 -0400 Subject: [cmake-developers] configure_file() missing output file regeneration In-Reply-To: <53DA40CC.1040303@gmail.com> References: <53DA2085.2010908@gmail.com> <53DA40C9.7010709@kitware.com> <53DA40CC.1040303@gmail.com> Message-ID: <53DA46C2.1030407@kitware.com> On 07/31/2014 09:12 AM, Nils Gladitz wrote: >> No need for that. Just do "git grep GetOutputFiles" and you will >> see that no generators even query that except Makefile and Ninja. >> Therefore Xcode and VS generators are missing this support. > > Are they intentionally left out? I don't think so. However, see below. Actually I just dug in to the history of this and found that the whole feature was attempted and reverted in 2006: ENH: add support for re-running cmake if the cmakefiles change, 2006-04-10 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c06f8e2 ENH: fix re-run of cmake based on configured files that are done with copy if different and never change, 2006-04-11 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa415043 Then the fix that would have made it work was done in 2009 by considering these outputs to be by-products that are expected to exist but not necessarily be newer than the inputs: BUG: Fix OS X AppBundle/FW byproducts dependencies, 2009-02-06 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22827489 Then the original feature was finally restored in 2013: cmMakefile: Track configured files so we can regenerate them, 2013-06-18 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad502502 and later refined as you already mentioned. The problem for VS and Xcode is that these "output" files may not be newer than the inputs, so they cannot be simply listed as build outputs of the rule to re-run CMake or it will run every time. The Makefile generator solves this with the cmake_check_build_system build target that runs every time and does custom analysis: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmake.cxx;hb=v3.0.0#l1971 Such always-run targets do not look clean to IDE builds. -Brad From nilsgladitz at gmail.com Thu Jul 31 09:48:19 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 31 Jul 2014 15:48:19 +0200 Subject: [cmake-developers] configure_file() missing output file regeneration In-Reply-To: <53DA46C2.1030407@kitware.com> References: <53DA2085.2010908@gmail.com> <53DA40C9.7010709@kitware.com> <53DA40CC.1040303@gmail.com> <53DA46C2.1030407@kitware.com> Message-ID: <53DA4923.1050608@gmail.com> On 07/31/2014 03:38 PM, Brad King wrote: > The problem for VS and Xcode is that these "output" files may not > be newer than the inputs, so they cannot be simply listed as build > outputs of the rule to re-run CMake or it will run every time. > The Makefile generator solves this with the cmake_check_build_system > build target that runs every time and does custom analysis: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmake.cxx;hb=v3.0.0#l1971 > > Such always-run targets do not look clean to IDE builds. Hm alright ... 2.8.12 has the following changelog entry: CMake: Removal of configured files will retrigger CMake when issuing a build command From which I took that this was implemented for all generators. But it sounds like this may not actually be possible/feasible. Thanks for clarifying. Nils From sean at rogue-research.com Thu Jul 31 12:09:33 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 31 Jul 2014 12:09:33 -0400 Subject: [cmake-developers] scan-build of CMake In-Reply-To: <53D96D5C.3080506@kitware.com> References: <53D96D5C.3080506@kitware.com> Message-ID: <20140731160933.1222910725@mail.rogue-research.com> On Wed, 30 Jul 2014 18:10:36 -0400, Bill Hoffman said: >I am working on scan-build integration with ctest/CDash and did a build >of CMake. The results show up in the warning section of the build: > >http://open.cdash.org/viewBuildError.php?type=1&buildid=3429991 Sweet! Looking forward to turning that on some of our dashboards. For those that don't know, when Bill refers to 'scan-build' he's talking about the clang static analyzer: Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.hoffman at kitware.com Thu Jul 31 12:16:33 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 31 Jul 2014 12:16:33 -0400 Subject: [cmake-developers] scan-build of CMake In-Reply-To: <20140731160933.1222910725@mail.rogue-research.com> References: <53D96D5C.3080506@kitware.com> <20140731160933.1222910725@mail.rogue-research.com> Message-ID: <53DA6BE1.6000906@kitware.com> On 7/31/2014 12:09 PM, Sean McBride wrote: > Sweet! Looking forward to turning that on some of our dashboards. > > For those that don't know, when Bill refers to 'scan-build' he's talking about the clang static analyzer: > > It is pretty easy to setup. You actually do not need to change ctest or CDash for this one. Just do a normal build, but change the compilers: set(ENV{CC} /usr/share/clang/scan-build/ccc-analyzer) set(ENV{CXX} /usr/share/clang/scan-build/c++-analyzer) Then all the warnings just show up in the build warnings. You can even exclude things like this: set(CTEST_CUSTOM_WARNING_EXCEPTION ".*stl_uninitialized.h:75:19: warning: Forming reference to null pointer.*" ".*stl_vector.h:771:9: warning: Returning null reference.*" "warning: Value stored to 'yymsg' is never read" "warning: Value stored to 'yytoken' is never read" ) I just found a bug from one of these already. :) -Bill From mantis at public.kitware.com Thu Jul 31 13:48:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 31 Jul 2014 13:48:47 -0400 Subject: [cmake-developers] [CMake 0015052]: INTERFACE_INCLUDE_DIRECTORIES does not allow non-existent directories, but INCLUDE_DIRECTORIES does Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15052 ====================================================================== Reported By: dpantele Assigned To: ====================================================================== Project: CMake Issue ID: 15052 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-31 13:48 EDT Last Modified: 2014-07-31 13:48 EDT ====================================================================== Summary: INTERFACE_INCLUDE_DIRECTORIES does not allow non-existent directories, but INCLUDE_DIRECTORIES does Description: It is a duplicate of http://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=14495 , but I think that Stephen Kelly was not right there. When using add_library(IMPORTED) with INTERFACE_INCLUDE_DIRECTORIES CMake checks existence of the directory in the configuration-time. However, if we declare the same path in INCLUDE_DIRECTORY of the dependent target, everything work fine. This is not consistent. Steps to Reproduce: 1. Unzip cmake-include-issue.zip 2. Try to build, build will fail 3. Replace "include(inc1.txt)' on line 25 of CMakeLists.txt with "include(inc2.txt)", effectively replacing set_target_properties(sub PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${source_dir}/include" ) with target_include_directories(main PRIVATE "${source_dir}/include") 4. Now everything works as expected ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-31 13:48 dpantele New Issue 2014-07-31 13:48 dpantele File Added: cmake-include-issue.zip ====================================================================== From gvjung at gmail.com Tue Jul 1 03:41:22 2014 From: gvjung at gmail.com (Greg Jung) Date: Tue, 1 Jul 2014 00:41:22 -0700 Subject: [cmake-developers] FreeType headers almost there but not quite ... Message-ID: I've been debugging the plplot-5.10.0 build under MSYS and finally found, it can all go well only when the "include/freetype2" cflags are manually included in the build.make files (containing the gcc commands) for plfreetype.c and for wingcc.c. This build uses freetype 15.0.9, where include/ft2build.h points to . Despite its presence in pkgconfig/freetype2.pc cflags line, the actual compile command (in build.make) includes "-DUNSINGDLL -I" with nothing attached to the -I. The funny thing, though, is that treatment of the include/freetype2 flag is correct for pango, cairo, etc., all those more complicated packages come in with freetype2 as well where necessary. I bellieve plfreetype and wingcc are the only modules that access freetype directly, without using libraries also dependent on freetype.. I've tried adding include/freetype2 directory to C_includes.rsp files and to flags.make files, that has no effect the CMAKECACHE shows the following: FREETYPE_INCLUDEDIR:INTERNAL=D:/Mingw/msys/1.0/local/include FREETYPE_INCLUDE_DIRS:INTERNAL=D:/Mingw/msys/1.0/local/include/freetype2;D:/Mingw/msys/1.0/local/include FREETYPE_CFLAGS:INTERNAL=-ID:/Mingw/msys/1.0/local/include/freetype2;-ID:/Mingw/msys/1.0/local/include de _CAIRO_STATIC_CFLAGS:INTERNAL=-mms-bitfields;-ID:/Mingw/msys/1.0/local/include/freetype2;-ID:/Mingw/ msys/1.0/local/include;-ID:/Mingw/include/cairo;-ID:/Mingw/include/glib-2.0;-ID:/Mingw/lib/glib-2.0/ include;-ID:/Mingw/include/pixman-1;-ID:/Mingw/include;-ID:/Mingw/include/libpng15 _CAIRO_INCLUDE_DIRS:INTERNAL=D:/Mingw/msys/1.0/local/include/freetype2;D:/Mingw/msys/1.0/local/inclu de;D:/Mingw/include/cairo;D:/Mingw/include/glib-2.0;D:/Mingw/lib/glib-2.0/include;D:/Mingw/include/p ixman-1;D:/Mingw/include;D:/Mingw/include/libpng15 I have no clue about where to search to resolve this, as I am still on the bunny slopes of the CMAKE learning curve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Tue Jul 1 07:47:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 1 Jul 2014 07:47:02 -0400 Subject: [cmake-developers] [CMake 0014999]: Changing Intermediate Directory of Visual Studio 2012 Message-ID: <9c79fccb05b96077485ddab5f84e7183@www.gccxml.org> The following issue has been SUBMITTED. ====================================================================== http://www.gccxml.org/Bug/view.php?id=14999 ====================================================================== Reported By: Ram Singh Assigned To: ====================================================================== Project: CMake Issue ID: 14999 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-07-01 07:47 EDT Last Modified: 2014-07-01 07:47 EDT ====================================================================== Summary: Changing Intermediate Directory of Visual Studio 2012 Description: We want to change the Intermediate Directory of CMake build so that our object files, executables and libraries can be build outside of CMake built files. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-01 07:47 Ram Singh New Issue ====================================================================== From mantis at public.kitware.com Tue Jul 1 14:33:56 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 1 Jul 2014 14:33:56 -0400 Subject: [cmake-developers] [CMake 0015000]: CMakeFindBinUtils always search for install_name_tool even when cross compiling on OSX Message-ID: <9d0eb7eb4ce66edd2e04a7fb3f582dad@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15000 ====================================================================== Reported By: Florent Castelli Assigned To: ====================================================================== Project: CMake Issue ID: 15000 Category: Modules Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-01 14:33 EDT Last Modified: 2014-07-01 14:33 EDT ====================================================================== Summary: CMakeFindBinUtils always search for install_name_tool even when cross compiling on OSX Description: When cross compiling (in my case for Android) from a Mac, CMakeFindBinUtils.cmake searches for a tool called "install_name_tool" required to make changes to Mach-O binaries (which is totally irrelevant to Android dev). This tool might not be installed (it comes with xcode or command line tools on OSX) and thus CMake will fail to generate a project (it issues a fatal error). This "error" is so pervasive that some android toolchain files actually ensure that install_name_tool is available just to pass this check. Fix would require to change the if(APPLE) on line 71 to if(CMAKE_PLATFORM_HAS_INSTALLNAME) which is set in other files when the tool is provided by the toolchain. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-01 14:33 Florent CastelliNew Issue ====================================================================== From florent.castelli at gmail.com Tue Jul 1 14:48:27 2014 From: florent.castelli at gmail.com (Florent Castelli) Date: Tue, 1 Jul 2014 20:48:27 +0200 Subject: [cmake-developers] [PATCH] Only search for install_name_tool if the toolchain has it Message-ID: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> When cross compiling, toolchains won't have install_name_tool, which is provided by Xcode and command line tools on OSX. This is a Mach-O specific utility and not required on all platforms. --- Modules/CMakeFindBinUtils.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Modules/CMakeFindBinUtils.cmake b/Modules/CMakeFindBinUtils.cmake index 829b6ff..5b5bda8 100644 --- a/Modules/CMakeFindBinUtils.cmake +++ b/Modules/CMakeFindBinUtils.cmake @@ -68,7 +68,7 @@ endif() # on Apple there really should be install_name_tool -if(APPLE) +if(CMAKE_PLATFORM_HAS_INSTALLNAME) find_program(CMAKE_INSTALL_NAME_TOOL NAMES install_name_tool HINTS ${_CMAKE_TOOLCHAIN_LOCATION}) if(NOT CMAKE_INSTALL_NAME_TOOL) -- 2.0.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Only-search-for-install_name_tool-if-the-toolchain-h.patch Type: application/octet-stream Size: 973 bytes Desc: not available URL: From sdougherty at barracuda.com Tue Jul 1 16:01:48 2014 From: sdougherty at barracuda.com (Steve Dougherty) Date: Tue, 1 Jul 2014 16:01:48 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <20140626150242.GA29055@megas.kitwarein.com> References: <20140626150242.GA29055@megas.kitwarein.com> Message-ID: <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> When I glance at ctest output, even if all tests passed, my eye catches "failed" before noticing the other things, which gives me a start. To make this less likely to happen this colors the test summary green if all tests succeeded and red if not. Although I have attempted to edit the test regular expressions so that they still pass, I'm missing something about matching escape codes, and a third of them fail. From LastTest.log: Start 1: RunCMake 1/1 MemCheck #1: RunCMake ......................... Passed 0.00 sec ESC[32;1m 100% tests passed, 0 tests failed out of 1 ESC[0m Total Test time (real) = 0.00 sec -- Processing memory checking output: Memory checking results: Test time = 0.11 sec ---------------------------------------------------------- Test Fail Reason: Required regular expression not found.Regex=[ 1/1 MemCheck #1: RunCMake \.+ Passed +[0-9]+\.[0-9]+ sec \\033\[32;1m 100% tests passed, 0 tests failed out of 1 .* -- Processing memory checking output:( ) Memory checking results: ((BullseyeCoverage|==)[^ ]* )*$ ] --- Source/CTest/cmCTestTestHandler.cxx | 13 +++++++++++++ Tests/CTestTestMemcheck/CMakeLists.txt | 4 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/Source/CTest/cmCTestTestHandler.cxx b/Source/CTest/cmCTestTestHandler.cxx index f21d166..b256be0 100644 --- a/Source/CTest/cmCTestTestHandler.cxx +++ b/Source/CTest/cmCTestTestHandler.cxx @@ -583,10 +583,23 @@ int cmCTestTestHandler::ProcessHandler() percent = 99; } + if ( failed.size() ) + { + // Bold red foreground + cmCTestLog(this->CTest, HANDLER_OUTPUT, "\033[31;1m"); + } + else + { + // Bold green foreground + cmCTestLog(this->CTest, HANDLER_OUTPUT, "\033[32;1m"); + } cmCTestLog(this->CTest, HANDLER_OUTPUT, std::endl << static_cast(percent + .5) << "% tests passed, " << failed.size() << " tests failed out of " << total << std::endl); + // Reset formatting to default + cmCTestLog(this->CTest, HANDLER_OUTPUT, "\033[0m"); + if(this->CTest->GetLabelSummary()) { this->PrintLabelSummary(); diff --git a/Tests/CTestTestMemcheck/CMakeLists.txt b/Tests/CTestTestMemcheck/CMakeLists.txt index 8984463..c35e1f7 100644 --- a/Tests/CTestTestMemcheck/CMakeLists.txt +++ b/Tests/CTestTestMemcheck/CMakeLists.txt @@ -54,7 +54,7 @@ set(other_tool_output "((${guard_malloc_output}BullseyeCoverage|==)[^\n]*\n)*") string(REPLACE "\r\n" "\n" ctest_and_tool_outputs " 1/1 MemCheck #1: RunCMake \\.+ Passed +[0-9]+\\.[0-9]+ sec -${guard_malloc_lines} +${guard_malloc_lines}\\\\033\\[32;1m 100% tests passed, 0 tests failed out of 1 .* -- Processing memory checking output:( ) @@ -177,7 +177,7 @@ set_tests_properties(CTestTestMemcheckDummyValgrindIgnoreMemcheck PASS_REGULAR_EXPRESSION "\n2/2 Test #2: RunCMakeAgain .*${ctest_and_tool_outputs}$") set_tests_properties(CTestTestMemcheckDummyBC PROPERTIES - PASS_REGULAR_EXPRESSION "\n1/1 MemCheck #1: RunCMake \\.+ Passed +[0-9]+.[0-9]+ sec\n\n100% tests passed, 0 tests failed out of 1\n(.*\n)?Error parsing XML in stream at line 1: no element found\n") + PASS_REGULAR_EXPRESSION "\n1/1 MemCheck #1: RunCMake \\.+ Passed +[0-9]+.[0-9]+ sec\n\\\\033\\[32;1m\n100% tests passed, 0 tests failed out of 1\n(.*\n)?Error parsing XML in stream at line 1: no element found\n") set_tests_properties(CTestTestMemcheckDummyValgrindInvalidSupFile PROPERTIES PASS_REGULAR_EXPRESSION "\nCannot find memory checker suppression file: ${CTEST_ESCAPED_REALPATH_CMAKE_CURRENT_BINARY_DIR}/does-not-exist\n") -- 2.0.1 =========================================================== DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. From irwin at beluga.phys.uvic.ca Tue Jul 1 16:35:23 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 1 Jul 2014 13:35:23 -0700 (PDT) Subject: [cmake-developers] FreeType headers almost there but not quite ... In-Reply-To: References: Message-ID: On 2014-07-01 00:41-0700 Greg Jung wrote: Hi Greg: Thanks for your interest in PLplot. I suspect this is either an issue concerning how you are using the PLplot build system or an issue with that system itself so I plan to follow up on this question on the appropriate list (plplot-devel) for discussing such issues. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From mantis at public.kitware.com Tue Jul 1 17:11:50 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 1 Jul 2014 17:11:50 -0400 Subject: [cmake-developers] [CMake 0015001]: add_custom_command: inconsistent treatment of escaped quotes Message-ID: <4b90f4570ebd0d21d541f2d2b35c5e6e@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15001 ====================================================================== Reported By: George Sakhnovsky Assigned To: ====================================================================== Project: CMake Issue ID: 15001 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2014-07-01 17:11 EDT Last Modified: 2014-07-01 17:11 EDT ====================================================================== Summary: add_custom_command: inconsistent treatment of escaped quotes Description: I have an add_custom_command COMMAND line where I want to wrap several of the strings in double quotes. cmake src snippet: add_custom_command( TARGET ${target_name} PRE_BUILD COMMAND "\"$(DevEnvDir)tf\"" history "\"$(SolutionDir)\"" /stopafter:1 /recursive > changeset.dat The generated vcxproj file looks as follows. Note that the escaped double quotes made it through quite literally: \"$(DevEnvDir)tf\" history "$(SolutionDir)" /stopafter:1 /recursive > changeset.dat The desired behavior is to have $(DevEnvDir)tf wrapped in double quotes like so: "$(DevEnvDir)tf" history "$(SolutionDir)" /stopafter:1 /recursive > changeset.dat Why does escaping double quotes work for the second string in the line but not the first? Should this be accomplished differently for the first string because it's the actual command? If this is not a bug, what's the workaround? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-01 17:11 George SakhnovskyNew Issue ====================================================================== From ben.boeckel at kitware.com Wed Jul 2 08:13:00 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 2 Jul 2014 08:13:00 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> References: <20140626150242.GA29055@megas.kitwarein.com> <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> Message-ID: <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> On Tue, Jul 01, 2014 at 16:01:48 -0400, Steve Dougherty wrote: > When I glance at ctest output, even if all tests passed, my eye catches > "failed" before noticing the other things, which gives me a start. > > To make this less likely to happen this colors the test summary green > if all tests succeeded and red if not. > > Although I have attempted to edit the test regular expressions so that > they still pass, I'm missing something about matching escape codes, > and a third of them fail. From LastTest.log: Colors should only be output if we're outputting to a TTY. Pipes or redirections should not be colored (they'll only confuse those who don't recognize the escape sequences). CMake also has color routines already, but I don't know off-hand how accessible they are from CTest code (i.e., might be static functions). --Ben From brad.king at kitware.com Wed Jul 2 09:19:15 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Jul 2014 09:19:15 -0400 Subject: [cmake-developers] [PATCH] Only search for install_name_tool if the toolchain has it In-Reply-To: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> References: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> Message-ID: <53B406D3.9030400@kitware.com> On 07/01/2014 02:48 PM, Florent Castelli wrote: > When cross compiling, toolchains won't have install_name_tool, > which is provided by Xcode and command line tools on OSX. > This is a Mach-O specific utility and not required on all platforms. Applied, thanks: OS X: Only search for install_name_tool if the toolchain has it http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3012d20 -Brad From eike at sf-mail.de Wed Jul 2 09:23:15 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 02 Jul 2014 15:23:15 +0200 Subject: [cmake-developers] =?utf-8?q?=5BPATCH=5D_Only_search_for_install?= =?utf-8?q?=5Fname=5Ftool_if_the_toolchain_has_it?= In-Reply-To: <53B406D3.9030400@kitware.com> References: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> <53B406D3.9030400@kitware.com> Message-ID: Am 02.07.2014 15:19, schrieb Brad King: > On 07/01/2014 02:48 PM, Florent Castelli wrote: >> When cross compiling, toolchains won't have install_name_tool, >> which is provided by Xcode and command line tools on OSX. >> This is a Mach-O specific utility and not required on all platforms. > > Applied, thanks: > > OS X: Only search for install_name_tool if the toolchain has it > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3012d20 Probably also remove the comment in the line before? Eike From brad.king at kitware.com Wed Jul 2 09:24:42 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Jul 2014 09:24:42 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> References: <20140626150242.GA29055@megas.kitwarein.com> <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> Message-ID: <53B4081A.1080205@kitware.com> On 07/02/2014 08:13 AM, Ben Boeckel wrote: > Colors should only be output if we're outputting to a TTY. Pipes or > redirections should not be colored (they'll only confuse those who don't > recognize the escape sequences). CMake also has color routines already, > but I don't know off-hand how accessible they are from CTest code (i.e., > might be static functions). Look for uses of "cmsysTerminal_cfprintf" as an example. See its declaration in "Source/kwsys/Terminal.h.in" also. -Brad From brad.king at kitware.com Wed Jul 2 09:43:06 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 02 Jul 2014 09:43:06 -0400 Subject: [cmake-developers] [PATCH] Only search for install_name_tool if the toolchain has it In-Reply-To: References: <9603381F-A5C6-4557-952B-A1977714AED1@gmail.com> <53B406D3.9030400@kitware.com> Message-ID: <53B40C6A.4020703@kitware.com> On 07/02/2014 09:23 AM, Rolf Eike Beer wrote: > Am 02.07.2014 15:19, schrieb Brad King: >> OS X: Only search for install_name_tool if the toolchain has it >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b3012d20 > > Probably also remove the comment in the line before? Yes, revised: OS X: Only search for install_name_tool if the toolchain has it http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=591a7388 Thanks, -Brad From mantis at public.kitware.com Wed Jul 2 12:38:28 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 2 Jul 2014 12:38:28 -0400 Subject: [cmake-developers] [CMake 0015002]: GetPrerequisites : fix objdump usage under non english locale Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15002 ====================================================================== Reported By: Olivier Trichet Assigned To: ====================================================================== Project: CMake Issue ID: 15002 Category: CMake Reproducibility: always Severity: minor Priority: low Status: new ====================================================================== Date Submitted: 2014-07-02 12:38 EDT Last Modified: 2014-07-02 12:38 EDT ====================================================================== Summary: GetPrerequisites : fix objdump usage under non english locale Description: While cross-compile from linux to win32, objdump is used by GetPrerequisites to find dependency dll. It runs : objdump -p some.exe | grep 'DLL Name:' Under non English locale, the output of objdump can be translated. Thus the matching on 'DLL Name:' does not work. The attached patch fix this issue. Steps to Reproduce: 1) Create the CMakeLists.txt file with : include(GetPrerequisites) # Force the function 'get_prerequisites' to use objdump # (Avoid to setup a crosscompiling env unix -> win32) set(gp_tool "objdump") get_prerequisites("cmake-3.0.0-win32-x86.exe" DEPENDENCIES 0 1 "" "") message("Some dependencies should have been found: ${DEPENDENCIES}") 2) wget http://www.cmake.org/files/v3.0/cmake-3.0.0-win32-x86.exe 3) Choose a non english locale from "locale -a" to to setup the variable LC_ALL 4) "LC_ALL=fr cmake ." => dependency dll not found without patch "LC_ALL=C cmake ." => dependency found ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-02 12:38 Olivier TrichetNew Issue 2014-07-02 12:38 Olivier TrichetFile Added: 0001-GetPrerequisites-ensure-objdump-output-is-not-locale.patch ====================================================================== From mantis at public.kitware.com Wed Jul 2 16:29:57 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 2 Jul 2014 16:29:57 -0400 Subject: [cmake-developers] [CMake 0015003]: depend.make ignores files with the same name Message-ID: <8c89406b2ea7eff5864b099a4d0e3c59@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15003 ====================================================================== Reported By: Ryan Curtin Assigned To: ====================================================================== Project: CMake Issue ID: 15003 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-02 16:29 EDT Last Modified: 2014-07-02 16:29 EDT ====================================================================== Summary: depend.make ignores files with the same name Description: I've attached an interesting project that exposes a bug that is similar (but maybe not identical) to http://public.kitware.com/Bug/view.php?id=9354 . This occurred while working on mlpack ( http://www.mlpack.org/ ) which uses CMake, but I have reduced it to the simplest case I can think of. We have a test file, 'test.cpp', which includes two files 'a.hpp' and 'b.hpp'. The file 'a.hpp' includes 'a/a.hpp' which in turn includes 'impl.hpp' located in the directory a/. The file 'b.hpp' includes 'b/b.hpp' which in turn includes 'impl.hpp' located in the directory b/. Then, the CMake configuration just makes a target 'test' that depends on test.cpp, and ideally CMake should figure out all the header dependencies correctly. However, when CMake is used to configure and build the target, the resulting depend.make file associated with the test target only contains a/impl.hpp and not b/impl.hpp. This means I can make changes to b/impl.hpp and recompile, but CMake does not detect the changes. Unfortunately I am not enough of a CMake expert to provide a patch, but I thought it would at least be useful to reproduce the issue. Steps to Reproduce: 1. unpack attached .tar.gz 2. use CMake to configure it 3. build the test target 4. run ./test, look, the output is complaints 5. modify b/impl.hpp and add vulgarities 6. make test 7. run ./test... no vulgarities! Additional Information: I tried with both CMake 2.8 and 3.0, so it is tested against the latest stable release of CMake in both the 2.x and 3.x branches. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-02 16:29 Ryan Curtin New Issue 2014-07-02 16:29 Ryan Curtin File Added: cmake-test.tar.gz ====================================================================== From mantis at public.kitware.com Wed Jul 2 21:49:36 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 2 Jul 2014 21:49:36 -0400 Subject: [cmake-developers] [CMake 0015004]: string(REGEX REPLACE) doesn't correctly anchor regex with ^ for multiple matches Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15004 ====================================================================== Reported By: Chris Foster Assigned To: ====================================================================== Project: CMake Issue ID: 15004 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-02 21:49 EDT Last Modified: 2014-07-02 21:49 EDT ====================================================================== Summary: string(REGEX REPLACE) doesn't correctly anchor regex with ^ for multiple matches Description: string(REGEX REPLACE) doesn't seem to anchor multiple matches correctly with the ^ symbol - subsequent matches seem to be anchored at the start of the next substring. Steps to Reproduce: Run the following cmake script: ----------- string(REGEX REPLACE "^([^-]*-)" "@\\1#" output "foo-1.2-3") message(STATUS "\"${output}\"") ----------- Output is -- "@foo-#@1.2-http://www.cmake.org/Bug/view.php?id=3" so the pattern has matched twice, whereas it should only match the input string once at the start - the expected output is -- "@foo-http://www.cmake.org/Bug/view.php?id=1.2-3" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-02 21:49 Chris Foster New Issue ====================================================================== From gvjung at gmail.com Thu Jul 3 01:10:43 2014 From: gvjung at gmail.com (Greg Jung) Date: Wed, 2 Jul 2014 22:10:43 -0700 Subject: [cmake-developers] FreeType headers almost there but not quite ... resolved Message-ID: Hi again, I'm re-transmitting this to include the mailing list, trim some and add my final analysis. I went back and was able to run cmake without my modifications, and the build proceeded fine ... oh but with_freetype was set to off, so that doesn't count. The same problem that bothered me when I first dove into the CMAKE system is still pestering me: Freetype library. The module in the plplot distribution works fine for only linux/unix hosts: FIND_PATH(FREETYPE_INCLUDE_DIR freetype/config/ftheader.h /usr/local/include/freetype2 /usr/include/freetype2 ) In MSYS case, /usr/local means nothing to CMAKE. The cmake distribution has a (more inclusive, shotgun) approach and I originally modified some (cmake-2.8).cmake modules to a) find the /MSYS and /mingw anchors and set appropriate values for CMAKE_SYSTEM_PREFIX_PATH, CMAKE _SYSTEM_LIBRARY_PATH, etc. in the MSYS case, b) parse environment variable PKG_CONFIG_PATH and use pkg-config facilities in cmake to hook libraries in. Of course that [b)] is what (plplot)/pkg-config.cmake does so I use that, and lib/pkgconfig/freetype.pc blends well into that system. Today I did some searching of the plplot-developer mailing list archives and found that a working downstream change has been in the plplot trunk since march 2014, that instead of FREETYPE_INCLUDE_DIR to use FREETYPE_INCLUDE_CFLAGS for build commands. So all versiopns 13025+ are good with that. The revised (plplot).freetype.cmake actually constructs INCLUDE_CFLAGS from the INCLUDE_DIRS returned by (cmake-2.8).FindFreeType.cmake. This module (FindFreetype) however is of no use to my configuration because it requires a windows GTKM installation to find a freeetype collection. Instead I am MSYS and stubbornly so, windows is only my backdrop. Hence my (cmake) module revisions discussed above are needed to make it all fly. And it does. I attached my cmake modules I use and additionally, pkg-config.cmake modules slightly modified from the plplot code. freetype.cmake is re-cast so that a prior pick-up of freetype can be used, i.e. freetype2.pc, as i do in the custom code. FindFreetype is called if the option is on but it still hasn't been found. Both cases converge to create _INCLUDE_CFLAGS from INCLUDE_DIRS where the (revised as of 13025) plplot build scripting. I re-tested, and include the cmake-gui chatter (cmake.out) from my revised config. In my enhanced cmake I can find freetype under MSYS, but with the modified procedure (call boiler_plate before including freetype) you can use vanilla cmake. ... The attached files include a cmake.out (cmake-gui configuration chatter) with plplot-5.10.0 using replacement .cmakes as found in the tarball, including the "plplot-specific" directory for the plplot/cmake/modules. I now test my vanilla cmake and attach it as "cmakeold.out". Last-second revision: src/CMakeLists.txt line 244 needs to use FREETYPE_INCLUDE_CFLAGS also. On Tue, Jul 1, 2014 at 1:35 PM, Alan W. Irwin wrote: > On 2014-07-01 00:41-0700 Greg Jung wrote: > > Hi Greg: > > Thanks for your interest in PLplot. > > I suspect this is either an issue concerning how you are using the > PLplot build system or an issue with that system itself so I plan to > follow up on this question on the appropriate list (plplot-devel) for > discussing such issues. > > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake.out Type: application/octet-stream Size: 5269 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newcmakemodules.tar.gz Type: application/x-gzip Size: 41053 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmakeold.out Type: application/octet-stream Size: 9273 bytes Desc: not available URL: From mantis at public.kitware.com Thu Jul 3 05:17:54 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 3 Jul 2014 05:17:54 -0400 Subject: [cmake-developers] [CMake 0015005]: Take in account CPACK_INSTALL_SCRIPT when running `cpack` Message-ID: <56e57b2f1083dfa7760fc7508be9b737@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15005 ====================================================================== Reported By: Alex Turbov Assigned To: ====================================================================== Project: CMake Issue ID: 15005 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-03 05:17 EDT Last Modified: 2014-07-03 05:17 EDT ====================================================================== Summary: Take in account CPACK_INSTALL_SCRIPT when running `cpack` Description: According lines 226-258 of the Source/CPack/cmCPackGenerator.cxx file, there are few ways to preinstall files to be packed: 1) via CPACK_INSTALL_COMMANDS variable [InstallProjectViaInstallCommands() function] 2) CPACK_INSTALL_SCRIPT [InstallProjectViaInstallScript()] 3) CPACK_INSTALLED_DIRECTORIES [InstallProjectViaInstalledDirectories()] 4) and finally CPACK_INSTALL_CMAKE_PROJECTS [InstallProjectViaInstallCMakeProjects()] but Source/CPack/cpack.cxx at line 470 checks only 1,3,4 options! so if my configuration file has only CPACK_INSTALL_SCRIPT variable defined, it doesn't want to run w/ the error: .../Source/CPack/cpack.cxx:479 Please specify build tree of the project that uses CMake using CPACK_INSTALL_CMAKE_PROJECTS, specify CPACK_INSTALL_COMMANDS, or specify CPACK_INSTALLED_DIRECTORIES. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-03 05:17 Alex Turbov New Issue ====================================================================== From ericmberge at gmail.com Thu Jul 3 17:19:32 2014 From: ericmberge at gmail.com (Eric Berge) Date: Thu, 3 Jul 2014 16:19:32 -0500 Subject: [cmake-developers] Dependency Checking Issue with Native HPUX 11iv3 make Message-ID: Please consider this as FYI if you're interested in running cmake on HPUX 11iv3: The nightly HPUX 11iv3 test run get an error in the BuildDepends test ( http://open.cdash.org/index.php?project=CMake). This fails virtually all the time, however, for some reason, a successful run does occasionally happen. This appears to be an issue with the native "make" command on HPUX at least according to the unit tests I've done. On the surface this appears to be an error in the LINK_DEPENDS_NO_SHARED property but that is not the case, the problem is more fundamental. In fact, just about the simplest test case for dependency checking (building a program with a single file) needs to be built twice to recognize that it is up-to-date. My test case ultimately was simply: ------------------------------------------------------------------- cmake_minimum_required(VERSION 2.8.12.2) project(MyBuildDepends) add_executable(prog prog.c) -------------------------------------------------------------------- With this, I run the native "make" command twice and, each time it will re-link "prog": -------------------------------------------------------------------- # cmake .. -- The C compiler identification is HP 6.25.0 -- The CXX compiler identification is HP 6.25.0 -- Check for working C compiler: /bin/cc -- Check for working C compiler: /bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /bin/c++ -- Check for working CXX compiler: /bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/eberge/projects/cmake/BuildDepends-failure/testcase2/build # make Scanning dependencies of target prog [100%] Building C object CMakeFiles/prog.dir/prog.c.o Linking C executable prog [100%] Built target prog # make Linking C executable prog [100%] Built target prog # make [100%] Built target prog # -------------------------------------------------------------------- Actually the odd thing is that it appears to have a "domino effect" where the first "make" builds the .o and links the executable, the 2nd only links the executable, and the last will finally do nothing. Since I had gmake on the system I gave that a try, and gmake works just fine. I'm not really looking for a solution for this, but just in case others run into problems on HPUX 11iv3 I thought it was worth saving you the hours it look me to run this down. For now I plan on setting CMAKE_MAKE_PROGRAM to gmake to allow the nightly 11iv3 tests to run successfully (but we'll see how well that expectation pans out tonight...). I did look around for a potential bugfix for make in HPUX but I didn't find anything but that might be because I don't know how to navigate the HPUX labyrith :-) Eric Berge -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Jul 4 02:42:54 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 4 Jul 2014 02:42:54 -0400 Subject: [cmake-developers] [CMake 0015006]: AUTORCC doesn't work with OBJECT library Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15006 ====================================================================== Reported By: sudakov_ivan Assigned To: ====================================================================== Project: CMake Issue ID: 15006 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-04 02:42 EDT Last Modified: 2014-07-04 02:42 EDT ====================================================================== Summary: AUTORCC doesn't work with OBJECT library Description: I wrote code: "add_library(foo OBJECT foo.cpp foo.rcc)". It doesn't compile by cmake. Can I use AUTORCC with OBJECT library? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-04 02:42 sudakov_ivan New Issue ====================================================================== From raffi.enficiaud at free.fr Fri Jul 4 20:02:01 2014 From: raffi.enficiaud at free.fr (Raffi Enficiaud) Date: Sat, 5 Jul 2014 02:02:01 +0200 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: <5347EFBF.7030403@kitware.com> References: <90AF0BC5-0EEE-4B39-9779-6CCA83A63E45@free.fr> <531763EF.60406@kitware.com> <05218E8A-75CB-48E6-84FE-54011F6B8DF9@free.fr> <5318A7DB.8050608@kitware.com> <32646FBF-9528-421E-885C-124ECD50700F@free.fr> <5347EFBF.7030403@kitware.com> Message-ID: Hi, Sorry for the delayed answer. On 11 Apr 2014, at 15:35, Brad King wrote: >> I avoided using the new syntax of cmake 3.x because I am still using 2.8.12 >> and I also would like ppl to get this new package and run it on older versions. > > If it is going to be added upstream it needs to have the appropriate > documentation syntax. You can still use comment blocks starting in > '#' on every line as most modules currently do and it will work with > 2.8.12. Sorry for the misunderstanding. It does use SPHINX syntax. I was mentioning the fact that I cannot use block comments like #[========================================[.rst: .. command:: xxx_do_something #]========================================] because it is not compatible with cmake 2.8. All doc lines are prefixed with # instead. > >> The current solution I am seeing now is to do a test on a cmake >> script that does the job of launching the command and flushing >> the log file onto the console. > > Many of our tests use "cmake -P" to run a cmake script that performs > the test inside. You can use -Dvar=${val} before the -P option to > pass options to the script, such as $. Done: this is the add_matlab_unit_test function. In fact, I think I can remove the log files since they are redundant with the tests logs. What do you think? > >> - Is it ok if we create log files of leave them onto the disk? > > Yes, but they should be inside the CMake build tree so there are > no side effects left when the tree is removed. Cool. This is what it does. > >> two modes for querying the registry: x86 and x64 modes. >> This is not very clear to me what I should do on that: > > The find_library command expands registry values with the view > that matches the target architecture. The find_program command > looks at the matching architecture first and then the other one: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v3.0.0-rc3#l347 > > This is how most of the modules deal with the difference. I'm > not familiar enough with matlab to say what should be done here. Well, this is not exactly what I am doing in fact with this module. I query the registry for all entries below a specific registry key, instead of brute-force checking all the possible keys. Now I am using CMAKE_CL_64 for switching the query on the x86 or x64 mode. > Thanks, > -Brad > I added a function add_matlab_mex that is like a add_library for creating MEX (compiled) extensions. There is an option to this function called REDUCE_VISIBILITY which deals with symbols collision between the library shipped with Matlab and the one the MEX file links to (Unix only). Basically, with this option on, all symbols of the MEX file are hidden, which is more or less what is happening on Windows. I attach to this email the updated files. -------------- next part -------------- A non-text attachment was scrubbed... Name: FindMatlab_TestsRedirect.cmake Type: application/octet-stream Size: 1743 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindMatlab.cmake Type: application/octet-stream Size: 37262 bytes Desc: not available URL: -------------- next part -------------- So far I am not sure how my implementation is compatible with the previous FindMatlab package. The requirements are to define the same variables, right? Is there anything else? BTW, is there any variable that tells the current cmake list, even in function in packages? The add_matlab_unittest is a function calling FindMatlab_TestsRedirect.cmake in script mode. When I use CMAKE_CURRENT_LIST_DIR, it takes the value of the cmake file calling the function. I would like to reference the call to FindMatlab_TestsRedirect.cmake relatively to FindMatlab.cmake. Best, Raffi From mantis at public.kitware.com Sat Jul 5 05:00:02 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 5 Jul 2014 05:00:02 -0400 Subject: [cmake-developers] [CMake 0015007]: [patch] Imagemagick detection stlli broken with multi-arch imagemagick Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15007 ====================================================================== Reported By: broucari Assigned To: ====================================================================== Project: CMake Issue ID: 15007 Category: Modules Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-07-05 05:00 EDT Last Modified: 2014-07-05 05:00 EDT ====================================================================== Summary: [patch] Imagemagick detection stlli broken with multi-arch imagemagick Description: Imagemagick detection is still broken with cmake. Indeed some headers are installed under arch dependant dir and it need to specify CFLAGS in order to get quantum selection. May be related to http://www.cmake.org/Bug/view.php?id=14012 Reported downstream as: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747907 I have made an untested patch using pkg-config. Please fix it, it lead to multiple FTBFS. Thanks Steps to Reproduce: Download recent imagemagick from debian experimental, and try to compile libtuxcap See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747908 Additional Information: Block newer imagemagick in experimental. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-05 05:00 broucari New Issue 2014-07-05 05:00 broucari File Added: Fix-imagemagick-multiarch ====================================================================== From joubert.sy at gmail.com Sat Jul 5 09:30:07 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Sat, 05 Jul 2014 15:30:07 +0200 Subject: [cmake-developers] [patch] Support for swig 3.0 Message-ID: <53B7FDDF.5090801@gmail.com> Hi all, Please consider this patch that makes swig 3.0 supported by the FindSWIG module. Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-swig-3.0-application.patch Type: text/x-patch Size: 1149 bytes Desc: not available URL: From mantis at public.kitware.com Sat Jul 5 23:09:44 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 6 Jul 2014 04:09:44 +0100 Subject: [cmake-developers] [CMake 0015008]: Fix CMakeExpandImportedTargets to avoid Error on non-existent target in get_target_property. Message-ID: <6d0c3dbbe756fbbb99c5d7b7f1bb4660@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15008 ====================================================================== Reported By: Jean-Christophe Fillion-Robin Assigned To: ====================================================================== Project: CMake Issue ID: 15008 Category: CMake Reproducibility: always Severity: tweak Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-06 04:09 WAT Last Modified: 2014-07-06 04:09 WAT ====================================================================== Summary: Fix CMakeExpandImportedTargets to avoid Error on non-existent target in get_target_property. Description: CMake Warning (dev) at cmake/CMakeExpandImportedTargets.cmake:66 (get_target_property): Policy CMP0045 is not set: Error on non-existent target in get_target_property. Run "cmake --help-policy CMP0045" for policy details. Use the cmake_policy command to set the policy and suppress this warning. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-06 04:09 Jean-Christophe Fillion-RobinNew Issue ====================================================================== From schueller at phimeca.com Sun Jul 6 15:34:21 2014 From: schueller at phimeca.com (Julien Schueller) Date: Sun, 6 Jul 2014 21:34:21 +0200 (CEST) Subject: [cmake-developers] [patch] Support for swig 3.0 In-Reply-To: <53B7FDDF.5090801@gmail.com> References: <53B7FDDF.5090801@gmail.com> Message-ID: <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> This is curious, SWIG does not provide an executable named "swig3.0". Where did you get swig from ? ----- Mail original ----- > De: "Sylvain Joubert" > ?: cmake-developers at cmake.org > Envoy?: Samedi 5 Juillet 2014 15:30:07 > Objet: [cmake-developers] [patch] Support for swig 3.0 > > Hi all, > > Please consider this patch that makes swig 3.0 supported by the FindSWIG > module. > > Sylvain > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Julien Schueller Phimeca Engineering www.phimeca.com From joubert.sy at gmail.com Sun Jul 6 16:43:45 2014 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Sun, 06 Jul 2014 22:43:45 +0200 Subject: [cmake-developers] [patch] Support for swig 3.0 In-Reply-To: <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> References: <53B7FDDF.5090801@gmail.com> <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> Message-ID: <53B9B501.50505@gmail.com> Le 06/07/2014 21:34, Julien Schueller a ?crit : > This is curious, SWIG does not provide an executable named "swig3.0". > Where did you get swig from ? > I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0' package. This package provides the '/usr/bin/swig3.0' executable. From schueller at phimeca.com Mon Jul 7 06:17:59 2014 From: schueller at phimeca.com (Julien Schueller) Date: Mon, 7 Jul 2014 12:17:59 +0200 (CEST) Subject: [cmake-developers] [patch] Support for swig 3.0 In-Reply-To: <53B9B501.50505@gmail.com> References: <53B7FDDF.5090801@gmail.com> <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> <53B9B501.50505@gmail.com> Message-ID: <2058949983.3795548.1404728279560.JavaMail.zimbra@phimeca.com> What's the point on renaming it ? installing multiple versions ? what's the point ? I'd say SWIG is rather a very stable utility. You can safely symlink to /usr/bin/swig. ----- Mail original ----- > De: "Sylvain Joubert" > ?: cmake-developers at cmake.org > Envoy?: Dimanche 6 Juillet 2014 22:43:45 > Objet: Re: [cmake-developers] [patch] Support for swig 3.0 > > Le 06/07/2014 21:34, Julien Schueller a ?crit : > > This is curious, SWIG does not provide an executable named "swig3.0". > > Where did you get swig from ? > > > > I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0' > package. This package provides the '/usr/bin/swig3.0' executable. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Julien Schueller Phimeca Engineering www.phimeca.com From brad.king at kitware.com Mon Jul 7 09:22:21 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 07 Jul 2014 09:22:21 -0400 Subject: [cmake-developers] [patch] Support for swig 3.0 In-Reply-To: <2058949983.3795548.1404728279560.JavaMail.zimbra@phimeca.com> References: <53B7FDDF.5090801@gmail.com> <729139308.3369982.1404675261652.JavaMail.zimbra@phimeca.com> <53B9B501.50505@gmail.com> <2058949983.3795548.1404728279560.JavaMail.zimbra@phimeca.com> Message-ID: <53BA9F0D.9020004@kitware.com> On 07/07/2014 06:17 AM, Julien Schueller wrote: > What's the point on renaming it ? installing multiple versions ? what's the point ? > > ----- Mail original ----- >> I'm using Debian unstable, SWIG 3.0 is packaged under the 'swig3.0' >> package. This package provides the '/usr/bin/swig3.0' executable. This is a very common convention in distro packaging and is supported by many of our find modules. FindSWIG already looks for "swig2.0" so it makes sense to also look for "swig3.0". I've applied the patch: FindSWIG: Add support for swig 3.0 application http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7400695e Thanks, -Brad From brad.king at kitware.com Mon Jul 7 10:51:38 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 07 Jul 2014 10:51:38 -0400 Subject: [cmake-developers] Introduction and volunteering for the Matlab package In-Reply-To: References: <90AF0BC5-0EEE-4B39-9779-6CCA83A63E45@free.fr> <531763EF.60406@kitware.com> <05218E8A-75CB-48E6-84FE-54011F6B8DF9@free.fr> <5318A7DB.8050608@kitware.com> <32646FBF-9528-421E-885C-124ECD50700F@free.fr> <5347EFBF.7030403@kitware.com> Message-ID: <53BAB3FA.5080206@kitware.com> Hi Raffi, Thanks for your continuing work on this module. I've made some whitespace and quoting tweaks to the files. See attached updated versions. I also renamed the test helper to not start in "Find" since no one should call find_package(Matlab_TestsRedirect). See further comments below. On 07/04/2014 08:02 PM, Raffi Enficiaud wrote: >> Many of our tests use "cmake -P" to run a cmake script that performs >> the test inside. You can use -Dvar=${val} before the -P option to >> pass options to the script, such as $. > > Done: this is the add_matlab_unit_test function. In fact, I think I can > remove the log files since they are redundant with the tests logs. I see no problem with that, but I'm not familiar with the tools. > I added a function add_matlab_mex that is like a add_library Please make all APIs start in "matlab_". The documentation blocks for each command also need to start in "#.rst:" #.rst: # .. command:: add_matlab_mex or they will not be included in the processed documentation. > for creating MEX (compiled) extensions. There is an option to this > function called REDUCE_VISIBILITY I see that implemented here: > if(HAS_VISIBILITY_INLINE_HIDDEN) > target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility-inlines-hidden") > endif() > if(HAS_VISIBILITY_HIDDEN) > target_compile_options(${${prefix}_NAME} PRIVATE "-fvisibility=hidden") > endif() An upstream version of the module should use the builtin features for visibility settings: http://www.cmake.org/cmake/help/v3.0/prop_tgt/LANG_VISIBILITY_PRESET.html http://www.cmake.org/cmake/help/v3.0/prop_tgt/VISIBILITY_INLINES_HIDDEN.html > # set(MATLAB_ADDITIONAL_VERSIONS > # "release_name1" "corresponding_version1" > # "release_name2" "corresponding_version2" > # ... > # ) Rather than relying on matched pairs, perhaps use "=" to separate: # set(MATLAB_ADDITIONAL_VERSIONS # "release_name1=corresponding_version1" # "release_name2=corresponding_version2" ? > I am not sure how my implementation is compatible with the previous > FindMatlab package. The requirements are to define the same variables, > right? Is there anything else? It needs to produce the same result variables and also respond to the old "input" variables (like find_ command cached results) that the old module did. That way existing build scripts can continue to work. > +# * ``MATLAB_USER_ROOT`` the root of the Matlab installation. This is given by the user. This should be documented in its own section of variables that the user can set to control the search. See FindZLIB for example. > + # list the keys under HKEY_LOCAL_MACHINE\SOFTWARE\mathworks but the call to reg does not work > + # from cmake, curiously, as is. The command provides the desired result under the command line though. > + # Fix: this is because "/reg:64" should appended to the command, otherwise it gets on the 32 bits software key (curiously again) This is because it gets the registry view of the calling CMake unless you tell it what view to use. > + find_program(MATLAB_REG_EXE_LOCATION "reg") > + file(TO_NATIVE_PATH ${MATLAB_REG_EXE_LOCATION} MATLAB_REG_EXE_LOCATION) The second line should not be needed. The execute_process command will take care of the path format. > + if((NOT DEFINED MATLAB_USER_ROOT) OR (NOT MATLAB_USER_ROOT)) This can be shortened to if(NOT MATLAB_USER_ROOT) > + if(NOT ${Matlab_PROGRAM}) and this to if(NOT Matlab_PROGRAM) > BTW, is there any variable that tells the current cmake list, > even in function in packages? In the attached version I added set(_FindMatlab_SELF_DIR "${CMAKE_CURRENT_LIST_DIR}") to the top of the file to save the location of the file for re-use inside function calls later. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: MatlabTestsRedirect.cmake Type: text/x-cmake Size: 1739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FindMatlab.cmake Type: text/x-cmake Size: 36956 bytes Desc: not available URL: From tim.jenks at eegeo.com Tue Jul 8 08:46:01 2014 From: tim.jenks at eegeo.com (Tim Jenks) Date: Tue, 8 Jul 2014 12:46:01 +0000 (UTC) Subject: [cmake-developers] Who does CMake contract work? References: <531889FF.7040504@kitware.com> Message-ID: > > Kitware has been offering CMake consulting since we created CMake. > Information can be found here: > > http://cmake.org/cmake/help/support.html > > Vince, I also sent you an email off list. This looks like a great > addition to CMake, and we would love to help. > > Thanks. > > -Bill > * snip * > > Modify open source CMake to be able to generate NSight Tegra project files. > > Vince I would also be interested in any information regarding nsight tegra solution generation using cmake. Did anything come of this thread? From mantis at public.kitware.com Wed Jul 9 07:14:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 9 Jul 2014 07:14:51 -0400 Subject: [cmake-developers] [CMake 0015011]: problem to find non-standard ncurses.h location Message-ID: <82a5d3937e85f6eecde21d8e63cc1cee@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15011 ====================================================================== Reported By: hsk Assigned To: ====================================================================== Project: CMake Issue ID: 15011 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-09 07:14 EDT Last Modified: 2014-07-09 07:14 EDT ====================================================================== Summary: problem to find non-standard ncurses.h location Description: i have installed gnu ncurses (and several other libraries) under separate location; os: solaris10, compiler: sunstudio 12.2 building cmake 2.8.x worked using env \ CC=cc \ CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \ CXX=CC \ CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \ LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' \ CPPFLAGS=-I/var/imb/include \ ./bootstrap --prefix=/var/imb; gmake with cmake 3.0, the "gmake" step fails: cmake-3.0.0/Source/CursesDialog/form/form.h", line 46: cannot find include file: and -I/var/imb/include must be explicitly added to CFLAGS / CXXFLAGS for ncurses.h to be found, i.e., i have to use env \ CC=cc \ CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \ CXX=CC \ CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \ LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' \ CPPFLAGS=-I/var/imb/include \ ./bootstrap --prefix=/var/imb; gmake imho, the value of CPPFLAGS should be honoured here ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-09 07:14 hsk New Issue ====================================================================== From tim at klingt.org Wed Jul 9 09:40:54 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 09 Jul 2014 15:40:54 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory Message-ID: cfbundles are currently not installed as directory, but the binary from Contents/MacOS is directly installed to the destination. attached patch fixes the issue. thanks, tim -------------- next part -------------- >From b021da36ec9c72cc6410a95ce81a177a87f6f232 Mon Sep 17 00:00:00 2001 From: Tim Blechmann Date: Wed, 9 Jul 2014 15:33:25 +0200 Subject: [PATCH] InstallTarget: install CFBundles with complete directory --- Source/cmInstallTargetGenerator.cxx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx index 7a39f45..93c0d63 100644 --- a/Source/cmInstallTargetGenerator.cxx +++ b/Source/cmInstallTargetGenerator.cxx @@ -213,6 +213,20 @@ void cmInstallTargetGenerator::GenerateScriptForConfig(std::ostream& os, filesFrom.push_back(from1); filesTo.push_back(to1); } + else if(this->Target->IsCFBundleOnApple()) + { + // Install the whole app bundle directory. + type = cmInstallType_DIRECTORY; + literal_args += " USE_SOURCE_PERMISSIONS"; + + std::string targetNameBase = targetName.substr(0, targetName.find_first_of("/")); + + std::string from1 = fromDirConfig + targetNameBase; + std::string to1 = toDir + targetNameBase; + + filesFrom.push_back(from1); + filesTo.push_back(to1); + } else { bool haveNamelink = false; -- 2.0.1 From brad.king at kitware.com Wed Jul 9 10:02:48 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 10:02:48 -0400 Subject: [cmake-developers] NVidia Nsight Tegra (was: Who does CMake contract work?) In-Reply-To: References: <531889FF.7040504@kitware.com> Message-ID: <53BD4B88.5060508@kitware.com> On 07/08/2014 08:46 AM, Tim Jenks wrote: > I would also be interested in any information regarding nsight tegra > solution generation using cmake. > > Did anything come of this thread? We ended up working with NVIDIA directly and have produced a draft of support for Nsight Tegra with Visual Studio. It is still a work in progress but I've attached the current draft patch series (they apply on master as of 487b6ccd, and perhaps more recent versions too). Limitations of the current draft are documented in patch 0004. With these patches and NVIDIA Nsight Tegra Visual Studio Edition installed, new generator variants are available: Visual Studio 12 2013 Tegra-Android Visual Studio 11 2012 Tegra-Android Visual Studio 10 2010 Tegra-Android A non-default Android NDK toolchain may be selected at the command-line, e.g. cmake -G "Visual Studio 12 2013 Tegra-Android" -T clang-3.4 ... or using a CMAKE_TOOLCHAIN_FILE that sets CMAKE_GENERATOR_TOOLSET. Feedback is welcome. Thanks, -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-VS-Make-MS-tool-specific-options-conditional.patch Type: text/x-diff Size: 10999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-VS-Add-Tegra-Android-platform-variant-of-VS-10-gener.patch Type: text/x-diff Size: 8947 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-VS-Detect-compiler-id-of-Nsight-Tegra-Android-toolch.patch Type: text/x-diff Size: 5832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-VS-Teach-vcxproj-generation-about-the-Tegra-Android-.patch Type: text/x-diff Size: 6096 bytes Desc: not available URL: From brad.king at kitware.com Wed Jul 9 11:09:01 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 11:09:01 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: Message-ID: <53BD5B0D.4000708@kitware.com> On 07/09/2014 09:40 AM, Tim Blechmann wrote: > cfbundles are currently not installed as directory, but the binary from > Contents/MacOS is directly installed to the destination. > > attached patch fixes the issue. Thanks. I do not understand this line: > + std::string targetNameBase = targetName.substr(0, targetName.find_first_of("/")); Why do we need to look for the first slash? Also, look earlier in that function for the blocks starting in: // Handle OSX Bundles. if(this->Target->IsAppBundleOnApple()) and else if(this->Target->IsFrameworkOnApple()) Those cases do special handling for the post-installation tweaks. Is something similar needed here? -Brad From brad.king at kitware.com Wed Jul 9 11:12:14 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 11:12:14 -0400 Subject: [cmake-developers] cost of usage requirements In-Reply-To: <53986BDC.7090707@kitware.com> References: <20140608225611.GC18896@megas.kitwarein.com> <8D151EF9D6FCEA2-26D4-1169@webmail-d299.sysops.aol.com> <20140610171757.GA3906@megas.kitwarein.com> <53986BDC.7090707@kitware.com> Message-ID: <53BD5BCE.2020204@kitware.com> On 06/11/2014 10:46 AM, Brad King wrote: > Here is a sscce:: > > cmake_minimum_required(VERSION 2.8.9) > project(ManyLibs C) > set(LibPrev) > foreach(n RANGE 100) > add_library(Lib${n} SHARED lib.c) > target_link_libraries(Lib${n} LINK_PUBLIC ${LibPrev}) > set(LibPrev Lib${n}) > endforeach() A similar case also appears when building VTKWikiExamples as discussed on the cmake user list here: cmake 3.0 memory usage on VTKWikiExamples http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/49910/focus=49922 Memory usage explodes during generation and CMake sometimes runs out and crashes. -Brad From ben.boeckel at kitware.com Wed Jul 9 11:23:02 2014 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 9 Jul 2014 11:23:02 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BD5B0D.4000708@kitware.com> References: <53BD5B0D.4000708@kitware.com> Message-ID: <20140709152302.GA30351@megas.kitwarein.com> On Wed, Jul 09, 2014 at 11:09:01 -0400, Brad King wrote: > > + std::string targetNameBase = targetName.substr(0, targetName.find_first_of("/")); Not that this is performance-sensitive region, but in the pursuit removing bad patterns to avoid copy/paste issues in the future: std::string targetNameBase = targetName.resize(targetName.find('/')); is better, though the resize might not be doable since there's a check for npos that is necessary if the targetName doesn't have a slash in it. The find_first_of(one_char_string) should definitely be find(one_char) or find_first_of(one_char). Of course, assuming this line survives to the final patch. Thanks, --Ben From tim at klingt.org Wed Jul 9 11:30:46 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 09 Jul 2014 17:30:46 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BD5B0D.4000708@kitware.com> References: <53BD5B0D.4000708@kitware.com> Message-ID: >> cfbundles are currently not installed as directory, but the binary from >> Contents/MacOS is directly installed to the destination. >> >> attached patch fixes the issue. > > Thanks. > > I do not understand this line: > >> + std::string targetNameBase = targetName.substr(0, targetName.find_first_of("/")); > > Why do we need to look for the first slash? targetName is: ${BundleName}${BundleExtension}/Contents/MacOS/${BundleName} we basically want to find ${BundleName}. i did not find any way to determine this information from the Target. > Also, look earlier in that function for the blocks starting in: > > // Handle OSX Bundles. > if(this->Target->IsAppBundleOnApple()) > > and > > else if(this->Target->IsFrameworkOnApple()) > > Those cases do special handling for the post-installation tweaks. > Is something similar needed here? i wonder: which tweaks are they? i've seen the comments, but failed to understand, what kind of post-install tweaks they add, as it is mainly about changing source and destinations. in my use-case it seems to work, but of course i might be missing something ... cheers, tim From brad.king at kitware.com Wed Jul 9 11:44:23 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 11:44:23 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: <53BD5B0D.4000708@kitware.com> Message-ID: <53BD6357.1030108@kitware.com> On 07/09/2014 11:30 AM, Tim Blechmann wrote: >> Why do we need to look for the first slash? > > targetName is: > ${BundleName}${BundleExtension}/Contents/MacOS/${BundleName} Okay, thanks. >> Those cases do special handling for the post-installation tweaks. > > i wonder: which tweaks are they? It's things like running "strip" on the executable file. The line filesTo.push_back(to1); needs to add the path to the executable file, not the directory. The filesTo vector is used only for tweaks and not for generating the main install rules. IIUC we should use std::string to1 = toDir + targetName; for CFBundles to get the location of the installed binary file. Thanks, -Brad From tim at klingt.org Wed Jul 9 11:52:47 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 09 Jul 2014 17:52:47 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BD6357.1030108@kitware.com> References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> Message-ID: >>> Those cases do special handling for the post-installation tweaks. >> >> i wonder: which tweaks are they? > > It's things like running "strip" on the executable file. > > The line > > filesTo.push_back(to1); > > needs to add the path to the executable file, not the directory. > The filesTo vector is used only for tweaks and not for generating > the main install rules. IIUC we should use > > std::string to1 = toDir + targetName; > > for CFBundles to get the location of the installed binary file. ah, i see ... double-checked and this works for me! shall i update the patch? cheers, tim From brad.king at kitware.com Wed Jul 9 12:48:45 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 09 Jul 2014 12:48:45 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> Message-ID: <53BD726D.4030303@kitware.com> On 07/09/2014 11:52 AM, Tim Blechmann wrote: > shall i update the patch? Yes, so that we know the updated version works for what you need. Please also include a change to use Ben's suggestion of targetName.find('/') instead of find_first_of. Thanks, -Brad From konstantin at podsvirov.pro Wed Jul 9 13:30:50 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 09 Jul 2014 21:30:50 +0400 Subject: [cmake-developers] CPack IFW generator Message-ID: <2019241404927050@web7g.yandex.ru> Hello dear developers! And again CPack IFW generator!!! This generator is not part of CMake, but I hope that soon it will become possible. This letter I once again want to awaken interest in the creation of new cross-platform the binary installer is based on Qt Framework Installer tools (http://qt-project.org/doc/qtinstallerframework/index.html) (Sorry for my English. I use a translator) I already appeared here some time ago: http://public.kitware.com/pipermail/cmake-developers/2014-May/010430.html I received some recommendations and considered them. With each commit generator becomes better. As before you can clone the code for the study: git clone git://podsvirov.pro/cmake/cpackifwgenerator.git Or check out the code in your browser: http://git.podsvirov.pro/?p=cmake/cpackifwgenerator.git;a=summary In the Wiki I found an example of creating a binary instalatorow: http://cmake.org/Wiki/CMake:Component_Install_With_CPack My generator also copes with this task. Here's how it looks in Linux and Windows: http://ifw.podsvirov.pro/cmake/cpackifw-componentexample-linux.png http://ifw.podsvirov.pro/cmake/cpackifw-componentexample-windows.png I strive to create the binary installer CMake using a new generator. I already have the achievements. Created installers produce the set of all that was specified in the install(...)but do not create shortcuts. Version of CMake (CPack IFW generator) collected them available for Linux and Windows now: http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-linux-i686.run http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-windows-x64.exe http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-windows-x86.exe Please test these installers and write your comments. It is not excluded that in the folder http://ifw.podsvirov.pro/cmake may be something useful. I've created accounts Mantis and CDash. Git push access to git at cmake.org:cmake.git I do not have. With respect Konstantin Podsvirov From tim at klingt.org Wed Jul 9 14:02:00 2014 From: tim at klingt.org (Tim Blechmann) Date: Wed, 09 Jul 2014 20:02:00 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BD726D.4030303@kitware.com> References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> <53BD726D.4030303@kitware.com> Message-ID: >> shall i update the patch? > > Yes, so that we know the updated version works for what you need. > Please also include a change to use Ben's suggestion of > > targetName.find('/') > > instead of find_first_of. attached! thanks a lot, tim -------------- next part -------------- >From 18147876fd834a24dcdeca70078c972f84e92866 Mon Sep 17 00:00:00 2001 From: Tim Blechmann Date: Wed, 9 Jul 2014 20:01:11 +0200 Subject: [PATCH] InstallTarget: install CFBundles with complete directory --- Source/cmInstallTargetGenerator.cxx | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx index 7a39f45..38d369e 100644 --- a/Source/cmInstallTargetGenerator.cxx +++ b/Source/cmInstallTargetGenerator.cxx @@ -213,6 +213,20 @@ void cmInstallTargetGenerator::GenerateScriptForConfig(std::ostream& os, filesFrom.push_back(from1); filesTo.push_back(to1); } + else if(this->Target->IsCFBundleOnApple()) + { + // Install the whole app bundle directory. + type = cmInstallType_DIRECTORY; + literal_args += " USE_SOURCE_PERMISSIONS"; + + std::string targetNameBase = targetName.substr(0, targetName.find('/')); + + std::string from1 = fromDirConfig + targetNameBase; + std::string to1 = toDir + targetName; + + filesFrom.push_back(from1); + filesTo.push_back(to1); + } else { bool haveNamelink = false; -- 2.0.1 From sdougherty at barracuda.com Wed Jul 9 16:24:51 2014 From: sdougherty at barracuda.com (Steve Dougherty) Date: Wed, 9 Jul 2014 16:24:51 -0400 Subject: [cmake-developers] [PATCH] fix comment typos Message-ID: <1404937491-12660-1-git-send-email-sdougherty@barracuda.com> --- Source/kwsys/Terminal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Source/kwsys/Terminal.c b/Source/kwsys/Terminal.c index 6d7ec41..e13003f 100644 --- a/Source/kwsys/Terminal.c +++ b/Source/kwsys/Terminal.c @@ -104,11 +104,11 @@ void kwsysTerminal_cfprintf(int color, FILE* stream, const char* format, ...) } /*--------------------------------------------------------------------------*/ -/* Detect cases when a stream is definately not interactive. */ +/* Detect cases when a stream is definitely not interactive. */ #if !defined(KWSYS_TERMINAL_ISATTY_WORKS) static int kwsysTerminalStreamIsNotInteractive(FILE* stream) { - /* The given stream is definately not interactive if it is a regular + /* The given stream is definitely not interactive if it is a regular file. */ struct stat stream_stat; if(fstat(fileno(stream), &stream_stat) == 0) @@ -212,7 +212,7 @@ static int kwsysTerminalStreamIsVT100(FILE* stream, int default_vt100, (void)default_tty; return isatty(fileno(stream))? 1:0; #else - /* Check for cases in which the stream is definately not a tty. */ + /* Check for cases in which the stream is definitely not a tty. */ if(kwsysTerminalStreamIsNotInteractive(stream)) { return 0; -- 2.0.1 =========================================================== DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. From sdougherty at barracuda.com Wed Jul 9 16:30:26 2014 From: sdougherty at barracuda.com (Steve Dougherty) Date: Wed, 9 Jul 2014 16:30:26 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <53B4081A.1080205@kitware.com> References: <20140626150242.GA29055@megas.kitwarein.com> <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> <53B4081A.1080205@kitware.com> Message-ID: <53BDA662.90908@barracuda.com> On 07/02/2014 09:24 AM, Brad King wrote: > On 07/02/2014 08:13 AM, Ben Boeckel wrote: >> Colors should only be output if we're outputting to a TTY. Pipes or >> redirections should not be colored (they'll only confuse those who don't >> recognize the escape sequences). CMake also has color routines already, >> but I don't know off-hand how accessible they are from CTest code (i.e., >> might be static functions). > > Look for uses of "cmsysTerminal_cfprintf" as an example. > See its declaration in "Source/kwsys/Terminal.h.in" also. I've attached an implementation that uses cmsysTerminal_cfprintf. Is it acceptable to decouple outputting this line from cmCTest::Log? Currently cmCTestLog is a macro that uses cmCTest::Log, which uses C++ ostreams. Would it be better to move the color logic and manipulation to something shared between Log and cmsysTerminal_cfprintf, and add a Log that can use color? Is it preferable to keep the user-facing string on one line, or break it up for line length? =========================================================== DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-color-test-summary-output.patch Type: text/x-patch Size: 1524 bytes Desc: not available URL: From gvjung at gmail.com Thu Jul 10 00:10:28 2014 From: gvjung at gmail.com (Greg Jung) Date: Wed, 9 Jul 2014 21:10:28 -0700 Subject: [cmake-developers] [CMake 0015011]: problem to find non-standard ncurses.h location In-Reply-To: <82a5d3937e85f6eecde21d8e63cc1cee@public.kitware.com> References: <82a5d3937e85f6eecde21d8e63cc1cee@public.kitware.com> Message-ID: The CMake module scripting is weak regarding the variable that should be taking care of this, CMAKE_SYSTEM_PREFIX_PATH (i.e., /usr; /opt) will be used in find_path (after appending /include) and for find_library(after appending /lib) - according to cmake.html documentation. For my mingw/msys builds I set this and the /include, /lib mostly located in platform/MingW.cmake: ---------------- if(MSYS) # enhance the system prefix path. (picks up /Mingw/lib) find_path( MINGWPATH msys PATH ${CMAKE_USR_PATH}/../../ NO_DEFAULT_PATH) list(APPEND CMAKE_SYSTEM_PREFIX_PATH ${MINGWPATH} ) list(APPEND CMAKE_SYSTEM_INCLUDE_PATH ${MINGWPATH}/include ) list(APPEND CMAKE_SYSTEM_LIBRARY_PATH ${MINGWPATH}/lib ) ------- then LDFLAGS is inspected: ____ set(LDFLAGS "$ENV{LDFLAGS}") if(LDFLAGS) message(STATUS "\n" " inspecting LDFLAGS: ${LDFLAGS}" ) string( REGEX MATCHALL "-L([^\" ]+)" librarylist "${LDFLAGS}" ) foreach(element IN LISTS librarylist) # LDFLAGS is more specific. ------------ etc., leading to message(STATUS " adding system library path: ${library}") list(INSERT CMAKE_SYSTEM_LIBRARY_PATH 0 ${library}) list(INSERT CMAKE_SYSTEM_INCLUDE_PATH 0 ${library}/../include ) ------------------------------------------------------- On Wed, Jul 9, 2014 at 4:14 AM, Mantis Bug Tracker < mantis at public.kitware.com> wrote: > > The following issue has been SUBMITTED. > ====================================================================== > http://public.kitware.com/Bug/view.php?id=15011 > ====================================================================== > Reported By: hsk > Assigned To: > ====================================================================== > Project: CMake > Issue ID: 15011 > Category: (No Category) > Reproducibility: always > Severity: minor > Priority: normal > Status: new > ====================================================================== > Date Submitted: 2014-07-09 07:14 EDT > Last Modified: 2014-07-09 07:14 EDT > ====================================================================== > Summary: problem to find non-standard ncurses.h location > Description: > i have installed gnu ncurses (and several other libraries) under separate > location; os: solaris10, compiler: sunstudio 12.2 > > building cmake 2.8.x worked using > > env \ > CC=cc \ > CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \ > CXX=CC \ > CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4' \ > LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' > \ > CPPFLAGS=-I/var/imb/include \ > ./bootstrap --prefix=/var/imb; gmake > > with cmake 3.0, the "gmake" step fails: > > cmake-3.0.0/Source/CursesDialog/form/form.h", line 46: cannot find include > file: > > > and -I/var/imb/include must be explicitly added to CFLAGS / CXXFLAGS for > ncurses.h to be found, i.e., i have to use > > env \ > CC=cc \ > CFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \ > CXX=CC \ > CXXFLAGS='-xtarget=ultra2 -xarch=sparcvis -xO4 -I/var/imb/include' \ > LDFLAGS='-L/var/imb/lib -R/var/imb/lib -L/usr/sfw/lib -R/usr/sfw/lib -s' > \ > CPPFLAGS=-I/var/imb/include \ > ./bootstrap --prefix=/var/imb; gmake > > imho, the value of CPPFLAGS should be honoured here > > ====================================================================== > > Issue History > Date Modified Username Field Change > ====================================================================== > 2014-07-09 07:14 hsk New Issue > ====================================================================== > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Thu Jul 10 07:09:07 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 07:09:07 -0400 Subject: [cmake-developers] [CMake 0015012]: Generator expressions provide PLATFORM_ID but its values are not documented Message-ID: <6f38a2b85274f8ba2a216e2c87e70553@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15012 ====================================================================== Reported By: Philipp M?ller Assigned To: ====================================================================== Project: CMake Issue ID: 15012 Category: Documentation Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-10 07:09 EDT Last Modified: 2014-07-10 07:09 EDT ====================================================================== Summary: Generator expressions provide PLATFORM_ID but its values are not documented Description: http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html documents PLATFORM_ID, but does not mention the possible values the variable could have. I suppose the corresponding variable is CMAKE__PLATFORM_ID http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_LANG_PLATFORM_ID.html, but is documented as internal. Removing PLATFORM_ID from generator expressions would be a step backwards since it would remove an important use case, documentation CMAKE__PLATFORM_ID seems the right direction. In general the generator expression documentation could be more explicit about the corresponding variables. Steps to Reproduce: None. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 07:09 Philipp M?ller New Issue ====================================================================== From brad.king at kitware.com Thu Jul 10 10:13:41 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 10:13:41 -0400 Subject: [cmake-developers] [CMake 0015011]: problem to find non-standard ncurses.h location In-Reply-To: References: <82a5d3937e85f6eecde21d8e63cc1cee@public.kitware.com> Message-ID: <53BE9F95.7090101@kitware.com> On 07/10/2014 12:10 AM, Greg Jung wrote: > The CMake module scripting is weak regarding the variable that should be taking care of this, > CMAKE_SYSTEM_PREFIX_PATH (i.e., /usr; /opt) will be used in find_path (after appending /include) > and for find_library(after appending /lib) - according to cmake.html documentation. For my mingw/msys > builds I set this and the /include, /lib mostly located in platform/MingW.cmake: Our issue tracker does not support email-submitted comments. I've copied your comment into the tracker here: http://www.cmake.org/Bug/view.php?id=15011#c36336 Please join discussion over there. Thanks, -Brad From brad.king at kitware.com Thu Jul 10 10:13:48 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 10:13:48 -0400 Subject: [cmake-developers] [PATCH] fix comment typos In-Reply-To: <1404937491-12660-1-git-send-email-sdougherty@barracuda.com> References: <1404937491-12660-1-git-send-email-sdougherty@barracuda.com> Message-ID: <53BE9F9C.2080603@kitware.com> On 07/09/2014 04:24 PM, Steve Dougherty wrote: > --- > Source/kwsys/Terminal.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Thanks. I've applied it to KWSys upstream: Terminal: Fix spelling of 'definitely' in comments http://public.kitware.com/gitweb?p=KWSys.git;a=commitdiff;h=5f28a52b It will be integrated to CMake next time we update our KWSys (which shouldn't be too long). -Brad From brad.king at kitware.com Thu Jul 10 10:13:53 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 10:13:53 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> <53BD726D.4030303@kitware.com> Message-ID: <53BE9FA1.9020600@kitware.com> On 07/09/2014 02:02 PM, Tim Blechmann wrote: > attached! Applied, thanks: OS X: Install CFBundles as complete directories http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=908433bd -Brad From brad.king at kitware.com Thu Jul 10 10:13:58 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 10:13:58 -0400 Subject: [cmake-developers] [RFCv2] ctest: color test summary output In-Reply-To: <53BDA662.90908@barracuda.com> References: <20140626150242.GA29055@megas.kitwarein.com> <1404244908-1666-1-git-send-email-sdougherty@barracuda.com> <20140702121300.GB32329@bronto-burt.dev.benboeckel.net> <53B4081A.1080205@kitware.com> <53BDA662.90908@barracuda.com> Message-ID: <53BE9FA6.2000407@kitware.com> On 07/09/2014 04:30 PM, Steve Dougherty wrote: > I've attached an implementation that uses cmsysTerminal_cfprintf. > > Is it acceptable to decouple outputting this line from cmCTest::Log? Currently > cmCTestLog is a macro that uses cmCTest::Log, which uses C++ ostreams. It will have to go through the log API because HANDLER_OUTPUT does not always go to std::cout. It looks like cmCTest needs to expose a way to determine whether 'StreamOut == &std::cout'. If so, then you could flush cout, write to stdout with cmsysTerminal_cfprintf, and then fflush(stdout). > Would it be better to move the color logic and manipulation to something shared > between Log and cmsysTerminal_cfprintf, and add a Log that can use color? cmsysTerminal is in a separate KWSys library that we import to the Source/kwsys directory. If something were to be shared then it would have to stay in that library. Some refactoring of cfprintf may be needed to fix this issue too: http://www.cmake.org/Bug/view.php?id=12991#c28687 Note that because color in Windows consoles requires state changes instead of using escape sequences it is not possible to achieve a single atomic write with color. > Is it preferable to keep the user-facing string on one line, or break it up for > line length? Unless the numbers are really big I do not see how this summary line can be very long. -Brad From tim at klingt.org Thu Jul 10 11:48:57 2014 From: tim at klingt.org (Tim Blechmann) Date: Thu, 10 Jul 2014 17:48:57 +0200 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: <53BE9FA1.9020600@kitware.com> References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> <53BD726D.4030303@kitware.com> <53BE9FA1.9020600@kitware.com> Message-ID: >> attached! > > Applied, thanks: > > OS X: Install CFBundles as complete directories > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=908433bd thanks a lot! i wonder: will this patch make it into 3.0.1? tim From mantis at public.kitware.com Thu Jul 10 12:05:34 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 12:05:34 -0400 Subject: [cmake-developers] [CMake 0015013]: subsystem windowsce is not set for dll only for exes, this makes dll not loadable on wec2013 (wince8) Message-ID: <7691d3a9c33d2c838849e3f413fc5897@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15013 ====================================================================== Reported By: Gunnar Roth Assigned To: ====================================================================== Project: CMake Issue ID: 15013 Category: CMake Reproducibility: always Severity: major Priority: urgent Status: new ====================================================================== Date Submitted: 2014-07-10 12:05 EDT Last Modified: 2014-07-10 12:05 EDT ====================================================================== Summary: subsystem windowsce is not set for dll only for exes, this makes dll not loadable on wec2013 (wince8) Description: the subsystem switch for the linker is only set for executables but not for dlls. this was no problem for ce < wec2013. but wec2013 checks for correct subsystem. you can see this informations using depends.exe from dependancywalker.com Steps to Reproduce: compile a project containg a dll with a wec2013 sdk. this dll will not be loaded on wec2013. Additional Information: this problem can be fixed with this simple patch: --- a\share\cmake-3.0\Modules/Platform/Windows-MSVC.cmake +++ b\share\cmake-3.0\Modules/Platform/Windows-MSVC.cmake @@ -37,12 +37,13 @@ endif() set(WIN32 1) if(CMAKE_SYSTEM_NAME MATCHES "WindowsCE") - set(CMAKE_CREATE_WIN32_EXE "/subsystem:windowsce /entry:WinMainCRTStartup") - set(CMAKE_CREATE_CONSOLE_EXE "/subsystem:windowsce /entry:mainACRTStartup") + set(CMAKE_CREATE_WIN32_EXE "/entry:WinMainCRTStartup") + set(CMAKE_CREATE_CONSOLE_EXE "/entry:mainACRTStartup") + set(CMAKE_EXE_LINKER_FLAGS_INIT "${CMAKE_EXE_LINKER_FLAGS_INIT} /subsystem:windowsce") set(WINCE 1) else() set(CMAKE_CREATE_WIN32_EXE "/subsystem:windows") set(CMAKE_CREATE_CONSOLE_EXE "/subsystem:console") endif() CMAKE_EXE_LINKER_FLAGS_INIT is inherited by the dll settings but CMAKE_CREATE_WIN32_EXE or CMAKE_CREATE_CONSOLE_EXE is of course not. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 12:05 Gunnar Roth New Issue ====================================================================== From mantis at public.kitware.com Thu Jul 10 12:13:27 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 12:13:27 -0400 Subject: [cmake-developers] [CMake 0015014]: for better release debbuging support for /d2Zi+ option should be added for vs2012 and up Message-ID: <1ff242e6441f7a52feb616e634c5182f@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15014 ====================================================================== Reported By: Gunnar Roth Assigned To: ====================================================================== Project: CMake Issue ID: 15014 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-10 12:13 EDT Last Modified: 2014-07-10 12:13 EDT ====================================================================== Summary: for better release debbuging support for /d2Zi+ option should be added for vs2012 and up Description: since vs2012 the option /d2Zi+ is supported by compiler which created much better debug info for release build and the debugger can actually use it. there is only a slight increase in pdb size. see http://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/ Additional Information: this simple patch add the switch to all projects if the compiler is > 1600 --- a\share\cmake-3.0\Modules/Platform/Windows-MSVC.cmake +++ b\share\cmake-3.0\Modules/Platform/Windows-MSVC.cmake @@ -254,6 +257,11 @@ set(CMAKE_${lang}_FLAGS_INIT "${_PLATFORM_DEFINES}${_PLATFORM_DEFINES_${lang}} /D_WINDOWS /W3${_FLAGS_${lang}}") set(CMAKE_${lang}_FLAGS_DEBUG_INIT "/D_DEBUG /MDd /Zi /Ob0 /Od ${_RTC1}") set(CMAKE_${lang}_FLAGS_RELEASE_INIT "/MD /O2 /Ob2 /D NDEBUG") set(CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT "/MD /Zi /O2 /Ob1 /D NDEBUG") set(CMAKE_${lang}_FLAGS_MINSIZEREL_INIT "/MD /O1 /Ob1 /D NDEBUG") + if(MSVC_VERSION GREATER 1600) + set(CMAKE_${lang}_FLAGS_DEBUG_INIT "${CMAKE_${lang}_FLAGS_DEBUG_INIT} /d2Zi+") + set(CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT "${CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT} /d2Zi+") + endif() + endmacro() ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 12:13 Gunnar Roth New Issue ====================================================================== From brad.king at kitware.com Thu Jul 10 12:56:05 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 10 Jul 2014 12:56:05 -0400 Subject: [cmake-developers] [patch] install cfbundles as directory In-Reply-To: References: <53BD5B0D.4000708@kitware.com> <53BD6357.1030108@kitware.com> <53BD726D.4030303@kitware.com> <53BE9FA1.9020600@kitware.com> Message-ID: <53BEC5A5.4060705@kitware.com> On 07/10/2014 11:48 AM, Tim Blechmann wrote: > thanks a lot! i wonder: will this patch make it into 3.0.1? Sure. I rebased the commit back on 3.0.0: OS X: Install CFBundles as complete directories http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3ac67cc -Brad From mantis at public.kitware.com Thu Jul 10 16:10:20 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 16:10:20 -0400 Subject: [cmake-developers] [CMake 0015015]: Bug 0015012 documents the platform Id now but there is no platform I'd for wince defined. Message-ID: <5befb2227dc638fd78d0430d1fa33895@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15015 ====================================================================== Reported By: Gunnar Roth Assigned To: ====================================================================== Project: CMake Issue ID: 15015 Category: CMake Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-10 16:10 EDT Last Modified: 2014-07-10 16:10 EDT ====================================================================== Summary: Bug 0015012 documents the platform Id now but there is no platform I'd for wince defined. Description: Is this by intent? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 16:10 Gunnar Roth New Issue ====================================================================== From mantis at public.kitware.com Thu Jul 10 20:19:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 10 Jul 2014 20:19:47 -0400 Subject: [cmake-developers] [CMake 0015016]: FindCUDA creates intermediate objects in wrong place when CUDA_SEPARABLE_COMPILATION is ON. Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15016 ====================================================================== Reported By: Marco Assigned To: ====================================================================== Project: CMake Issue ID: 15016 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-10 20:19 EDT Last Modified: 2014-07-10 20:19 EDT ====================================================================== Summary: FindCUDA creates intermediate objects in wrong place when CUDA_SEPARABLE_COMPILATION is ON. Description: When setting CUDA_SEPARABLE_COMPILATION to ON, if .cu files are not in the same folder of CMakeLists.txt, intermediate linkage objects are generated in the wrong folder, causing a compilation error that, on Visual Studio, looks like this: Cannot open compiler generated file: 'project_path/CMakeFiles/project_name/Debug/project_name_intermediate_link.obj': No such file or directory. Steps to Reproduce: The file attached to this report has a .cu file and a CMakeLists.txt. Generate a Visual Studio solution and try to compile the project to reproduce this bug. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-10 20:19 Marco New Issue 2014-07-10 20:19 Marco File Added: find_cuda_bug.7z ====================================================================== From vitalii.chernookyi at globallogic.com Fri Jul 11 05:15:25 2014 From: vitalii.chernookyi at globallogic.com (Vitaly Chernooky) Date: Fri, 11 Jul 2014 12:15:25 +0300 Subject: [cmake-developers] Random hang of building process: deedlock in cmake. Message-ID: Hi all! Today I caught again a hang of local building process. I used debugger and strace in steps to catch a bug. so: $ pstree ... | | ??gbs???sh???depanneur???sh???sudo???build???perl ? ? ? ??su???rpmbuild???sh???cmake???gmake ... $ ps ax | grep gmake ... 1105 ? Z 0:00 [gmake] ... $ ps ax | grep cmake ... 760 ? S 0:01 /usr/bin/cmake ... ... $ sudo strace -p 760 [sudo] password for vitalii.chernookyi: Process 760 attached - interrupt to quit select(4, [3], NULL, NULL, NULL^C Process 760 detached $ ls -l /proc/760/fd/3 lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 -> pipe:[1670438] $ ls -l /proc/*/fd/* | grep 'pipe:\[1670438\]' lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 -> pipe:[1670438] l-wx------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:42 /proc/760/fd/4 -> pipe:[1670438] $ sudo gdb -p 760 ... 0x0000000060138543 in ?? () (gdb) bt #0 0x0000000060138543 in ?? () #1 0x000000006004a4ce in ?? () #2 0x000000006004e2fe in ?? () #3 0x0000000060040309 in ?? () #4 0x00000000600039ee in ?? () #5 0x00000000600d9584 in ?? () #6 0x0000000060003f41 in ?? () #7 0x00007fff61dc5e88 in ?? () #8 0x0000000000000000 in ?? () (gdb) quit ... $ So we caught a deedlock. Do anyone have any idea how to fix it? -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalii.chernookyi at globallogic.com Fri Jul 11 05:54:55 2014 From: vitalii.chernookyi at globallogic.com (Vitaly Chernooky) Date: Fri, 11 Jul 2014 12:54:55 +0300 Subject: [cmake-developers] [Dev] Random hang of building process: deedlock in cmake. In-Reply-To: References: Message-ID: Alexander, Yes - you are right. It's just excellent illustration why I hate pipes. So CMake guys can remove this crap from their code and use socketpair() or like instead. \\wbr On Fri, Jul 11, 2014 at 12:33 PM, Kanevskiy, Alexander < alexander.kanevskiy at intel.com> wrote: > On 11/07/14 12:15 , "Vitaly Chernooky" > wrote: > > > This looks like old ?good? bug in qemu that sometimes re-appear in certain > combination of host environment and sources you?re building: > > https://bugs.launchpad.net/qemu/+bug/955379 > > > > > >Hi all! > > > >Today I caught again a hang of local building process. > > > >I used debugger and strace in steps to catch a bug. > > > >so: > > > >$ pstree > >... > > | | ??gbs???sh???depanneur???sh???sudo???build???perl > > ? ? ? > >??su???rpmbuild???sh???cmake???gmake > >... > >$ ps ax | grep gmake > >... > >1105 ? Z 0:00 [gmake] > > > >... > >$ ps ax | grep cmake > >... > > 760 ? S 0:01 /usr/bin/cmake ... > > > >... > >$ sudo strace -p 760 > >[sudo] password for vitalii.chernookyi: > > > > > >Process 760 attached - interrupt to quit > >select(4, [3], NULL, NULL, NULL^C > > > > > >Process 760 detached > >$ ls -l /proc/760/fd/3 > > > >lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 > >-> pipe:[1670438] > > > >$ ls -l /proc/*/fd/* | grep 'pipe:\[1670438\]' > >lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 > >-> pipe:[1670438] > >l-wx------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:42 /proc/760/fd/4 > >-> pipe:[1670438] > > > > > >$ sudo gdb -p 760 > >... > >0x0000000060138543 in ?? () > > > > > >(gdb) bt > >#0 0x0000000060138543 in ?? () > > > > > >#1 0x000000006004a4ce in ?? () > >#2 0x000000006004e2fe in ?? () > > > > > >#3 0x0000000060040309 in ?? () > >#4 0x00000000600039ee in ?? () > > > > > >#5 0x00000000600d9584 in ?? () > >#6 0x0000000060003f41 in ?? () > > > > > >#7 0x00007fff61dc5e88 in ?? () > >#8 0x0000000000000000 in ?? () > > > > > >(gdb) quit > > > > > > > > > >... > >$ > > > > > > > >So we caught a deedlock. > > > >Do anyone have any idea how to fix it? > > > > > >-- > >Vitaly Chernooky | Senior Developer - Product Engineering and Development > >GlobalLogic > >P +380.44.4929695 ext.1136 M +380.98.7920568 S cvv_2k > >www.globallogic.com > > > >http://www.globallogic.com/email_disclaimer.txt > > > > > > > > > > > > > > > -- > Best regards, Alexander Kanevskiy. > > --------------------------------------------------------------------- > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalii.chernookyi at globallogic.com Fri Jul 11 06:04:16 2014 From: vitalii.chernookyi at globallogic.com (Vitaly Chernooky) Date: Fri, 11 Jul 2014 13:04:16 +0300 Subject: [cmake-developers] [Dev] Random hang of building process: deedlock in cmake. In-Reply-To: References: Message-ID: Also it will be good if every body from us will vote for that bug on launchpad. On Fri, Jul 11, 2014 at 12:54 PM, Vitaly Chernooky < vitalii.chernookyi at globallogic.com> wrote: > Alexander, > > Yes - you are right. > > It's just excellent illustration why I hate pipes. > > So CMake guys can remove this crap from their code and use socketpair() or > like instead. > > \\wbr > > > On Fri, Jul 11, 2014 at 12:33 PM, Kanevskiy, Alexander < > alexander.kanevskiy at intel.com> wrote: > >> On 11/07/14 12:15 , "Vitaly Chernooky" >> wrote: >> >> >> This looks like old ?good? bug in qemu that sometimes re-appear in certain >> combination of host environment and sources you?re building: >> >> https://bugs.launchpad.net/qemu/+bug/955379 >> >> >> >> >> >Hi all! >> > >> >Today I caught again a hang of local building process. >> > >> >I used debugger and strace in steps to catch a bug. >> > >> >so: >> > >> >$ pstree >> >... >> > | | ??gbs???sh???depanneur???sh???sudo???build???perl >> > ? ? ? >> >??su???rpmbuild???sh???cmake???gmake >> >... >> >$ ps ax | grep gmake >> >... >> >1105 ? Z 0:00 [gmake] >> > >> >... >> >$ ps ax | grep cmake >> >... >> > 760 ? S 0:01 /usr/bin/cmake ... >> > >> >... >> >$ sudo strace -p 760 >> >[sudo] password for vitalii.chernookyi: >> > >> > >> >Process 760 attached - interrupt to quit >> >select(4, [3], NULL, NULL, NULL^C >> > >> > >> >Process 760 detached >> >$ ls -l /proc/760/fd/3 >> > >> >lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 >> >-> pipe:[1670438] >> > >> >$ ls -l /proc/*/fd/* | grep 'pipe:\[1670438\]' >> >lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 >> >-> pipe:[1670438] >> >l-wx------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:42 /proc/760/fd/4 >> >-> pipe:[1670438] >> > >> > >> >$ sudo gdb -p 760 >> >... >> >0x0000000060138543 in ?? () >> > >> > >> >(gdb) bt >> >#0 0x0000000060138543 in ?? () >> > >> > >> >#1 0x000000006004a4ce in ?? () >> >#2 0x000000006004e2fe in ?? () >> > >> > >> >#3 0x0000000060040309 in ?? () >> >#4 0x00000000600039ee in ?? () >> > >> > >> >#5 0x00000000600d9584 in ?? () >> >#6 0x0000000060003f41 in ?? () >> > >> > >> >#7 0x00007fff61dc5e88 in ?? () >> >#8 0x0000000000000000 in ?? () >> > >> > >> >(gdb) quit >> > >> > >> > >> > >> >... >> >$ >> > >> > >> > >> >So we caught a deedlock. >> > >> >Do anyone have any idea how to fix it? >> > >> > >> >-- >> >Vitaly Chernooky | Senior Developer - Product Engineering and Development >> >GlobalLogic >> >P +380.44.4929695 ext.1136 M +380.98.7920568 S cvv_2k >> >www.globallogic.com >> > >> >http://www.globallogic.com/email_disclaimer.txt >> > >> > >> > >> > >> > >> > >> >> >> -- >> Best regards, Alexander Kanevskiy. >> >> --------------------------------------------------------------------- >> Intel Finland Oy >> Registered Address: PL 281, 00181 Helsinki >> Business Identity Code: 0357606 - 4 >> Domiciled in Helsinki >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> > > > > -- > *Vitaly Chernooky | Senior Developer - Product Engineering and Development* > GlobalLogic > P *+380.44.4929695 ext.1136 <%2B380.44.4929695%20ext.1136>* M *+380.98.7920568 > <%2B380.98.7920568>* S cvv_2k > www.globallogic.com > > http://www.globallogic.com/email_disclaimer.txt > -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalii.chernookyi at globallogic.com Fri Jul 11 06:05:50 2014 From: vitalii.chernookyi at globallogic.com (Vitaly Chernooky) Date: Fri, 11 Jul 2014 13:05:50 +0300 Subject: [cmake-developers] [Dev] Random hang of building process: deedlock in cmake. In-Reply-To: <53BFAE72.7020707@samsung.com> References: <53BFAE72.7020707@samsung.com> Message-ID: Ilya, do you still interested in build logs? I've collected them. \\wbr On Fri, Jul 11, 2014 at 12:29 PM, Ilya Palachev wrote: > Hi, Vitaly. > Maybe your backtrace information will be somehow more useful if you > download and unrpm > "debuginfo" and "debugsource" rpm packages from the repository that you > use as default repository in your ~/.gbs.conf > > If you use native gdb (not in chroot) these RPMs should be unrpm'ed inside > root (/) directory, so that new files > will appear in directories /usr/lib/debug and /usr/src/debug. > > I have already noticed cmake's hanging in our build system for many times > about 2 yours ago. Maybe it's specific for our environment. > > Also the output log of cmake will be useful. Does cmake hangs during the > search of some libraries? > > Best regards, > Ilya Palachev > ------------------------------ > > *From:* Vitaly Chernooky > > *Sent:* Friday, July 11, 2014 1:15PM > *To:* cmake-developers at cmake.org, dev at lists.tizen.org > > *Cc:* Andrii Anisov > > *Subject:* [Dev] Random hang of building process: deedlock in cmake. > > Hi all! > > Today I caught again a hang of local building process. > > I used debugger and strace in steps to catch a bug. > > so: > > $ pstree > ... > | | ??gbs???sh???depanneur???sh???sudo???build???perl > ? ? ? > ??su???rpmbuild???sh???cmake???gmake > ... > $ ps ax | grep gmake > ... > 1105 ? Z 0:00 [gmake] > ... > $ ps ax | grep cmake > ... > 760 ? S 0:01 /usr/bin/cmake ... > ... > $ sudo strace -p 760 > [sudo] password for vitalii.chernookyi: > > > Process 760 attached - interrupt to quit > select(4, [3], NULL, NULL, NULL^C > > > Process 760 detached > $ ls -l /proc/760/fd/3 > > lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 -> > pipe:[1670438] > $ ls -l /proc/*/fd/* | grep 'pipe:\[1670438\]' > lr-x------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:41 /proc/760/fd/3 > -> pipe:[1670438] > l-wx------ 1 vitalii.chernookyi tizendev 64 Jul 11 11:42 /proc/760/fd/4 -> > pipe:[1670438] > > $ sudo gdb -p 760 > ... > 0x0000000060138543 in ?? () > > > (gdb) bt > #0 0x0000000060138543 in ?? () > > > #1 0x000000006004a4ce in ?? () > #2 0x000000006004e2fe in ?? () > > > #3 0x0000000060040309 in ?? () > #4 0x00000000600039ee in ?? () > > > #5 0x00000000600d9584 in ?? () > #6 0x0000000060003f41 in ?? () > > > #7 0x00007fff61dc5e88 in ?? () > #8 0x0000000000000000 in ?? () > > > (gdb) quit > > > ... > $ > > > So we caught a deedlock. > > Do anyone have any idea how to fix it? > > > -- > *Vitaly Chernooky | Senior Developer - Product Engineering and > Development* > GlobalLogic > P *+380.44.4929695 ext.1136 <%2B380.44.4929695%20ext.1136>* M *+380.98.7920568 > <%2B380.98.7920568>* S cvv_2k > www.globallogic.com > > http://www.globallogic.com/email_disclaimer.txt > > > _______________________________________________ > Dev mailing listDev at lists.tizen.orghttps://lists.tizen.org/listinfo/dev > > > > > -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Jul 11 18:24:20 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 11 Jul 2014 18:24:20 -0400 Subject: [cmake-developers] [CMake 0015017]: Changing compiler/library versions, Finding Packages, and etc. Message-ID: <5564407c8b307f7d248bc460f4b02144@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15017 ====================================================================== Reported By: rhl Assigned To: ====================================================================== Project: CMake Issue ID: 15017 Category: (No Category) Reproducibility: always Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-11 18:24 EDT Last Modified: 2014-07-11 18:24 EDT ====================================================================== Summary: Changing compiler/library versions, Finding Packages, and etc. Description: Hi, I really enjoy using CMake, it takes a lot of redundancy and hassle out of build systems. Thank you to all developers involved :) I am writing to request the developers to consider making a high level change to the way that the compilers are chosen and changed as well as packages are added. It would be great if there was a way (say within ccmake) to selectively choose which of the many compilers on a system are available, and, when adding packages via find_package, if some list of the available FindXXX.cmake scripts could be made conveniently available. Regularly I am on a system with many compiler choices ( a modern os/x machine with homebrew will have clang by default, but gcc installed on the side potentially, or gcc symlinked to clang) and possibly many library versions. It would be great to be able to selectively choose when running cmake or ccmake which of these libraries/compilers I want to compile/link with based on what cmake is able to find when inspecting the system. On linux with the environment-modules or like program, many many different compilers can be available, many flavors of gcc, icc, clang, etc.. I find it a hassle to have to modify the CMakeLists.txt each time i need to change the compiler and add/remove specific compiler flags. I'm sure you are all busy and i'm not sure if anyone else is interested in this, or some variant of this idea.. At any rate, thanks again for all your hard work. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-11 18:24 rhl New Issue ====================================================================== From mantis at public.kitware.com Sat Jul 12 16:41:49 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sat, 12 Jul 2014 16:41:49 -0400 Subject: [cmake-developers] [CMake 0015018]: Try_run with project and target Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15018 ====================================================================== Reported By: Andrew Aladjev Assigned To: ====================================================================== Project: CMake Issue ID: 15018 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-12 16:41 EDT Last Modified: 2014-07-12 16:41 EDT ====================================================================== Summary: Try_run with project and target Description: "try_compile" has ability to work with complete project and it's target, "try_run" do not. Why? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-12 16:41 Andrew Aladjev New Issue ====================================================================== From mantis at public.kitware.com Mon Jul 14 10:47:07 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 14 Jul 2014 10:47:07 -0400 Subject: [cmake-developers] [CMake 0015020]: Segmentation Fault after writing build files Message-ID: <7fd5977decc1460ef3e83a4f82aa0a30@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15020 ====================================================================== Reported By: k0n3ru Assigned To: ====================================================================== Project: CMake Issue ID: 15020 Category: CMake Reproducibility: always Severity: crash Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-14 10:47 EDT Last Modified: 2014-07-14 10:47 EDT ====================================================================== Summary: Segmentation Fault after writing build files Description: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff774117f in std::basic_string, std::allocator >::~basic_string() () from /usr/lib64/libstdc++.so.6 (gdb) bt http://www.cmake.org/Bug/view.php?id=0 0x00007ffff774117f in std::basic_string, std::allocator >::~basic_string() () from /usr/lib64/libstdc++.so.6 http://www.cmake.org/Bug/view.php?id=1 0x00000000005f9efa in cmListFileContext::~cmListFileContext() () http://www.cmake.org/Bug/view.php?id=2 0x00000000005f9f55 in void std::_Destroy(cmListFileContext*) () http://www.cmake.org/Bug/view.php?id=3 0x00000000005f9f72 in void std::_Destroy(cmListFileContext*, cmListFileContext*) () http://www.cmake.org/Bug/view.php?id=4 0x00000000005f9fa4 in void std::_Destroy(cmListFileContext*, cmListFileContext*, std::allocator&) () http://www.cmake.org/Bug/view.php?id=5 0x0000000000600813 in std::vector >::~vector() () http://www.cmake.org/Bug/view.php?id=6 0x000000000060086f in cmListFileBacktrace::~cmListFileBacktrace() () http://www.cmake.org/Bug/view.php?id=7 0x000000000070b98b in cmCustomCommand::~cmCustomCommand() () http://www.cmake.org/Bug/view.php?id=8 0x000000000060a075 in void std::_Destroy(cmCustomCommand*) () http://www.cmake.org/Bug/view.php?id=9 0x000000000060a092 in void std::_Destroy(cmCustomCommand*, cmCustomCommand*) () http://www.cmake.org/Bug/view.php?id=10 0x000000000060a0c7 in void std::_Destroy(cmCustomCommand*, cmCustomCommand*, std::allocator&) () http://www.cmake.org/Bug/view.php?id=11 0x000000000060a0f9 in std::vector >::~vector() () http://www.cmake.org/Bug/view.php?id=12 0x000000000060a697 in cmTarget::~cmTarget() () http://www.cmake.org/Bug/view.php?id=13 0x000000000060a894 in std::pair::~pair() () http://www.cmake.org/Bug/view.php?id=14 0x000000000060a903 in __gnu_cxx::new_allocator >::destroy(std::pair*) () http://www.cmake.org/Bug/view.php?id=15 0x000000000060a93a in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_destroy_node(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=16 0x000000000060a9bf in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=17 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=18 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=19 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=20 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=21 0x000000000060a9a5 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase(std::_Rb_tree_node >*) () http://www.cmake.org/Bug/view.php?id=22 0x000000000060a9f4 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::~_Rb_tree() () http://www.cmake.org/Bug/view.php?id=23 0x000000000060aa4f in std::map, std::allocator > >::~map() () http://www.cmake.org/Bug/view.php?id=24 0x00000000005ebc27 in cmMakefile::~cmMakefile() () http://www.cmake.org/Bug/view.php?id=25 0x000000000078760a in cmLocalGenerator::~cmLocalGenerator() () http://www.cmake.org/Bug/view.php?id=26 0x00000000007948db in cmLocalUnixMakefileGenerator3::~cmLocalUnixMakefileGenerator3() () http://www.cmake.org/Bug/view.php?id=27 0x0000000000743a70 in cmGlobalGenerator::~cmGlobalGenerator() () http://www.cmake.org/Bug/view.php?id=28 0x000000000076485d in cmGlobalUnixMakefileGenerator3::~cmGlobalUnixMakefileGenerator3() () http://www.cmake.org/Bug/view.php?id=29 0x000000000065d9c0 in cmake::~cmake() () http://www.cmake.org/Bug/view.php?id=30 0x00000000005b2194 in do_cmake(int, char**) () http://www.cmake.org/Bug/view.php?id=31 0x00000000005b2297 in main () Additional Information: This backtrace was generated from gdb. I have tried with CMake version 2.8.12.1 and this problem does not appear. Seems all the files have been generated.I was able to build entire project successfully with the generated MakeFile. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-14 10:47 k0n3ru New Issue ====================================================================== From nilsgladitz at gmail.com Mon Jul 14 17:20:59 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 14 Jul 2014 23:20:59 +0200 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <2019241404927050@web7g.yandex.ru> References: <2019241404927050@web7g.yandex.ru> Message-ID: <53C449BB.3070506@gmail.com> On 09.07.2014 19:30, Konstantin Podsvirov wrote: > Hello dear developers! > > And again CPack IFW generator!!! > > This generator is not part of CMake, but I hope that soon it will become possible. > > This letter I once again want to awaken interest in the creation of new cross-platform > the binary installer is based on Qt Framework Installer tools (http://qt-project.org/doc/qtinstallerframework/index.html) > > (Sorry for my English. I use a translator) > > I already appeared here some time ago: > http://public.kitware.com/pipermail/cmake-developers/2014-May/010430.html > > I received some recommendations and considered them. > > With each commit generator becomes better. > > As before you can clone the code for the study: > git clone git://podsvirov.pro/cmake/cpackifwgenerator.git > > Or check out the code in your browser: > http://git.podsvirov.pro/?p=cmake/cpackifwgenerator.git;a=summary > > In the Wiki I found an example of creating a binary instalatorow: > http://cmake.org/Wiki/CMake:Component_Install_With_CPack > > My generator also copes with this task. Here's how it looks in Linux and Windows: > http://ifw.podsvirov.pro/cmake/cpackifw-componentexample-linux.png > http://ifw.podsvirov.pro/cmake/cpackifw-componentexample-windows.png > > I strive to create the binary installer CMake using a new generator. I already have the achievements. > Created installers produce the set of all that was specified in the install(...)but do not create shortcuts. > Version of CMake (CPack IFW generator) collected them available for Linux and Windows now: > http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-linux-i686.run > http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-windows-x64.exe > http://ifw.podsvirov.pro/cmake/cmake-3.0.20140709-ifw-windows-x86.exe > > Please test these installers and write your comments. Hello again :) Some stuff that remains from my earlier observations: - Lot of commented out code that should be removed. - Unescaped XML content from CMake variables. Some other random stuff I noticed: - CPACK_IFW_BINARYCREATOR_EXECUTABLE_FOUND seems redundant given that find_program() already encodes this in the cache variable. - In the CMake coding conventions class members start upper case. I tried building a CMake installer with the generator again but it failed with: Caught exception: Component version for '/home/ngladitz/src/git/cpackifwgenerator/build/_CPack_Packages/Linux-x86_64/IFW/cmake-3.0.20140709-gd078a-Linux-x86_64/packages/CMake/meta/package.xml' is invalid! 3.0.20140709-gd078a Nils From mantis at public.kitware.com Tue Jul 15 04:47:19 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Jul 2014 04:47:19 -0400 Subject: [cmake-developers] [CMake 0015021]: misleading header comments in FindHDF5 Message-ID: <9b1bfcc311638a240615ad265ded4b5f@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15021 ====================================================================== Reported By: Joachim Wuttke Assigned To: ====================================================================== Project: CMake Issue ID: 15021 Category: Modules Reproducibility: have not tried Severity: text Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-15 04:47 EDT Last Modified: 2014-07-15 04:47 EDT ====================================================================== Summary: misleading header comments in FindHDF5 Description: - Header component says module takes 'COMPONENTS' argument. Doesn't work for me; what works for me is set( HDF5_FIND_COMPONENTS "CXX" ) include( FindHDF5 ) - Header comment says module will define 'HDF5_CXX_LIBRARIES'. Doesn't work for me; the module only defines 'HDF5_LIBRARIES' ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-15 04:47 Joachim Wuttke New Issue ====================================================================== From daniele.domenichelli at gmail.com Tue Jul 15 04:52:39 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 15 Jul 2014 10:52:39 +0200 Subject: [cmake-developers] RFC fix_Xcode_generator_name topic Message-ID: <53C4EBD7.30809@gmail.com> Hello all, Can anyone with OSX and Xcode check if this commit is correct? http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e475c067 I have no way to test it, but by looking at the code, it looks to me that the name should be Xcode instead of XCode... Thanks, Daniele From steveire at gmail.com Tue Jul 15 07:00:24 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 15 Jul 2014 13:00:24 +0200 Subject: [cmake-developers] cost of usage requirements In-Reply-To: <53BD5BCE.2020204@kitware.com> References: <20140608225611.GC18896@megas.kitwarein.com> <8D151EF9D6FCEA2-26D4-1169@webmail-d299.sysops.aol.com> <20140610171757.GA3906@megas.kitwarein.com> <53986BDC.7090707@kitware.com> <53BD5BCE.2020204@kitware.com> Message-ID: <53C509C8.6090100@gmail.com> On 07/09/2014 05:12 PM, Brad King wrote: > On 06/11/2014 10:46 AM, Brad King wrote: >> Here is a sscce:: >> >> cmake_minimum_required(VERSION 2.8.9) >> project(ManyLibs C) >> set(LibPrev) >> foreach(n RANGE 100) >> add_library(Lib${n} SHARED lib.c) >> target_link_libraries(Lib${n} LINK_PUBLIC ${LibPrev}) >> set(LibPrev Lib${n}) >> endforeach() > A similar case also appears when building VTKWikiExamples > as discussed on the cmake user list here: > > cmake 3.0 memory usage on VTKWikiExamples > http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/49910/focus=49922 > > Memory usage explodes during generation and CMake sometimes > runs out and crashes. Is this affected in any way by the recent refactoring with the same motivation? Thanks, Steve. From brad.king at kitware.com Tue Jul 15 09:07:19 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Jul 2014 09:07:19 -0400 Subject: [cmake-developers] RFC fix_Xcode_generator_name topic In-Reply-To: <53C4EBD7.30809@gmail.com> References: <53C4EBD7.30809@gmail.com> Message-ID: <53C52787.2010407@kitware.com> On 07/15/2014 04:52 AM, Daniele E. Domenichelli wrote: > Can anyone with OSX and Xcode check if this commit is correct? > > http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e475c067 > > I have no way to test it, but by looking at the code, it looks to me > that the name should be Xcode instead of XCode... Yes, please merge for testing in 'next'. Thanks, -Brad From daniele.domenichelli at gmail.com Tue Jul 15 09:14:44 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 15 Jul 2014 15:14:44 +0200 Subject: [cmake-developers] RFC fix_Xcode_generator_name topic In-Reply-To: <53C52787.2010407@kitware.com> References: <53C4EBD7.30809@gmail.com> <53C52787.2010407@kitware.com> Message-ID: <53C52944.4000206@gmail.com> On 15/07/14 15:07, Brad King wrote: > Yes, please merge for testing in 'next'. Done, Thanks. Cheers, Daniele From brad.king at kitware.com Tue Jul 15 09:47:54 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Jul 2014 09:47:54 -0400 Subject: [cmake-developers] cost of usage requirements In-Reply-To: <53C509C8.6090100@gmail.com> References: <20140608225611.GC18896@megas.kitwarein.com> <8D151EF9D6FCEA2-26D4-1169@webmail-d299.sysops.aol.com> <20140610171757.GA3906@megas.kitwarein.com> <53986BDC.7090707@kitware.com> <53BD5BCE.2020204@kitware.com> <53C509C8.6090100@gmail.com> Message-ID: <53C5310A.8000108@kitware.com> On 07/15/2014 07:00 AM, Stephen Kelly wrote: > On 07/09/2014 05:12 PM, Brad King wrote: >> Memory usage explodes during generation and CMake sometimes >> runs out and crashes. > > Is this affected in any way by the recent refactoring with the same > motivation? The refactoring so far does not help much directly, but it does reduce some code duplication to make further improvements easier. A small example that is a bit closer to what happens in VTKWikiExamples is: cmake_minimum_required(VERSION 2.8.9) project(ManyLibs C) set(LibPrev) foreach(n RANGE 100) add_library(Lib${n} SHARED lib.c) target_link_libraries(Lib${n} LINK_PUBLIC ${LibPrev}) set(LibPrev Lib${n}) endforeach() foreach(n RANGE 100) add_executable(Exe${n} exe.c) target_link_libraries(Exe${n} ${LibPrev}) endforeach() On my machine: ========= ========= ========= ======== version real user sys ========= ========= ========= ======== 2.8.9 0m1.017s 0m0.912s 0m0.096s 2.8.12.2 0m7.293s 0m7.156s 0m0.120s 3.0.0 0m10.728s 0m10.384s 0m0.128s 487b6ccd 0m20.819s 0m20.724s 0m0.092s 7bc84502 0m11.390s 0m11.296s 0m0.084s ========= ========= ========= ======== The cleanup between 487b6ccd and 7bc84502 got this example back to 3.0-ish time but nothing like 2.8.9. -Brad From mantis at public.kitware.com Tue Jul 15 09:53:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Jul 2014 09:53:51 -0400 Subject: [cmake-developers] [CMake 0015023]: Researchers Find Bacon Sandwich Perfect Cure For A Hangover Message-ID: <982959b7437d8a43c631dfdc76f017e0@www.itk.org> The following issue has been SUBMITTED. ====================================================================== http://www.itk.org/Bug/view.php?id=15023 ====================================================================== Reported By: Melva Jorgensen Assigned To: ====================================================================== Project: CMake Issue ID: 15023 Category: CMakeSetup Reproducibility: have not tried Severity: trivial Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-15 09:53 EDT Last Modified: 2014-07-15 09:53 EDT ====================================================================== Summary: Researchers Find Bacon Sandwich Perfect Cure For A Hangover Description: This is quite a challenge. Coat a bacon (utilize the basic supermarket kind) in a half-cup of brown glucose. I'm a big time bacon eater. Of course, the issue with bacon has always been it is fattening. This really is boiled or baked and then served hot or cold. Some, which includes Bacon, refused to hear. If you don't know where your cholesterol, blood pressure, and blood sugar levels are, this is a advantageous time for a check-up plus blood tests. Chop the stem off and cut the flowerettes into bite sized pieces. Raw, fresh food ingredients offer one of the best basis for a healthy diet. A small object to act as the "bacon." Any small object may be used as the bacon - a small ball or dry erase board eraser are usually easy to find in a classroom setting. The mess is nothing more then a tiny puddle of grease, which may later be saved by diehard foodies that recognize which bacon grease, is as close to paradise because you can get without entering the actual gates. It contains less fat than the conventional bacon from the U.S. Although quiche is connected with the French, plus is in fact a classic French dish, it originally was built in Germany. You are able to eat it right away! Get pitted medjool dates, though this is produced with usual dates furthermore. While we will create healthier food options, most days of the week, we could furthermore enjoy each today and then. The olive oil sticks to the pasta (don't rinse the pasta inside cold water, warm pasta holds the oil plus seasonings better) plus blends all flavors. That was around the time that I was in "Diner." I've heard there is going to be a "Footloose" remake starring Zac Effron. It barely looks fair but, given the method the awards ceremonies are conducted, only 1 normally walks away the winner when there are a quantity of losers, foremost of that are the final contenders for the particular award being given away. Water temperature, salinity, and nearby tides all affect the taste of a oyster. We should be thoughtful to monitor the oven, considering in the event you cook it too lengthy, it might burn. Challenge 5: Not targeting the Right Market. Bacon is one of the many universal foods accessible as it can be served with or added to any kind of edible entr???e. Enjoy delicious deviled eggs with bacon ( http://bacon4.me/ ) yourselves! In buying bacon, it is commonly more economical to purchase the entire side, or the entire center cut, yet when smaller quantities are desired, any amount, either in 1 piece or inside slices, can be bought. The insides of the date are like molten lava. Also you will learn all regarding the different toxicities and just how they affect a wellness. Transfer the bacon onto several paper towels which will soak up the excess grease plus then serve them. Store pre packaged fresh beef the same way, first loosening original wrapper. That is a time-honored spot reserved for "a side of a pig cured and smoked." "But the fat! Safety consultants that conserve the bacon, as well as furthermore save a revenue.Not to mention, that safety consultants can see any safety issues about the website, and may imply the difference between an injury or a death online site. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-15 09:53 Melva JorgensenNew Issue ====================================================================== From mantis at public.kitware.com Tue Jul 15 10:01:09 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 15 Jul 2014 10:01:09 -0400 Subject: [cmake-developers] [CMake 0015023]: Researchers Find Bacon Sandwich Perfect Cure For A Hangover In-Reply-To: <982959b7437d8a43c631dfdc76f017e0@www.cmake.org> Message-ID: The following issue has been DELETED. ====================================================================== Reported By: Melva Jorgensen Assigned To: ====================================================================== Project: CMake Issue ID: 15023 Category: CMakeSetup Reproducibility: have not tried Severity: trivial Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-15 09:53 EDT Last Modified: 2014-07-15 09:53 EDT ====================================================================== Summary: Researchers Find Bacon Sandwich Perfect Cure For A Hangover Description: This is quite a challenge. Coat a bacon (utilize the basic supermarket kind) in a half-cup of brown glucose. I'm a big time bacon eater. Of course, the issue with bacon has always been it is fattening. This really is boiled or baked and then served hot or cold. Some, which includes Bacon, refused to hear. If you don't know where your cholesterol, blood pressure, and blood sugar levels are, this is a advantageous time for a check-up plus blood tests. Chop the stem off and cut the flowerettes into bite sized pieces. Raw, fresh food ingredients offer one of the best basis for a healthy diet. A small object to act as the "bacon." Any small object may be used as the bacon - a small ball or dry erase board eraser are usually easy to find in a classroom setting. The mess is nothing more then a tiny puddle of grease, which may later be saved by diehard foodies that recognize which bacon grease, is as close to paradise because you can get without entering the actual gates. It contains less fat than the conventional bacon from the U.S. Although quiche is connected with the French, plus is in fact a classic French dish, it originally was built in Germany. You are able to eat it right away! Get pitted medjool dates, though this is produced with usual dates furthermore. While we will create healthier food options, most days of the week, we could furthermore enjoy each today and then. The olive oil sticks to the pasta (don't rinse the pasta inside cold water, warm pasta holds the oil plus seasonings better) plus blends all flavors. That was around the time that I was in "Diner." I've heard there is going to be a "Footloose" remake starring Zac Effron. It barely looks fair but, given the method the awards ceremonies are conducted, only 1 normally walks away the winner when there are a quantity of losers, foremost of that are the final contenders for the particular award being given away. Water temperature, salinity, and nearby tides all affect the taste of a oyster. We should be thoughtful to monitor the oven, considering in the event you cook it too lengthy, it might burn. Challenge 5: Not targeting the Right Market. Bacon is one of the many universal foods accessible as it can be served with or added to any kind of edible entr???e. Enjoy delicious deviled eggs with bacon ( http://bacon4.me/ ) yourselves! In buying bacon, it is commonly more economical to purchase the entire side, or the entire center cut, yet when smaller quantities are desired, any amount, either in 1 piece or inside slices, can be bought. The insides of the date are like molten lava. Also you will learn all regarding the different toxicities and just how they affect a wellness. Transfer the bacon onto several paper towels which will soak up the excess grease plus then serve them. Store pre packaged fresh beef the same way, first loosening original wrapper. That is a time-honored spot reserved for "a side of a pig cured and smoked." "But the fat! Safety consultants that conserve the bacon, as well as furthermore save a revenue.Not to mention, that safety consultants can see any safety issues about the website, and may imply the difference between an injury or a death online site. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-15 09:53 Melva JorgensenNew Issue 2014-07-15 10:01 Brad King Issue Deleted: 0015023 ====================================================================== From mantis at public.kitware.com Wed Jul 16 10:09:58 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Jul 2014 10:09:58 -0400 Subject: [cmake-developers] [CMake 0015026]: Build fails with Cray compiler on Linux Message-ID: <9dc6911598a810fa65fd31b690a9c393@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15026 ====================================================================== Reported By: Chuck Atkins Assigned To: ====================================================================== Project: CMake Issue ID: 15026 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-16 10:09 EDT Last Modified: 2014-07-16 10:09 EDT ====================================================================== Summary: Build fails with Cray compiler on Linux Description: When building with the Cray compiler on Linux (on an XE6 or XE7 such as Titan or Garnet, for example), the CMake curl library fails to build. Steps to Reproduce: 1. Checkout current master on a Cray XE6 or XE7 2. Configure the programming environment to use the cray compilers: # module purge # module load PrgEnv-cray # module load cce 3. Configure and build. The result will fail with: CC-20 craycc: ERROR File = /dev/shm/atkins3/cmake/master/Utilities/cmcurl/hostip.c, Line = 616 The identifier "SIZEOF_in_addr" is undefined. memcpy(addrentry, &num, SIZEOF_in_addr); ^ Total errors detected in /dev/shm/atkins3/cmake/master/Utilities/cmcurl/hostip.c: 1 Additional Information: The error is caused by a workaround for UNICOS. The workaround incorrectly uses the _CRAYC macro to determine if building for UNICOS. This macro will always be defined for the Cray C and C++ compiler regardless of the target platform, even when building for Linux. The correct macro should be _CRAY, which as per Cray documentation is only defined for UNICOS targeted builds. Attached is a patch with a fix. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-16 10:09 Chuck Atkins New Issue 2014-07-16 10:09 Chuck Atkins File Added: 0001-Fix-a-build-failure-with-the-Cray-compiler-on-Linux.patch ====================================================================== From daniele.domenichelli at gmail.com Wed Jul 16 11:55:17 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Wed, 16 Jul 2014 17:55:17 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree Message-ID: <53C6A065.7010201@gmail.com> Hello all, Please review the topic CMakePackageConfigHelpers_build_tree. This patch adds an option BUILD_TREE to configure_package_config_file. At the moment it is complicated to generate config files both for install and build tree, usually combined with "export(TARGETS)" and "install(EXPORT)", using configure_package_config_file, and it will require to tweak the build tree variables to always use absolute paths, or the generated config file will be broken. You can generate valid config files, but in the build tree the relative paths will always be calculated compared to CMAKE_INSTALL_PREFIX, and this does not make sense, and also generates config files with very long lists of "../../../" and difficult to read. The BUILD_TREE option instructs configure_package_config_file to consider paths that are not absolute as relative to the CMAKE_BINARY_DIR directory instead of relative to the CMAKE_INSTALL_PREFIX` directory. This makes a lot easier to generate 2 different config files, one for the build directory and one to install with the package. * CMakePackageConfigHelpers: Remove unused variable: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=7d7bb039 * CMakePackageConfigHelpers: restructure documentation and document commands: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=a8e70768 * CMakePackageConfigHelpers: Add BUILD_TREE option: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=d64849af * CMakePackageConfigHelpers: Add unit tests for BUILD_TREE option: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=3d3695ca Cheers, Daniele From mantis at public.kitware.com Wed Jul 16 21:46:04 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 16 Jul 2014 21:46:04 -0400 Subject: [cmake-developers] [CMake 0015027]: Failure to find GTK Message-ID: <038aec60f2e8b92e8da7288c43387e39@cmake.org> The following issue has been SUBMITTED. ====================================================================== http://cmake.org/Bug/view.php?id=15027 ====================================================================== Reported By: Luc J. Bourhis Assigned To: ====================================================================== Project: CMake Issue ID: 15027 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-16 21:46 EDT Last Modified: 2014-07-16 21:46 EDT ====================================================================== Summary: Failure to find GTK Description: In the process of building cmake on that version of MacOS 10.9, I get the following failures {{{ CMake Error at Modules/FindGTK2.cmake:181 (file): file STRINGS file "/Library/Frameworks/Gtk.framework/Headers/gtk/gtk/gtkversion.h" cannot be read. Call Stack (most recent call first): Modules/FindGTK2.cmake:796 (_GTK2_GET_VERSION) Tests/CMakeLists.txt:1197 (find_package) }}} There is a file /Library/Frameworks/Gtk.framework/Headers/gtk/gtkversion.h on my system. Steps to Reproduce: 1. Install MacPorts 2. Issue "port install cmake" Additional Information: I was advised by the MacPorts maintainer to report the bug upstream. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-16 21:46 Luc J. Bourhis New Issue ====================================================================== From konstantin at podsvirov.pro Thu Jul 17 03:33:01 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Jul 2014 11:33:01 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <53C449BB.3070506@gmail.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> Message-ID: <2681081405582381@web7g.yandex.ru> Hi Nils, and other developers! 15.07.2014, 01:21, "Nils Gladitz" : > Hello again :) > Some stuff that remains from my earlier observations: > - A Lot of commented out code that should be removed. I do this work sometimes > Is Unescaped XML content from CMake variables. Now I use cmXMLSafe in several places > Some other random stuff I noticed: > - CPACK_IFW_BINARYCREATOR_EXECUTABLE_FOUND seems redundant given that > find_program() already encodes this in the cache variable. I think you're right and I'll get rid of this variable in the near future. But as long as the variable is still alive. > - In the CMake coding conventions class members start uppercase. The names of the methods I write with a capital letter, but the property names with a small letter as in the base class cmCpackGenerator. > I tried building a CMake installer with the generator again but it > failed with: > Caught exception: Component version for > '/home/ngladitz/src/git/cpackifwgenerator/build/_CPack_Packages/Linux-x86_64/IFW/cmake-3.0.20140709-gd078a-Linux-x86_64/packages/CMake/meta/package.xml' > is invalid! 3.0.20140709-gd078a Now I fixed it. Should work. Regards From konstantin at podsvirov.pro Thu Jul 17 03:57:59 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Jul 2014 11:57:59 +0400 Subject: [cmake-developers] =?koi8-r?b?Q1BhY2sgSUZXIMfFzsXSwdTP0g==?= Message-ID: <3923551405583879@web23m.yandex.ru> Hello fans of CMake and Windows! I want to present the online installer CMake for 32-bit and 64-bit versions of Windows. And immediately the binaries: http://ifw.podsvirov.pro/cmake/cmake-master-windows-32bit-online.exe http://ifw.podsvirov.pro/cmake/cmake-master-windows-64bit-online.exe The installer will install CMake from an online repository and create shortcuts in the start menu. The composition of the labels is the same as that of the NSIS installer. But there is a difference: the Uninstaller allows not only to delete it may update CMake. The content of the installed package matches the 'master' branch source code + the CPack IFW generator. CMake well done: he build and package himself :-) I don't promise daily updates, but once a week I'll try to put a fresh build. Regards, Konstantin Podsvirov From konstantin at podsvirov.pro Thu Jul 17 04:11:48 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 17 Jul 2014 12:11:48 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <3923551405583879@web23m.yandex.ru> References: <3923551405583879@web23m.yandex.ru> Message-ID: <6963841405584708@web29h.yandex.ru> 17.07.2014, 12:04, "Konstantin Podsvirov" : > Hello fans of CMake and Windows! > > I want to present the online installer CMake for 32-bit and 64-bit versions of Windows. All well and good, but the title of the previous writing containing Russian characters. Sorry :-) just Russian is my native language. It was a typo. The installers I presented are test and may contain errors. If you have questions or suggestions, please write to the list or to me personally. Regards, Konstantin Podsvirov From mantis at public.kitware.com Thu Jul 17 06:23:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 17 Jul 2014 06:23:47 -0400 Subject: [cmake-developers] [CMake 0015028]: CMake build error on QNX Message-ID: <75c413d5038cfb1015bd72003156ed56@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15028 ====================================================================== Reported By: Bob E. Assigned To: ====================================================================== Project: CMake Issue ID: 15028 Category: CMake Reproducibility: always Severity: minor Priority: high Status: new ====================================================================== Date Submitted: 2014-07-17 06:23 EDT Last Modified: 2014-07-17 06:23 EDT ====================================================================== Summary: CMake build error on QNX Description: cmake-2.8.12.2/Source/kwsys/SystemInformation.cxx:3682: error: 'SA_RESTART' was not declared in this scope cc: /usr/qnx650/host/qnx6/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 make[2]: *** [Source/kwsys/CMakeFiles/cmsys.dir/SystemInformation.cxx.o] Error 1 Steps to Reproduce: Make Cmake from sources. Additional Information: QNX not support SA_RESTART signal: qnx6\usr\include\signal.h /* #define SA_RESTART 0x0040 (not supported yet) */ /* Restart the kernel call on signal return */ In ProcessUNIX.c this error was resolved earlier. Patch correct it in SystemInformation.cxx ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-17 06:23 Bob E. New Issue 2014-07-17 06:23 Bob E. File Added: SystemInformation.cxx.QNX.path ====================================================================== From brad.king at kitware.com Thu Jul 17 10:33:28 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 17 Jul 2014 10:33:28 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53C6A065.7010201@gmail.com> References: <53C6A065.7010201@gmail.com> Message-ID: <53C7DEB8.2020304@kitware.com> On 07/16/2014 11:55 AM, Daniele E. Domenichelli wrote: > Please review the topic CMakePackageConfigHelpers_build_tree. > > This patch adds an option BUILD_TREE to configure_package_config_file. The changes look good to me, though I'd appreciate feedback from others who have worked on this module before. In the documentation formatting commit, I see blocks like: > +# .. command:: configure_package_config_file > +# > +# Create a config file for a project:: The definition of the command should be in an indented block so that reST knows it is part of the explicit markup block. Thanks, -Brad From mantis at public.kitware.com Fri Jul 18 15:17:51 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 18 Jul 2014 15:17:51 -0400 Subject: [cmake-developers] [CMake 0015029]: Segmentation fault handling packages (infinite loop, ?perhaps fills up memory?) Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15029 ====================================================================== Reported By: darlingm Assigned To: ====================================================================== Project: CMake Issue ID: 15029 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-18 15:17 EDT Last Modified: 2014-07-18 15:17 EDT ====================================================================== Summary: Segmentation fault handling packages (infinite loop, ?perhaps fills up memory?) Description: Loading gdb for cmake and the associated dropped core file gives: Program terminated with signal SIGSEGV, Segmentation fault. http://www.cmake.org/Bug/view.php?id=0 0x0000003646e576b0 in _IO_vfscanf_internal () from /lib64/libc.so.6 (gdb) bt http://www.cmake.org/Bug/view.php?id=0 0x0000003646e576b0 in _IO_vfscanf_internal () from /lib64/libc.so.6 http://www.cmake.org/Bug/view.php?id=1 0x0000003646e62eb5 in vsscanf () from /lib64/libc.so.6 http://www.cmake.org/Bug/view.php?id=2 0x0000003646e5dfe8 in sscanf () from /lib64/libc.so.6 http://www.cmake.org/Bug/view.php?id=3 0x00000000007b89d1 in cmFindPackageCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=4 0x00000000007c5b35 in cmCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=5 0x00000000006c80ba in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=6 0x00000000006c901e in cmMakefile::ReadListFile(char const*, char const*, std::string*, bool) () http://www.cmake.org/Bug/view.php?id=7 0x00000000007bce56 in cmFindPackageCommand::ReadListFile(char const*, cmFindPackageCommand::PolicyScopeRule) () http://www.cmake.org/Bug/view.php?id=8 0x00000000007bb531 in cmFindPackageCommand::FindModule(bool&) () http://www.cmake.org/Bug/view.php?id=9 0x00000000007ba1d4 in cmFindPackageCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=10 0x00000000007c5b35 in cmCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=11 0x00000000006c80ba in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=12 0x00000000006c901e in cmMakefile::ReadListFile(char const*, char const*, std::string*, bool) () http://www.cmake.org/Bug/view.php?id=13 0x00000000007bce56 in cmFindPackageCommand::ReadListFile(char const*, cmFindPackageCommand::PolicyScopeRule) () http://www.cmake.org/Bug/view.php?id=14 0x00000000007bb531 in cmFindPackageCommand::FindModule(bool&) () ........... this InitialPass(http://www.cmake.org/Bug/view.php?id=3)->FindModule(http://www.cmake.org/Bug/view.php?id=8) repeats ........... http://www.cmake.org/Bug/view.php?id=31413 0x00000000007ba1d4 in cmFindPackageCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31414 0x00000000007c5b35 in cmCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31415 0x00000000006c80ba in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31416 0x00000000006c901e in cmMakefile::ReadListFile(char const*, char const*, std::string*, bool) () http://www.cmake.org/Bug/view.php?id=31417 0x00000000006b1ac4 in cmLocalGenerator::ReadInputFile() () http://www.cmake.org/Bug/view.php?id=31418 0x00000000006b163e in cmLocalGenerator::Configure() () http://www.cmake.org/Bug/view.php?id=31419 0x00000000008b33c7 in cmLocalUnixMakefileGenerator3::Configure() () http://www.cmake.org/Bug/view.php?id=31420 0x00000000006ccdfa in cmMakefile::ConfigureSubDirectory(cmLocalGenerator*) () http://www.cmake.org/Bug/view.php?id=31421 0x00000000006cd224 in cmMakefile::AddSubDirectory(char const*, char const*, bool, bool, bool) () http://www.cmake.org/Bug/view.php?id=31422 0x000000000079b462 in cmAddSubDirectoryCommand::InitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31423 0x00000000007c5b35 in cmCommand::InvokeInitialPass(std::vector > const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31424 0x00000000006c80ba in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&) () http://www.cmake.org/Bug/view.php?id=31425 0x00000000006c901e in cmMakefile::ReadListFile(char const*, char const*, std::string*, bool) () http://www.cmake.org/Bug/view.php?id=31426 0x00000000006b1ac4 in cmLocalGenerator::ReadInputFile() () http://www.cmake.org/Bug/view.php?id=31427 0x00000000006b163e in cmLocalGenerator::Configure() () http://www.cmake.org/Bug/view.php?id=31428 0x00000000008b33c7 in cmLocalUnixMakefileGenerator3::Configure() () http://www.cmake.org/Bug/view.php?id=31429 0x000000000087edea in cmGlobalGenerator::Configure() () http://www.cmake.org/Bug/view.php?id=31430 0x000000000089bca2 in cmGlobalUnixMakefileGenerator3::Configure() () http://www.cmake.org/Bug/view.php?id=31431 0x000000000076657e in cmake::ActualConfigure() () http://www.cmake.org/Bug/view.php?id=31432 0x0000000000765ec2 in cmake::Configure() () http://www.cmake.org/Bug/view.php?id=31433 0x0000000000766d5c in cmake::Run(std::vector > const&, bool) () http://www.cmake.org/Bug/view.php?id=31434 0x0000000000681031 in do_cmake(int, char const* const*) () http://www.cmake.org/Bug/view.php?id=31435 0x00000000006808b5 in main () Steps to Reproduce: Extract attached codeTestPackages.tar.gz. mkdir build && cd build && cmake .. Additional Information: I'm attempting to use packages in my build system for the first time. I have no doubt I've done something wrong in the CMakeLists.txt files or FindLIB.cmake file, but I've caused CMake to segmentation fault with a very small reduced case. (Entire project is 41 lines.) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-18 15:17 darlingm New Issue 2014-07-18 15:17 darlingm File Added: codeTestPackages.tar.gz ====================================================================== From daniel at pfeifer-mail.de Sun Jul 20 05:22:21 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Sun, 20 Jul 2014 11:22:21 +0200 Subject: [cmake-developers] LZMA support Message-ID: Hi, In my liblzma branch (https://github.com/purpleKarrot/CMake/commits/liblzma), I did the following: * add the liblzma source from XZ Utils * make it compile with CMake (by adding CMakeLists.txt etc.) * make it compile in VC6 (by porting the source from C99 to C90) * make cmlibarchive use cmliblzma (using cm_lzma.h) * add cpack generators for .7z and .tar.xz This should solve the following issues: http://www.cmake.org/Bug/view.php?id=13072 http://www.cmake.org/Bug/view.php?id=13515 http://www.cmake.org/Bug/view.php?id=14504 http://www.cmake.org/Bug/view.php?id=14519 Please review, comment, pull. Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sun Jul 20 13:16:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 20 Jul 2014 13:16:47 -0400 Subject: [cmake-developers] [CMake 0015030]: Error messages from configure_file do not show the root of the problem Message-ID: <918ee35a25c78920bbcba49715983b70@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15030 ====================================================================== Reported By: Christopher Yeleighton Assigned To: ====================================================================== Project: CMake Issue ID: 15030 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-20 13:16 EDT Last Modified: 2014-07-20 13:16 EDT ====================================================================== Summary: Error messages from configure_file do not show the root of the problem Description: In general, when a system-level exception happens, the exception should be reported via a system facility like perror. I currently get: /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake(1491): configure_file(${kde_cmake_module_dir}/kde4_cmake_uninstall.cmake.in ${CMAKE_BINARY_DIR}/cmake_uninstall.cmake @ONLY ) CMake Error at /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:1491 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): /usr/share/cmake/Modules/FindKDE4.cmake:95 (find_package) CMakeLists.txt:30 (FIND_PACKAGE) This is not enough to identify the cause of the failure. Steps to Reproduce: mkdir -p b/cmake_uninstall.cmake/kde4_cmake_uninstall.cmake.in && cd b && cmake ../libkexiv2-4.13.1 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-20 13:16 Christopher YeleightonNew Issue ====================================================================== From daniele.domenichelli at gmail.com Mon Jul 21 04:54:27 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 21 Jul 2014 10:54:27 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53C7DEB8.2020304@kitware.com> References: <53C6A065.7010201@gmail.com> <53C7DEB8.2020304@kitware.com> Message-ID: <53CCD543.5040207@gmail.com> On 17/07/14 16:33, Brad King wrote: >> > +# .. command:: configure_package_config_file >> > +# >> > +# Create a config file for a project:: > The definition of the command should be in an indented block so > that reST knows it is part of the explicit markup block. I indented the whole command block, can you please have a look if that's what you meant? Or is it just the "brief description" of the command that should be indented? Thanks. Daniele From steveire at gmail.com Mon Jul 21 08:23:43 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 21 Jul 2014 14:23:43 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree References: <53C6A065.7010201@gmail.com> Message-ID: Daniele E. Domenichelli wrote: > You can generate valid config files, but in the build tree the relative > paths will always be calculated compared to CMAKE_INSTALL_PREFIX, and > this does not make sense, and also generates config files with very long > lists of "../../../" and difficult to read. Can you give a more-concrete example of what the problem is? Is this relating to a missing target property somehow? Which paths do you need to specify? Thanks, Steve. From brad.king at kitware.com Mon Jul 21 10:17:03 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Jul 2014 10:17:03 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53CCD543.5040207@gmail.com> References: <53C6A065.7010201@gmail.com> <53C7DEB8.2020304@kitware.com> <53CCD543.5040207@gmail.com> Message-ID: <53CD20DF.707@kitware.com> On 07/21/2014 04:54 AM, Daniele E. Domenichelli wrote: > I indented the whole command block, can you please have a look if that's > what you meant? Or is it just the "brief description" of the command > that should be indented? I think just the signature summary is enough. Section headers can be used if we need a higher-level organization. Also please review the style guidelines: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style In particular, self-references should be plain inline literals: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style-referencing-cmake-domain-objects Thanks, -Brad From nilsgladitz at gmail.com Mon Jul 21 10:38:39 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 21 Jul 2014 16:38:39 +0200 Subject: [cmake-developers] CMake 3.0 COMPILE_DEFINITIONS_ Documentation Message-ID: <53CD25EF.5020708@gmail.com> With CMP0043 the COMPILE_DEFINITIONS_ properties are ignored. This currently doesn't seem to be reflected in the documentation of the properties themselves. Should the documentation for those properties be deleted (I think I would personally prefer that) or extended to show that they may not have any effect when requiring 3.0 (the policy is set to NEW)? Nils From brad.king at kitware.com Mon Jul 21 10:55:17 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Jul 2014 10:55:17 -0400 Subject: [cmake-developers] CMake 3.0 COMPILE_DEFINITIONS_ Documentation In-Reply-To: <53CD25EF.5020708@gmail.com> References: <53CD25EF.5020708@gmail.com> Message-ID: <53CD29D5.6050703@kitware.com> On 07/21/2014 10:38 AM, Nils Gladitz wrote: > Should the documentation for those properties be deleted (I think I > would personally prefer that) or extended to show that they may not have > any effect when requiring 3.0 (the policy is set to NEW)? The latter, please. See the intro paragraph in export_library_dependencies for example: Help/command/export_library_dependencies.rst Thanks, -Brad From daniele.domenichelli at gmail.com Mon Jul 21 11:12:57 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 21 Jul 2014 17:12:57 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> Message-ID: <53CD2DF9.70601@gmail.com> On 21/07/14 14:23, Stephen Kelly wrote: > Can you give a more-concrete example of what the problem is? I have a project that is similar to this small example: --- CMakeLists.txt cmake_minimum_required(VERSION 2.8.12) project(FOO NONE) set(FOO_VERSION 0.0.1) include(${CMAKE_CURRENT_LIST_DIR}/CMakePackageConfigHelpers.cmake) set(FOO_INSTALL_CMAKE_DIR "share/FOO/cmake") set(FOO_BUILD_ABSOLUTE_DIR "${CMAKE_BINARY_DIR}/share/FOO/absolute") set(FOO_INSTALL_ABSOLUTE_DIR "${CMAKE_INSTALL_PREFIX}/share/FOO/absolute") set(FOO_BUILD_RELATIVE_DIR "share/FOO/relative") set(FOO_INSTALL_RELATIVE_DIR "share/FOO/relative") #--------- BUILD TREE set(FOO_ABSOLUTE_DIR ${FOO_BUILD_ABSOLUTE_DIR}) set(FOO_RELATIVE_DIR ${FOO_BUILD_RELATIVE_DIR}) # FOOConfig.cmake (build tree) configure_package_config_file(FOOConfig.cmake.in "FOOConfig.cmake" INSTALL_DESTINATION "${CMAKE_BINARY_DIR}" PATH_VARS FOO_ABSOLUTE_DIR FOO_RELATIVE_DIR NO_CHECK_REQUIRED_COMPONENTS_MACRO BUILD_TREE) #--------- INSTALLED set(FOO_ABSOLUTE_DIR ${FOO_INSTALL_ABSOLUTE_DIR}) set(FOO_RELATIVE_DIR ${FOO_INSTALL_RELATIVE_DIR}) # FOOConfig.cmake (installed) configure_package_config_file(FOOConfig.cmake.in "FOOConfigInstall.cmake" INSTALL_DESTINATION "${FOO_INSTALL_CMAKE_DIR}" PATH_VARS FOO_ABSOLUTE_DIR FOO_RELATIVE_DIR NO_CHECK_REQUIRED_COMPONENTS_MACRO) install(FILES ${CMAKE_BINARY_DIR}/${CMAKE_FILES_DIRECTORY}/FOOConfigInstall.cmake DESTINATION ${FOO_INSTALL_CMAKE_DIR} RENAME FOOConfig.cmake) --- FOOConfig.cmake.in set(FOO_VERSION @FOO_VERSION@) @PACKAGE_INIT@ set_and_check(FOO_ABSOLUTE_DIR "@PACKAGE_FOO_ABSOLUTE_DIR@") set_and_check(FOO_RELATIVE_DIR "@PACKAGE_FOO_RELATIVE_DIR@") The project is supposed to work both from build tree (using export(TARGETS)) and from the install tree (using install(EXPORT)). The file FOOConfigInstall.cmake is perfect and can be relocated as expected. The file FOOConfig.cmake for the build tree contains --- [...] get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../usr/local" ABSOLUTE) [...] set_and_check(FOO_ABSOLUTE_DIR "/share/FOO/absolute") set_and_check(FOO_RELATIVE_DIR "${PACKAGE_PREFIX_DIR}/share/FOO/relative") --- in PACKAGE_PREFIX_DIR, obviously, the length list of "/.." depends on the folder where the package is built. "/usr/local" is the prefix and it makes no sense in the file for the build directory. The path passed using a variable containing an _absolute path_ is _correct_, but it uses the absolute path to the build directory. The path passed using a variable containing a _relative path_ is _wrong_ and it contains a path relative to the install directory. If the package was not installed this path is invalid. This means that all the paths should be passed as absolute paths or the generated file will be invalid. With my patch applied and passing "BUILD_TREE" to the configure_package_config_file call, the generated file becomes: --- [...] get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/" ABSOLUTE) [...] set_and_check(FOO_ABSOLUTE_DIR "${PACKAGE_PREFIX_DIR}/share/FOO/absolute") set_and_check(FOO_RELATIVE_DIR "${PACKAGE_PREFIX_DIR}/share/FOO/relative") --- This removes all the absolute paths from the file (This is not necessary for using the package in the build tree, since I believe that it's not going to be relocated, but I still think it is a good thing), and very important, it allows you to pass relative paths as PATH_VARS and get the same behaviour in both cases. Cheers, Daniele From daniele.domenichelli at gmail.com Mon Jul 21 11:38:31 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 21 Jul 2014 17:38:31 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53CD20DF.707@kitware.com> References: <53C6A065.7010201@gmail.com> <53C7DEB8.2020304@kitware.com> <53CCD543.5040207@gmail.com> <53CD20DF.707@kitware.com> Message-ID: <53CD33F7.8040206@gmail.com> On 21/07/14 16:17, Brad King wrote: > On 07/21/2014 04:54 AM, Daniele E. Domenichelli wrote: >> I indented the whole command block, can you please have a look if that's >> what you meant? Or is it just the "brief description" of the command >> that should be indented? > > I think just the signature summary is enough. Section headers > can be used if we need a higher-level organization. Done. > Also please review the style guidelines: > > http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#style > > In particular, self-references should be plain inline literals: Done. Cheers, Daniele From brad.king at kitware.com Mon Jul 21 13:23:38 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Jul 2014 13:23:38 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53CD33F7.8040206@gmail.com> References: <53C6A065.7010201@gmail.com> <53C7DEB8.2020304@kitware.com> <53CCD543.5040207@gmail.com> <53CD20DF.707@kitware.com> <53CD33F7.8040206@gmail.com> Message-ID: <53CD4C9A.8070009@kitware.com> On 07/21/2014 11:38 AM, Daniele E. Domenichelli wrote: > Done. Thanks. Please squash in something like the patch below. -Brad diff --git a/Modules/CMakePackageConfigHelpers.cmake b/Modules/CMakePackageConfigHelpers.cmake index 24b5b74..54ceb54 100644 --- a/Modules/CMakePackageConfigHelpers.cmake +++ b/Modules/CMakePackageConfigHelpers.cmake @@ -8,7 +8,8 @@ # Adds the :command:`configure_package_config_file()` and # :command:`write_basic_package_version_file()` commands. # -# +# Generating a Package Configuration File +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # # .. command:: configure_package_config_file # @@ -104,10 +105,10 @@ # When using the ``NO_CHECK_REQUIRED_COMPONENTS_MACRO`` option, this macro is # not generated into the ``FooConfig.cmake`` file. # -# For an example see below the documentation for -# :command:`write_basic_package_version_file()`. -# +# See the `Example Generating Package Files`_ below. # +# Generating a Package Version File +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # # .. command:: write_basic_package_version_file # @@ -154,6 +155,8 @@ # :command:`configure_file()` on them yourself, but they can be used as starting # point to create more sophisticted custom ``ConfigVersion.cmake`` files. # +# Example Generating Package Files +# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # # Example using both :command:`configure_package_config_file` and # ``write_basic_package_version_file()``: From steveire at gmail.com Mon Jul 21 15:04:32 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 21 Jul 2014 21:04:32 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> Message-ID: Daniele E. Domenichelli wrote: > On 21/07/14 14:23, Stephen Kelly wrote: >> Can you give a more-concrete example of what the problem is? > > The project is supposed to work both from build tree (using > export(TARGETS)) and from the install tree (using install(EXPORT)). Your example is too abstract. What is the meaning of the paths? What is the problem which can be solved only with CMakePackageConfigHelpers and can't be solved (currently) another way? Is there a first-class feature CMake could learn to make this stuff easier? Here is why I am asking: The documentation at http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages does not use CMakePackageConfigHelpers because for 'modern' packages, paths such as include directories are encoded into imported targets. Then the complete FooConfig.cmake file is: include(CMakeFindDependencyMacro) find_dependency(Stats 2.6.4) include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake") include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake") and it works as both a build-location package and an install-location package, without using CMakePackageConfigHelpers. That is assuming the ClimbingStatsMacros.cmake can be generated in or copied to the build location. That is an easy assumption to make, because it is easy to do such generation or copying. So, I am trying to find out: When using 'modern cmake', is there a remaining need for CMakePackageConfigHelpers? Thanks, Steve. From brad.king at kitware.com Mon Jul 21 16:07:08 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 21 Jul 2014 16:07:08 -0400 Subject: [cmake-developers] LZMA support In-Reply-To: References: Message-ID: <53CD72EC.3010608@kitware.com> On 07/20/2014 05:22 AM, Daniel Pfeifer wrote: > * add the liblzma source from XZ Utils > * make it compile with CMake (by adding CMakeLists.txt etc.) > * make it compile in VC6 (by porting the source from C99 to C90) > * make cmlibarchive use cmliblzma (using cm_lzma.h) > * add cpack generators for .7z and .tar.xz Wonderful, thanks! I restructured the topic a bit to make it easier to update the liblzma version in the future. I also added references to the issue numbers to the commit messages. I've temporarily published an 'add-liblzma' branch to our topic stage at . After some further manual testing I will merge it to 'next'. Thanks, -Brad From daniele.domenichelli at gmail.com Tue Jul 22 04:28:19 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 22 Jul 2014 10:28:19 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> Message-ID: <53CE20A3.7090502@gmail.com> On 21/07/14 21:04, Stephen Kelly wrote: >>> Can you give a more-concrete example of what the problem is? >> >> The project is supposed to work both from build tree (using >> export(TARGETS)) and from the install tree (using install(EXPORT)). > > Your example is too abstract. What is the meaning of the paths? I have at least a couple of different cases where I would like to be able to do this. The first case is a folder that is appended to CMAKE_MODULE_PATH, and that containing CMake files that can optionally be included by projects using this package. The second case is a path to a folder containing "data" files installed by the library (that usually go in /share/), and that other projects should be able to use. In both cases I need to pass a path to the project, not to include a file. The files that the projects need to use are not in ${CMAKE_CURRENT_LIST_DIR} (relative to the config files) and the relative path is different, since for the build tree the cmake config files are in ${CMAKE_BINARY_DIR} (as expected for example by the package registry), while for the install tree the config files are in some of the directory searched by find_package (depending on the OS). > What is the problem which can be solved only with CMakePackageConfigHelpers > and can't be solved (currently) another way? Is there a first-class feature > CMake could learn to make this stuff easier? CMakePackageConfigHelpers _can_ already solve this problem, but you have to pass _absolute_ paths to configure_package_config_file, and that is different from everywhere else in CMake. > The documentation at > > http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages > > does not use CMakePackageConfigHelpers because for 'modern' packages, paths > such as include directories are encoded into imported targets. Does this mean that configure_package_config_file is going to be deprecated and should not be used for new packages? If that's the case, maybe the documentation should mention it. Anyway, even when creating targets in a modern way, I still believe that it is a very useful module when you need to pass paths that cannot be encoded into imported targets. Cheers, Daniele From steveire at gmail.com Tue Jul 22 04:53:03 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Jul 2014 10:53:03 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> Message-ID: Daniele E. Domenichelli wrote: > The first case is a folder that is appended to CMAKE_MODULE_PATH, and > that containing CMake files that can optionally be included by projects > using this package. I still find this an odd user interface. You provide a variable FOO_MODULE_PATH or something and document that users should add that to their CMAKE_MODULE_PATH after invoking find_package? Then what? The user needs to know which files they can include(). Do you leave the user to run ls to find out what's there or do you document them for your package? Instead of all that, you could provide and document variables (ala QT_USE_FILE) which the users pass directly to include(). I would find that a better user interface and less fragile. > The second case is a path to a folder containing "data" files installed > by the library (that usually go in /share/), and that > other projects should be able to use. I guess if you have a particular structure in the source tree, you might not want to symlink/replicate it to the build tree. That arises for qml files for example. However, usually I have chosen the symlink/copy route. As you can see here, the CMakePackageConfigHelpers is only needed for 'backward compatibility' provision of the INCLUDE_DIRS variable, which wouldn't be added in new code: https://github.com/KDAB/KDSoap/blob/master/CMakeLists.txt#L92 https://github.com/KDAB/KDSoap/blob/master/KDSoapConfig.cmake.in > and the > relative path is different, since for the build tree the cmake config > files are in ${CMAKE_BINARY_DIR} (as expected for example by the package > registry) Some other places you can have the cmake config file for the build tree: ${CMAKE_BINARY_DIR}/cmake ${CMAKE_BINARY_DIR}/ ${CMAKE_BINARY_DIR}//cmake ${CMAKE_BINARY_DIR}/cmake/ ${CMAKE_BINARY_DIR}/lib/cmake/ ${CMAKE_BINARY_DIR}/lib/cmake Depending on whether you're going for 'cleanliness' or similarity to the installed layout etc. >> The documentation at >> >> http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages >> >> does not use CMakePackageConfigHelpers because for 'modern' packages, >> paths such as include directories are encoded into imported targets. > > Does this mean that configure_package_config_file is going to be > deprecated and should not be used for new packages? No, it does not mean that. It means I was trying to find out why you need it. My current understanding is that the things it does can also be done other ways (and better ways I think as with the variables for include() above). > I still believe that it is a very useful module > when you need to pass paths that cannot be encoded into imported targets. I was trying to find out if that points us to a gap in the first-class features provided by cmake. Thanks, Steve. From daniele.domenichelli at gmail.com Tue Jul 22 06:48:44 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 22 Jul 2014 12:48:44 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> Message-ID: <53CE418C.9090507@gmail.com> On 22/07/14 10:53, Stephen Kelly wrote: > Daniele E. Domenichelli wrote: > >> The first case is a folder that is appended to CMAKE_MODULE_PATH, and >> that containing CMake files that can optionally be included by projects >> using this package. > > I still find this an odd user interface. > > You provide a variable FOO_MODULE_PATH or something and document that users > should add that to their CMAKE_MODULE_PATH after invoking find_package? Then > what? The user needs to know which files they can include(). Do you leave > the user to run ls to find out what's there or do you document them for your > package? Not exactly, the folder is appended to CMAKE_MODULE_PATH in the config file... The user can include one of the modules in the folder, but he does not need to do it, since the modules enable some extra feature that the user might not want. He just needs to know the name of the module, so it's not different from knowing the name of a variable... > Instead of all that, you could provide and document variables (ala > QT_USE_FILE) which the users pass directly to include(). I would find that a > better user interface and less fragile. Sorry, I'm still not convinced by this... The "QT_USE_FILE" variable will have the same issue with relative paths and will have to be passed as absolute path to configure_package_config_file(), or am I missing something? >> The second case is a path to a folder containing "data" files installed >> by the library (that usually go in /share/), and that >> other projects should be able to use. > > I guess if you have a particular structure in the source tree, you might not > want to symlink/replicate it to the build tree. That arises for qml files > for example. However, usually I have chosen the symlink/copy route. Symlinks are not really an option, because it works on unix only, and we need to support windows as well. Also I think that in one of our cases copy might be not the best options, since some of these files are large binary blobs, and therefore a copy is quite expensive, but I'll have to check if that is necessary... Another issue with copying the file is that the file is copied at CMake time, not a build time, and cmake is not triggered and therefore the copy is not performed at build time if the file is modified and the user just runs make (or "build" for visual studio and other IDEs). By the way, is there a reason why file(COPY) does not have an option to copy the file only if the file(s) is(are) different. I had a few cases where I had to use "execute_process(COMMAND ${CMAKE_COMMAND} -E copy_if_different" because file(COPY) would trigger an unnecessary rebuild. Since you were asking if CMake misses some important feature, I believe that a very useful feature to have would be to be able to have an option for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the install tree in the binary directory, but at build time, and only if the destination file is missing or is different from the source. Or maybe, using the export(FILES/PROGRAMS/DIRECTORY), like for the new export(EXPORT) command... > As you can see here, the CMakePackageConfigHelpers is only needed for > 'backward compatibility' provision of the INCLUDE_DIRS variable, which > wouldn't be added in new code: Backwards compatibility is, in my opinion, another valid use case... Of course you could get the INCLUDE_DIRS using get_property inside the config file, but there is still some case uncovered, i.e. if you don't have libraries in your package (for example for a header only library). >> and the >> relative path is different, since for the build tree the cmake config >> files are in ${CMAKE_BINARY_DIR} (as expected for example by the package >> registry) > > Some other places you can have the cmake config file for the build tree: > > ${CMAKE_BINARY_DIR}/cmake > ${CMAKE_BINARY_DIR}/ > ${CMAKE_BINARY_DIR}//cmake > ${CMAKE_BINARY_DIR}/cmake/ > ${CMAKE_BINARY_DIR}/lib/cmake/ > ${CMAKE_BINARY_DIR}/lib/cmake > > Depending on whether you're going for 'cleanliness' or similarity to the > installed layout etc. I wasn't aware of this, thanks for pointing it out... Maybe this needs some more documentation... I couldn't find anything about in export[1] and cmake-packages.7[2], and find_package[3] says: CMake constructs a set of possible installation prefixes for the package. Under each prefix several directories are searched for a configuration file. The build directory is unlikely to be constructed as an "installation prefix", therefore I thought that these paths were not checked for a build tree. Does this mean that if I set the _DIR environment variable to the CMAKE_BINARY_DIR of my package, CMake will look into these folders as well? This is what our users are used to do and it will not be easy to change their behaviour, also because this is quite useful for testing different builds. [1]http://www.cmake.org/cmake/help/git-master/command/export.html [2]http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html [3]http://www.cmake.org/cmake/help/git-master/command/find_package.htm >> Does this mean that configure_package_config_file is going to be >> deprecated and should not be used for new packages? > > No, it does not mean that. It means I was trying to find out why you need > it. My current understanding is that the things it does can also be done > other ways (and better ways I think as with the variables for include() > above). Anyway, conceptually one should recreate the install tree inside the build tree, and then generate just one config file using configure_package_config_file and use it both for build and install, is this correct? Cheers, Daniele From steveire at gmail.com Tue Jul 22 07:44:45 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Jul 2014 13:44:45 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> Message-ID: Daniele E. Domenichelli wrote: > Sorry, I'm still not convinced by this... The "QT_USE_FILE" variable > will have the same issue with relative paths and will have to be passed > as absolute path to configure_package_config_file(), or am I missing > something? Are you missing the assumption that its location is constant relative to the config file? That makes ${CMAKE_CURRENT_LIST_DIR} appropriate. >>> The second case is a path to a folder containing "data" files installed >>> by the library (that usually go in /share/), and that >>> other projects should be able to use. >> >> I guess if you have a particular structure in the source tree, you might >> not want to symlink/replicate it to the build tree. That arises for qml >> files for example. However, usually I have chosen the symlink/copy route. > > Symlinks are not really an option I wrote 'symlink/replicate'. > Another issue with copying the file is that the file is copied at CMake > time, not a build time, and cmake is not triggered and therefore the > copy is not performed at build time if the file is modified and the user > just runs make (or "build" for visual studio and other IDEs). CMake re-runs (as of a recent cmake version) if the input to configure_file changes. > > > By the way, is there a reason why file(COPY) does not have an option to > copy the file only if the file(s) is(are) different. configure_file(COPY_ONLY) does that. file(COPY_IF_DIFFERENT) would just do the same thing but would be more discoverable and might be a good idea. > Since you were asking if CMake misses some important feature, I believe > that a very useful feature to have would be to be able to have an option > for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the > install tree in the binary directory Yes, seems like something worth investigating. > , but at build time, and only if the > destination file is missing or is different from the source. > > Or maybe, using the export(FILES/PROGRAMS/DIRECTORY), like for the new > export(EXPORT) command... It might be worth filing a bug to record the full idea. >>> and the >>> relative path is different, since for the build tree the cmake config >>> files are in ${CMAKE_BINARY_DIR} (as expected for example by the package >>> registry) >> >> Some other places you can have the cmake config file for the build tree: >> >> ${CMAKE_BINARY_DIR}/cmake >> ${CMAKE_BINARY_DIR}/ >> ${CMAKE_BINARY_DIR}//cmake >> ${CMAKE_BINARY_DIR}/cmake/ >> ${CMAKE_BINARY_DIR}/lib/cmake/ >> ${CMAKE_BINARY_DIR}/lib/cmake >> >> Depending on whether you're going for 'cleanliness' or similarity to the >> installed layout etc. > > I wasn't aware of this, thanks for pointing it out... Maybe this needs > some more documentation... Actually, are you talking about export(PACKAGE)? I don't really know anything about that. > The build directory is unlikely to be constructed as an "installation > prefix", therefore I thought that these paths were not checked for a > build tree. Setting the CMAKE_PREFIX_PATH to contain the build dir would do it. > Does this mean that if I set the _DIR environment variable to > the CMAKE_BINARY_DIR of my package, CMake will look into these folders > as well? No, I don't think so. You would have to set it to the exact dir afaik. > Anyway, conceptually one should recreate the install tree inside the > build tree, and then generate just one config file using > configure_package_config_file and use it both for build and install, is > this correct? In my preference, there should be no need to generate the config file, except to copy it from the source tree to the build tree. Then the content of that file is the same, yes. My preference. Thanks, Steve. From mantis at public.kitware.com Tue Jul 22 08:36:46 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 22 Jul 2014 08:36:46 -0400 Subject: [cmake-developers] [CMake 0015031]: visual studio 2012 generator ampersand escaping Message-ID: <6d2773a4cc588f6878f378df6db4d336@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15031 ====================================================================== Reported By: mscott Assigned To: ====================================================================== Project: CMake Issue ID: 15031 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-22 08:36 EDT Last Modified: 2014-07-22 08:36 EDT ====================================================================== Summary: visual studio 2012 generator ampersand escaping Description: The Visual Studio 2012 generator does not seem to escape ampersands in source file paths correctly, resulting in the generated project XML containing errors and being un-openable with Visual Studio. I tested the same config with the Visual Studio 2008 generator and did not encounter the same issue. When looking at the generated XML, in VS2008 the '&' character is replaced by '&'. Steps to Reproduce: Create a target whose sources includes a file path with the '&' character, then run cmake specifying VS2012 as the generator, open the created solution and notice that it cannot open the target project. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-22 08:36 mscott New Issue ====================================================================== From mantis at public.kitware.com Tue Jul 22 09:43:05 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 22 Jul 2014 09:43:05 -0400 Subject: [cmake-developers] [CMake 0015032]: Binary and source path not handled properly if path does not contain a sub-directory but "drive letter" only Message-ID: <2ece6cb8bb48d91eef874dede3f8b970@www.itk.org> The following issue has been SUBMITTED. ====================================================================== http://www.itk.org/Bug/view.php?id=15032 ====================================================================== Reported By: Gerald Hofmann Assigned To: ====================================================================== Project: CMake Issue ID: 15032 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-22 09:43 EDT Last Modified: 2014-07-22 09:43 EDT ====================================================================== Summary: Binary and source path not handled properly if path does not contain a sub-directory but "drive letter" only Description: If building in a binary directory that is on root level of a "drive letter" the binary path name is not handled properly. Src directory handling also affected, but workaround available. Steps to Reproduce: - Open terminal and cd to a root level build directory (e.g. network share mapped to a server based platform specific build dir) - Issue "cmake-gui s:" (assuming s: points to the src dir) - Find binary dir preset with training backslash. src dir has no training backslash. - Re-select src directory from "browse source" and find the training backslash added First error occourence: ======================= - Try to configure for any generator. CMake Error at s://CMakeLists.txt:42 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory "s:/foo" is not a subdirectory of "s:/". => Looks strange. Error message is not correct. All dirs are in place. - Apply work-around by removing training backslash in source directory (keep it for the bin directory) - Re-configure -> works Extended error occourence: ========================== - Removing the backslash from src dir seemingly works. Run generate. - Find Makefile not working - Makefiles containing wrong build targets # The main all target all: cmake_check_build_system $(CMAKE_COMMAND) -E cmake_progress_start U:\CMakeFiles U:\CMakeFiles\progress.marks $(MAKE) -f CMakeFiles\Makefile2 /nologo -$(MAKEFLAGS) U:\\all $(CMAKE_COMMAND) -E cmake_progress_start U:\CMakeFiles 0 .PHONY : all => "all" target is prefixed by the binary dir drive letter. Makefile is not usable. Manually removing the "U:\\" prefix from the target name will fix the Makefile. All other entries seem to be correct. Additional Information: Probably introduced in late 2.8.x releases Worked in 2.8.2, found during update to 2.8.12 / 3.0.0 Workaround: Always use subdirectory for the binary dir. Make sure there is no training slash in src and bin directory entry. Probable explanation: Path names are not split up properly. cmake seems to expext *no training slash* for src/bin path names (GUI or cl). If selected dir is on root level, internal splitting fails, probably because the parser is looking for a backslash to separate drive letter and relative bin path components. Adding a trailing slash will cure configure stage processing, but bin directory handling is broken by this "enforced" parsing. *** Windoze console path names == root of all evil.... *** ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-22 09:43 Gerald Hofmann New Issue ====================================================================== From daniele.domenichelli at gmail.com Tue Jul 22 10:42:57 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Tue, 22 Jul 2014 16:42:57 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> Message-ID: <53CE7871.1080605@gmail.com> On 22/07/14 13:44, Stephen Kelly wrote: >> Does this mean that if I set the _DIR environment variable to >> the CMAKE_BINARY_DIR of my package, CMake will look into these folders >> as well? > > No, I don't think so. You would have to set it to the exact dir afaik. Actually I tested it, and CMake actually finds the package both if the package is using export(PACKAGE) or if the user sets the _DIR or the CMAKE_PREFIX_PATH environment variables, but it does not work when passing the _DIR cmake variable (i.e. cmake -D_DIR=), that needs to be the correct path to the config files... Unfortunately that's part of the workflow commonly used here to test different builds, and I don't think that I'll be allowed to change the workflow of a quite large team in this way... It is more likely that I'll have to live with "old-style" config files in the main CMAKE_BINARY_DIR, with different relative paths compared to the one installed (or with absolute paths). Also until now I always had the impression that the config file for the build tree should be in the CMAKE_BINARY_DIR folder, see for example http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file where it creates the config file for the build tree in this way: configure_file(FooBarConfig.cmake.in "${PROJECT_BINARY_DIR}/FooBarConfig.cmake" @ONLY) The ultimate solution that I can think about is to have a config file and a version file in CMAKE_BINARY_DIR that just include the real config and version files, but that sounds a little bit weird to me, even though I tested it and it works as expected... So I could have a config file (either configured, or static) in the correct relative folder, and generate the fake ones in this way: file(WRITE "${CMAKE_BINARY_DIR}/FOOConfig.cmake" "include(\${CMAKE_CURRENT_LIST_DIR}//FOOConfig.cmake)\n") file(WRITE "${CMAKE_BINARY_DIR}/FOOConfigVersion.cmake" "include(${CMAKE_CURRENT_LIST_DIR}//FOOConfigVersion.cmake)\n") What do you think, would this be an acceptable solution in a "modern CMake" style? Cheers, Daniele From konstantin at podsvirov.pro Wed Jul 23 04:38:38 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 23 Jul 2014 12:38:38 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <3923551405583879@web23m.yandex.ru> References: <3923551405583879@web23m.yandex.ru> Message-ID: <3104551406104718@web10h.yandex.ru> Update as of July 23, available! 17.07.2014, 12:04, "Konstantin Podsvirov" : > Hello fans of CMake and Windows! > > I want to present the online installer CMake for 32-bit and 64-bit versions of Windows. > > And immediately the binaries: > > http://ifw.podsvirov.pro/cmake/cmake-master-windows-32bit-online.exe > > http://ifw.podsvirov.pro/cmake/cmake-master-windows-64bit-online.exe > > The installer will install CMake from an online repository and create shortcuts in the start menu. > The composition of the labels is the same as that of the NSIS installer. If you have already used these installers then just click "Start Menu -> CMake -> Uninstall" , then click "Update components" and click "Next" ... Added new features CPack IFW generator. Now you can specify one or more license file for a group of components or for a particular component. As before the source code is available here: http://git.podsvirov.pro/?p=cmake/cpackifwgenerator.git;a=summary HTML version of the documentation is available here: http://ifw.podsvirov.pro/cmake/doc/cmake-3.0/html Note the documentation of the module CPackIFW: http://ifw.podsvirov.pro/cmake/doc/cmake-3.0/html/module/CPackIFW.html Download the source code and collect it yourself or use installers for Windows or Linux http://ifw.podsvirov.pro/cmake). If there is a need to create an online installers with the possibility of renewal for Linux, then contact me and I will make them. Encouraged to read and test the code and share their comments. My purpose here to CPack IFW generator became a part of the project CMake!!! (Sorry for my English, I use a translator) Regards, Konstantin Podsvirov From mantis at public.kitware.com Wed Jul 23 04:56:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 23 Jul 2014 04:56:11 -0400 Subject: [cmake-developers] [CMake 0015034]: target_link_libraries omits some dependencies Message-ID: <59e64381a8ad99d9aeae1040c179b861@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15034 ====================================================================== Reported By: Glenn Coombs Assigned To: ====================================================================== Project: CMake Issue ID: 15034 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-23 04:56 EDT Last Modified: 2014-07-23 04:56 EDT ====================================================================== Summary: target_link_libraries omits some dependencies Description: The target_link_libraries command fails to add the specified linker option under some conditions. Steps to Reproduce: Save the example CMakeLists.txt file attached to this ticket and then run these commands: mkdir build cd build cmake .. make VERBOSE=yes The link command generated for my_lib_shared is as follows: gcc -fPIC -shared -Wl,-soname,libmy_lib_shared.so -o libmy_lib_shared.so CMakeFiles/my_lib_shared.dir/my_lib_shared.c.o libsome_lib_1.a -Wl,-whole-archive libsome_lib_3.a -Wl,-no-whole-archive libsome_lib_2.a -Wl,-whole-archive libsome_lib_4.a libsome_lib_5.a which is incorrect. The lib4 line should include a -no-whole-archive option on the end. If you comment line 25 and uncomment line 26 in the CMakeLists.txt then the correct output is generated: gcc -fPIC -shared -Wl,-soname,libmy_lib_shared.so -o libmy_lib_shared.so CMakeFiles/my_lib_shared.dir/my_lib_shared.c.o libsome_lib_1.a -Wl,-whole-archive libsome_lib_3.a -Wl,-no-whole-archive libsome_lib_2.a -Wl,-whole-archive libsome_lib_4.a -Wl,-Qy,-no-whole-archive libsome_lib_5.a For some reason the -no-whole-archive is omitted unless another option precedes it. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-23 04:56 Glenn Coombs New Issue 2014-07-23 04:56 Glenn Coombs File Added: CMakeLists.txt ====================================================================== From nick at astrant.net Wed Jul 23 08:00:12 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 23 Jul 2014 14:00:12 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. Message-ID: Hey guys, With this https://github.com/NickNick/cmake-dependency-waiting code here, why do b wait for a and c wait for b to be build? The object files could all be build in parallel right? Not doing it is making my distcc-cluster less and less useful the more nodes I add. Is there a way to fix or work around this? Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlrdave at aol.com Wed Jul 23 08:16:42 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 23 Jul 2014 08:16:42 -0400 (EDT) Subject: [cmake-developers] LZMA support Message-ID: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> Wow! Fantastic! Thanks to Daniel, great work on this contribution... This is a ton of tedious work, but it will be very useful. Thank you *very much*. Two minor comments -- in the commit at the tip of this topic: http://public.kitware.com/gitweb?p=stage/cmake.git;a=commitdiff;h=5201fb2e62fb06609b02c83278da6546561a9e9f I think the extensions should be alphabetized, and they should also include "7z" so folks can use the typically smaller 7z files with ExternalProject as well. Would you like me to amend and update the topic? Or would you mind doing the minor edit for that? BTW, I just submitted an Experimental dashboard for this topic using ninja and the VS2012 compiler on Windows 8.1, and it was all green: http://open.cdash.org/buildSummary.php?buildid=3420600 Thanks, David C. From brad.king at kitware.com Wed Jul 23 08:36:53 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 08:36:53 -0400 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: Message-ID: <53CFAC65.5000000@kitware.com> On 07/23/2014 08:00 AM, Nick Overdijk wrote: > With this https://github.com/NickNick/cmake-dependency-waiting code here, why do b wait for a and c wait for b to be build? The object files could all be build in parallel right? Not doing it is making my distcc-cluster less and less useful the more nodes I add. Is there a way to fix or work around > this? See here: http://www.cmake.org/Bug/view.php?id=14726#c35021 http://www.cmake.org/Bug/view.php?id=14726#c35023 -Brad From nick at astrant.net Wed Jul 23 08:58:07 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 23 Jul 2014 14:58:07 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: <53CFAC65.5000000@kitware.com> References: <53CFAC65.5000000@kitware.com> Message-ID: Thanks for the quick reply, but what if c needs b and b needs a? Adding "INTERFACE" will then break the build of course, right, since b isn't really linked to a... Or am I mistaken? On Wed, Jul 23, 2014 at 2:36 PM, Brad King wrote: > On 07/23/2014 08:00 AM, Nick Overdijk wrote: > > With this https://github.com/NickNick/cmake-dependency-waiting code > here, why do b wait for a and c wait for b to be build? The object files > could all be build in parallel right? Not doing it is making my > distcc-cluster less and less useful the more nodes I add. Is there a way to > fix or work around > > this? > > See here: > > http://www.cmake.org/Bug/view.php?id=14726#c35021 > http://www.cmake.org/Bug/view.php?id=14726#c35023 > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at astrant.net Wed Jul 23 09:07:19 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 23 Jul 2014 15:07:19 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> Message-ID: Oh wait, since a is in the interface of b, b will always be accompanied by a, even though it's not a dependency. Is that how it works? On Wed, Jul 23, 2014 at 2:58 PM, Nick Overdijk wrote: > Thanks for the quick reply, but what if c needs b and b needs a? Adding > "INTERFACE" will then break the build of course, right, since b isn't > really linked to a... Or am I mistaken? > > > On Wed, Jul 23, 2014 at 2:36 PM, Brad King wrote: > >> On 07/23/2014 08:00 AM, Nick Overdijk wrote: >> > With this https://github.com/NickNick/cmake-dependency-waiting code >> here, why do b wait for a and c wait for b to be build? The object files >> could all be build in parallel right? Not doing it is making my >> distcc-cluster less and less useful the more nodes I add. Is there a way to >> fix or work around >> > this? >> >> See here: >> >> http://www.cmake.org/Bug/view.php?id=14726#c35021 >> http://www.cmake.org/Bug/view.php?id=14726#c35023 >> >> -Brad >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 23 09:14:20 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 09:14:20 -0400 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> Message-ID: <53CFB52C.3090500@kitware.com> On 07/23/2014 09:07 AM, Nick Overdijk wrote: > Oh wait, since a is in the interface of b, b will always be > accompanied by a, even though it's not a dependency. > Is that how it works? Yes. If B is a static library then it does not really link so its dependencies are only ever used transitively when something else links to B. If B really links as a shared library though then see the following. If target B links to target A then CMake will not compile objects in B until A is done. As explained in my previous link this is because we allow A to contain custom commands that generate headers used by B. The VS and Xcode IDE build systems offer only this granularity since they organize compilation and linking rules of a single target together. The Makefile generator was designed this way too. Only the Ninja generator has a chance of increasing parallelism if the extra ordering dependencies were dropped. We've thought about how to do extra analysis to determine when there is no such custom command to drop them but have not implemented anything yet. You might be able to use OBJECT libraries to increase parallelism for all generators and with no changes to CMake: set(CMAKE_POSITION_INDEPENDENT_CODE ON) add_library(Aobjs OBJECT a1.c a2.c) add_library(Bobjs OBJECT b1.c b2.c) add_library(Cobjs OBJECT c1.c c2.c) set(dummy_c dummy.c) # needed for VS 6 and Xcode add_library(A SHARED $ ${dummy_c}) add_library(B SHARED $ ${dummy_c}) add_library(C SHARED $ ${dummy_c}) target_link_libraries(B PUBLIC A) target_link_libraries(C PUBLIC B) This way the object compilations will be completely independent of one another and of the linking and ordering dependencies. -Brad From nick at astrant.net Wed Jul 23 09:19:05 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 23 Jul 2014 15:19:05 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: <53CFB52C.3090500@kitware.com> References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> Message-ID: Crystal clear. Another layer of indirection eh? I'll see if I can work with that... Thanks for the explanation. On Wed, Jul 23, 2014 at 3:14 PM, Brad King wrote: > On 07/23/2014 09:07 AM, Nick Overdijk wrote: > > Oh wait, since a is in the interface of b, b will always be > > accompanied by a, even though it's not a dependency. > > Is that how it works? > > Yes. If B is a static library then it does not really link so > its dependencies are only ever used transitively when something > else links to B. If B really links as a shared library though > then see the following. > > If target B links to target A then CMake will not compile objects > in B until A is done. As explained in my previous link this is > because we allow A to contain custom commands that generate > headers used by B. The VS and Xcode IDE build systems offer only > this granularity since they organize compilation and linking rules > of a single target together. The Makefile generator was designed > this way too. Only the Ninja generator has a chance of increasing > parallelism if the extra ordering dependencies were dropped. We've > thought about how to do extra analysis to determine when there is > no such custom command to drop them but have not implemented anything > yet. > > You might be able to use OBJECT libraries to increase parallelism > for all generators and with no changes to CMake: > > set(CMAKE_POSITION_INDEPENDENT_CODE ON) > add_library(Aobjs OBJECT a1.c a2.c) > add_library(Bobjs OBJECT b1.c b2.c) > add_library(Cobjs OBJECT c1.c c2.c) > set(dummy_c dummy.c) # needed for VS 6 and Xcode > add_library(A SHARED $ ${dummy_c}) > add_library(B SHARED $ ${dummy_c}) > add_library(C SHARED $ ${dummy_c}) > target_link_libraries(B PUBLIC A) > target_link_libraries(C PUBLIC B) > > This way the object compilations will be completely independent > of one another and of the linking and ordering dependencies. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 23 10:43:20 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 10:43:20 -0400 Subject: [cmake-developers] LZMA support In-Reply-To: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> Message-ID: <53CFCA08.1090605@kitware.com> On 07/23/2014 08:16 AM, David Cole wrote: > Thanks to Daniel, great work on this contribution... This is a ton of > tedious work, but it will be very useful. Thank you *very much*. +1 I've merged the topic to 'next' for testing, but without the CPack or ExternalProject pieces. Likely some more portability fixes will be required after testing on the dashboard. Once that is clean I will add the other changes again on top of the revised topic. > Two minor comments -- in the commit at the tip of this topic: For reference, that change is to ExternalProject with hunks like: - if(filename MATCHES "(\\.|=)(bz2|tar\\.gz|tgz|zip)$") + if(filename MATCHES "(\\.|=)(xz|bz2|tar\\.gz|tgz|zip)$") > I think the extensions should be alphabetized, and they should also > include "7z" so folks can use the typically smaller 7z files with > ExternalProject as well. Thanks. Actually I think adding "xz" is incorrect anyway. We support compressed tarballs, not arbitrary compressed files. Therefore the list should be 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip correct? -Brad From nilsgladitz at gmail.com Wed Jul 23 10:46:59 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 23 Jul 2014 16:46:59 +0200 Subject: [cmake-developers] LZMA support In-Reply-To: <53CFCA08.1090605@kitware.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> Message-ID: <53CFCAE3.2060200@gmail.com> On 23.07.2014 16:43, Brad King wrote: > Therefore the list should be > > 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip > > correct? > bz2 -> tar\\.bz2 as well while you are at it(?) Nils From eike at sf-mail.de Wed Jul 23 10:48:13 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 23 Jul 2014 16:48:13 +0200 Subject: [cmake-developers] LZMA support In-Reply-To: <53CFCA08.1090605@kitware.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> Message-ID: Am 23.07.2014 16:43, schrieb Brad King: > On 07/23/2014 08:16 AM, David Cole wrote: >> Thanks to Daniel, great work on this contribution... This is a ton of >> tedious work, but it will be very useful. Thank you *very much*. > > +1 > > I've merged the topic to 'next' for testing, but without the CPack > or ExternalProject pieces. Likely some more portability fixes > will be required after testing on the dashboard. Once that is clean > I will add the other changes again on top of the revised topic. > >> Two minor comments -- in the commit at the tip of this topic: > > For reference, that change is to ExternalProject with hunks like: > > - if(filename MATCHES "(\\.|=)(bz2|tar\\.gz|tgz|zip)$") > + if(filename MATCHES "(\\.|=)(xz|bz2|tar\\.gz|tgz|zip)$") > >> I think the extensions should be alphabetized, and they should also >> include "7z" so folks can use the typically smaller 7z files with >> ExternalProject as well. > > Thanks. Actually I think adding "xz" is incorrect anyway. We > support compressed tarballs, not arbitrary compressed files. > Therefore the list should be > > 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip > > correct? Well, then it should be tar.bz2, too. And since this is a regex anyway: 7z|tar\\.bz2|tar\\.[gx]z|t[xg]z|zip Eike From dlrdave at aol.com Wed Jul 23 11:23:33 2014 From: dlrdave at aol.com (David Cole) Date: Wed, 23 Jul 2014 11:23:33 -0400 (EDT) Subject: [cmake-developers] LZMA support In-Reply-To: References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> Message-ID: <8D174A1337641BD-1AC8-15048@webmail-va102.sysops.aol.com> >> Thanks. Actually I think adding "xz" is incorrect anyway. We >> support compressed tarballs, not arbitrary compressed files. >> Therefore the list should be >> >> 7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip >> >> correct? > > Well, then it should be tar.bz2, too. And since this is a regex anyway: > > 7z|tar\\.bz2|tar\\.[gx]z|t[xg]z|zip Yes, correct. I still like the original "list all the extensions separately and explicitly" technique rather than "'simplifying' the regex" -- because the first one is an "easier to parse as a human being" regex. Also, it's "more greppable" if somebody is looking for .gz or .xz or tgz or txz. D From mantis at public.kitware.com Wed Jul 23 13:54:12 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 23 Jul 2014 13:54:12 -0400 Subject: [cmake-developers] [CMake 0015035]: Build time file copy_if_different Message-ID: <6a98e9280853afeaa932fc86fff8b0f1@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15035 ====================================================================== Reported By: Daniele E. Domenichelli Assigned To: ====================================================================== Project: CMake Issue ID: 15035 Category: CMake Reproducibility: have not tried Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-23 13:54 EDT Last Modified: 2014-07-23 13:54 EDT ====================================================================== Summary: Build time file copy_if_different Description: As a follow up to this thread[1], we agreed that in order to create a project that other project can use both from the install and build tree, in some cases it is a good idea to replicate the installation tree or part of it inside the build directory, so that the relative paths are the same when the package is used from the build tree or from the installation. [1]http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10492 file(COPY) copies the file is copied at CMake time, not a build time, and cmake is not triggered when the original file is modified, and therefore the copy is not performed at build time if the file is modified and the just runs make (or "build" for visual studio and other IDEs). Also file(COPY) does not have an option to copy the file only if the file(s) is(are) different and could trigger an unnecessary rebuild. execute_process(COMMAND "${CMAKE_COMMAND} -E copy_if_different") does not trigger unnecessary builds, but it is still in the configure phase configure_file(COPYONLY) still copies the file in the configure phase, but it will trigger a cmake run if the original file was modified. Nonetheless it has a few disadvantages: * It's less discoverable than file(COPY) * It can copy just one file at the time, therefore it is not easy to reproduce an install tree * It triggers a cmake run, that will slow down the build * The files to configure might be the product of some build step and therefore not available during the configure step. At the moment (as far as I know) the only way to do it is to use add_custom_command to execute some external CMake script that runs "${CMAKE_COMMAND} -E copy_if_different", but this require a lot of work to handle the file level and target level dependencies correctly. It would be very useful to be able to copy files at build time only if different, without triggering a cmake run, and with a syntax similar to the install command. I suggest to implement one of the following ideas: * Have an option for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the install tree in the binary directory, but at build time, and only if the destination file is missing or is different from the source. * Add some modes to the export() command, for example export(FILES/PROGRAMS/DIRECTORY), with the same signature of install(FILES/PROGRAMS/DIRECTORY), and that replicates the behaviour of this command but at build time and in in the similar way as export(EXPORT) replicates the behaviour of install(EXPORT) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-23 13:54 Daniele E. DomenichelliNew Issue ====================================================================== From brad.king at kitware.com Wed Jul 23 14:39:17 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 14:39:17 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> Message-ID: <53D00155.5000002@kitware.com> On 07/22/2014 07:44 AM, Stephen Kelly wrote: > Daniele E. Domenichelli wrote: >> By the way, is there a reason why file(COPY) does not have an option to >> copy the file only if the file(s) is(are) different. > > configure_file(COPY_ONLY) does that. file(COPY_IF_DIFFERENT) would just do > the same thing but would be more discoverable and might be a good idea. Our file(INSTALL) command used by scripts for "make install" at one time did do a copy-if-different but for incremental re-installations it spent a very long time comparing content. It was decided instead to make the re-copy decision based only on the file timestamp comparison. This makes it very fast. The file(COPY) command is just a binding to file(INSTALL) that does not print status messages and has slightly different defaults. The file(COPY) command already has many keyword options, so a new COPY_IF_DIFFERENT to request the time-consuming comparison could be added. >> Since you were asking if CMake misses some important feature, I believe >> that a very useful feature to have would be to be able to have an option >> for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the >> install tree in the binary directory > > Yes, seems like something worth investigating. I don't think we need to have a build tree, install-in-build-tree, and install-tree all managed by a single build tree. Things like INSTALL_RPATH do not make sense when there are two possible "install" locations. An install-in-build-tree directory is not easily defined in multi-config generators. If you want to test installation then set CMAKE_INSTALL_PREFIX to $build/prefix or something and use the normal "make install" target. Some projects also arrange their layout within the build tree to look like the install tree by setting CMAKE_RUNTIME_OUTPUT_DIRECTORY[_] and related variables appropriately. Returning to CMakePackageConfigHelpers, I work on several projects that provide one Config.cmake file in the build tree and one in the install tree. They are generated by hand. I do not use CMakePackageConfigHelpers. IMO it is good for getting projects started without having to learn all the details. For mature projects that want to do fancy things like supporting applications from the build tree, manual generation of the package configuration files becomes worthwhile. -Brad From konstantin at podsvirov.pro Wed Jul 23 14:59:44 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 23 Jul 2014 22:59:44 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <3104551406104718@web10h.yandex.ru> References: <3923551405583879@web23m.yandex.ru> <3104551406104718@web10h.yandex.ru> Message-ID: <6560191406141984@web27m.yandex.ru> CPack IFW generator built an online installer itself on Linux! 23.07.2014, 12:39, "Konstantin Podsvirov" : > Update as of July 23, available! The installer for 64-bit versions of Linux are available here: http://ifw.podsvirov.pro/cmake/cmake-master-linux-64bit-online.run Encouraged to test and write your own reviews. As before, I will try to build updates once a week. Regards, Konstantin Podsvirov From brad.king at kitware.com Wed Jul 23 16:44:09 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 23 Jul 2014 16:44:09 -0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <2681081405582381@web7g.yandex.ru> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> Message-ID: <53D01E99.3090905@kitware.com> On 07/17/2014 03:33 AM, Konstantin Podsvirov wrote: > Now I fixed it. Should work. Thanks for this contribution! I finally made time to look over the changes and integrate them. Overall, very nice work. I squashed your history down to a single commit, fixed newlines, fixed indentation, fixed long lines, and made couple minor portability tweaks. The new draft commit is: CPack: Add an "IFW" generator for Qt Framework Installer http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9006316 You can compare it to your last commit (3c506bd2) with: git diff 3c506bd2 a9006316 -w --color-words=. to see that there are almost no non-whitespace changes. I also added a slightly larger portability change: CPackIFW: Replace use of strftime with cmTimestamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a943d41d but I'm not set up to test it. Please fetch from our repo to try out these versions to make sure I didn't break anything. These draft commits are now in 'next' for upstream testing. Thanks! -Brad From mathieu.marache at gmail.com Thu Jul 24 03:57:56 2014 From: mathieu.marache at gmail.com (Mathieu MARACHE) Date: Thu, 24 Jul 2014 09:57:56 +0200 Subject: [cmake-developers] [patch] Qt plugins are missing when deploying Message-ID: I added two plugins qnativewifi and qtga that where missing in FindQt4.cmake and thus where not deployed with DeployQt4.cmake although they were mentioned in the plugins parameters. This is a patch is against current master but could well be back ported to earlier versions since this file has slightly changed thanks -- n?????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-nativewifi-and-qtga-plugins.patch Type: application/octet-stream Size: 2470 bytes Desc: not available URL: From mantis at public.kitware.com Thu Jul 24 05:48:01 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 24 Jul 2014 05:48:01 -0400 Subject: [cmake-developers] [CMake 0015036]: "make --question" always returns 1 Message-ID: <079a36c52269e1672afc107b5bdf2528@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15036 ====================================================================== Reported By: Simon Ask Ulsnes Assigned To: ====================================================================== Project: CMake Issue ID: 15036 Category: (No Category) Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-24 05:48 EDT Last Modified: 2014-07-24 05:48 EDT ====================================================================== Summary: "make --question" always returns 1 Description: In my project, I'm relying on the build system being able to answer the question whether or not the source tree has been updated or not. Currently, Makefiles generated by CMake do not support this usage for one reason or another. The exit code of "make --question" should be 0 if all targets (or the specified target) are up to date, and nonzero if changes have been made. However, CMake-generated Makefiles always indicate that changes have been made, which results in nontrivial work being executed unnecessarily. Steps to Reproduce: 1. Create simple project with a single source file and a CMakeLists.txt 2. Create the Makefile with `cmake .` 3. Run `make`. 4. Run `make --question`. 5. Observe that the exit code is 1 instead of 0, even though the source file was not updated between steps 3 and 4. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-24 05:48 Simon Ask UlsnesNew Issue ====================================================================== From mantis at public.kitware.com Thu Jul 24 09:11:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 24 Jul 2014 09:11:47 -0400 Subject: [cmake-developers] [CMake 0015037]: given a cpp file, how to know what target it's built and where is the flags.make is placed Message-ID: <87648039c2ef18534583ffdafea701c2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15037 ====================================================================== Reported By: chen bin Assigned To: ====================================================================== Project: CMake Issue ID: 15037 Category: CMake Reproducibility: always Severity: major Priority: immediate Status: new ====================================================================== Date Submitted: 2014-07-24 09:11 EDT Last Modified: 2014-07-24 09:11 EDT ====================================================================== Summary: given a cpp file, how to know what target it's built and where is the flags.make is placed Description: assume the generator is GNU make. how to know what executable or library is built from the build directory *by my software*? the executable or library is built through the rule "add_executable" or "add_library" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-24 09:11 chen bin New Issue ====================================================================== From nick at astrant.net Thu Jul 24 17:47:19 2014 From: nick at astrant.net (Nick Overdijk) Date: Thu, 24 Jul 2014 23:47:19 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> Message-ID: I'm using target_include_directories of A to get some include directories into B well, so I can't use target_link_libraries(A INTERFACE B), and I can't seem to use the OBJECT-way neither since B's sources won't compile without A's INTERFACE_INCLUDE_DIRECTORIES... Any suggestions? On Wed, Jul 23, 2014 at 3:19 PM, Nick Overdijk wrote: > Crystal clear. Another layer of indirection eh? I'll see if I can work > with that... Thanks for the explanation. > > > On Wed, Jul 23, 2014 at 3:14 PM, Brad King wrote: > >> On 07/23/2014 09:07 AM, Nick Overdijk wrote: >> > Oh wait, since a is in the interface of b, b will always be >> > accompanied by a, even though it's not a dependency. >> > Is that how it works? >> >> Yes. If B is a static library then it does not really link so >> its dependencies are only ever used transitively when something >> else links to B. If B really links as a shared library though >> then see the following. >> >> If target B links to target A then CMake will not compile objects >> in B until A is done. As explained in my previous link this is >> because we allow A to contain custom commands that generate >> headers used by B. The VS and Xcode IDE build systems offer only >> this granularity since they organize compilation and linking rules >> of a single target together. The Makefile generator was designed >> this way too. Only the Ninja generator has a chance of increasing >> parallelism if the extra ordering dependencies were dropped. We've >> thought about how to do extra analysis to determine when there is >> no such custom command to drop them but have not implemented anything >> yet. >> >> You might be able to use OBJECT libraries to increase parallelism >> for all generators and with no changes to CMake: >> >> set(CMAKE_POSITION_INDEPENDENT_CODE ON) >> add_library(Aobjs OBJECT a1.c a2.c) >> add_library(Bobjs OBJECT b1.c b2.c) >> add_library(Cobjs OBJECT c1.c c2.c) >> set(dummy_c dummy.c) # needed for VS 6 and Xcode >> add_library(A SHARED $ ${dummy_c}) >> add_library(B SHARED $ ${dummy_c}) >> add_library(C SHARED $ ${dummy_c}) >> target_link_libraries(B PUBLIC A) >> target_link_libraries(C PUBLIC B) >> >> This way the object compilations will be completely independent >> of one another and of the linking and ordering dependencies. >> >> -Brad >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Fri Jul 25 07:05:39 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Fri, 25 Jul 2014 07:05:39 -0400 Subject: [cmake-developers] [CMake 0015038]: Linking $ into a static library is broken with Xcode 6 Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15038 ====================================================================== Reported By: Jamie Kirkpatrick Assigned To: ====================================================================== Project: CMake Issue ID: 15038 Category: (No Category) Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-25 07:05 EDT Last Modified: 2014-07-25 07:05 EDT ====================================================================== Summary: Linking $ into a static library is broken with Xcode 6 Description: Trying to use $ to link an object target into a static library is broken with Xcode 6 because it uses separate flags for linking static libraries. Steps to Reproduce: - Create an object library target with a source file compiled in. - Create a static library that links the object library in. - Create a binary that uses something from the original source file and links the static library in. - Compiling will result in undefined symbols. Additional Information: Previously the OTHER_LDFLAGS variable was respected but now it uses OTHER_LIBTOOLFLAGS which breaks things because the old variable was used to specify the list of extra object files to link into the static library target. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-25 07:05 Jamie KirkpatrickNew Issue ====================================================================== From daniele.domenichelli at gmail.com Fri Jul 25 09:54:59 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Fri, 25 Jul 2014 15:54:59 +0200 Subject: [cmake-developers] Install in Build Tree [Was: Topic CMakePackageConfigHelpers_build_tree] In-Reply-To: <53D00155.5000002@kitware.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> Message-ID: <53D261B3.4000702@gmail.com> [Changing subject in order to keep the conversation separate] On 23/07/14 20:39, Brad King wrote: >>> Since you were asking if CMake misses some important feature, I believe >>> that a very useful feature to have would be to be able to have an option >>> for the install(FILES/PROGRAMS/DIRECTORY) command that reproduces the >>> install tree in the binary directory >> >> Yes, seems like something worth investigating. > > I don't think we need to have a build tree, install-in-build-tree, and > install-tree all managed by a single build tree. Things like > INSTALL_RPATH do not make sense when there are two possible "install" > locations. An install-in-build-tree directory is not easily defined > in multi-config generators. Sorry, maybe I didn't explain the problem properly, there are no "build tree", "install-in-build-tree", and "install-tree", but only "build tree" and "install-tree" I'm not referring to the installation of "TARGETS" (for which the rpath and CMAKE_RUNTIME_OUTPUT_DIRECTORY[_] and related variables are enough), I'm referring to the "data files" (i.e. whatever usually goes to /share) that may or may not be generated by cmake or by the build step (not as target but as configure_file or as a product of some command) and are usually installed with "install(FILES/PROGRAMS/DIRECTORY)". These files might not be related to a target, therefore it might not make sense to "add" them to a target and install them with the install(TARGET) call (like you could do with PUBLIC_HEADERs and similar). I think there are good reasons for copying the files, for example: * Your program expects to find the data files in a certain relative path or with a certain tree structure and you have some good reason for not keeping them with the same structure in the source folder. * You have some files that are coming from the source tree but some are generated by CMake or produced during the build and the program expects to find all of them in the same folder. If these files are not in the expected place, the build tree might not be usable, and the installation step would be required to use your project. > If you want to test installation then set CMAKE_INSTALL_PREFIX to > $build/prefix or something and use the normal "make install" target. What I want to be able to do is not test the installation, but to be able to use the library from the build tree. Using an installation for testing different builds is more complicated, because you will have to set a different CMAKE_INSTALL_PREFIX and to run the install phase every time you make a change. Finally it will require to set LD_LIBRARY_PATH environment variable, or to set CMAKE_SKIP_INSTALL_RPATH cmake variable to FALSE. > Some projects also arrange their layout within the build tree to look > like the install tree by setting CMAKE_RUNTIME_OUTPUT_DIRECTORY[_] > and related variables appropriately. That's exactly what I would like to be able to do, but for "data files" as well, and at the moment that is possible, but not in an easy way. Cheers, Daniele From daniele.domenichelli at gmail.com Fri Jul 25 10:00:42 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Fri, 25 Jul 2014 16:00:42 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D00155.5000002@kitware.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> Message-ID: <53D2630A.1030106@gmail.com> On 23/07/14 20:39, Brad King wrote: > Returning to CMakePackageConfigHelpers, I work on several projects > that provide one Config.cmake file in the build tree and one > in the install tree. They are generated by hand. I do not use > CMakePackageConfigHelpers. IMO it is good for getting projects > started without having to learn all the details. For mature projects > that want to do fancy things like supporting applications from the > build tree, manual generation of the package configuration files > becomes worthwhile. Sorry if I insist, but I still don't understand why not allowing to be able to use CMakePackageConfigHelpers for the build tree, and I still cannot find a valid alternative therefore I'll do a last desperate defence of my patch to try to convince you and Steve. ;) I think that it is good for new projects to be able to use the build tree before actually testing the installation of the project, as this will speed up the development process. From my experience, the installation step is finalized later in the creation step of a library. 'configure_package_config_file()' allows you to do whatever you want in your input config file, exactly like 'configure_file()', but it is still very helpful for handling relative paths correctly. I agree that "perfect" config files should not contain paths, but I believe that if no paths should be in the config file, then 'configure_package_config_file()' does not make not much sense neither for mature nor new projects (except for simplify the handling of components) and perhaps should be deprecated or replaced by something else. On the other hand if paths are acceptable be in the config files (as relative paths), then I don't see why generating them in the same way both for build and install tree shouldn't be allowed, and I believe that there are several valid use cases where the paths are required. I work too on several projects that provide one Config.cmake file in the build tree and one for the installation, but they use paths, and the paths in the installed files are absolute. I'm working on porting them to a "modern" CMake style, but I cannot suddenly drop compatibility with older versions, and I cannot drop the path variables from the config files. Moreover I cannot push the dependency on the latest CMake and I'm stuck with 2.8.9, that misses several of the new features required for a full "modern" CMake style are still missing, thus the paths are necessary. Therefore for now I'm trying to port them to use relative paths, in order to simplify the creation of the installers for Windows, and this led to trying to port them from configure_file() to configure_package_config_file(). Unfortunately I cannot but drop compatibility with having a working build tree. The result is that I had to choose between these options (I couldn't find any other option, but I'm still open to different solution if you can think one): 1) Not using CMakePackageConfigHelpers and keep using configure_file with the absolute paths 2) Using two different input files and two different calls. 3) Pay very good attention to pass only absolute path to configure_package_config_file, and keep an "ugly" config file in the build directory with PACKAGE_PREFIX_DIR pointing to the CMAKE_INSTALL_PREFIX, and the variables with absolute path. As I mentioned before, this works, but it is error prone because using relative path will result in a broken config file. 4) Use a hack like (this actually works, but it looks horrible to me and require an explaination comment wherever you use it...) set(_CMAKE_INSTALL_PREFIX "${CMAKE_INSTALL_PREFIX}") set(CMAKE_INSTALL_PREFIX "${CMAKE_BINARY_DIR}") configure_package_config_file(...) set(CMAKE_INSTALL_PREFIX "${_CMAKE_INSTALL_PREFIX}") unset(_CMAKE_INSTALL_PREFIX) 5) Ship a modified version of CMakePackageConfigHelpers with my project. All these options seem bad to me, therefore I went for the "cleanest" solution, i.e. get the patch merged upstream, in order to ship with my projects the update "official" CMakePackageConfigHelpers module that I will remove when I can finally depend on the version that will contain the patched version. Anyway, if I still didn't convince you, at least now nobody can say I didn't try... ;) Do you want me to drop the patch and push the restructured documentation in a new topic? Cheers, Daniele P.S. Sorry for the long mail From norman-k-williams at uiowa.edu Fri Jul 25 17:05:38 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Fri, 25 Jul 2014 21:05:38 +0000 Subject: [cmake-developers] CMake, Ninja generator, and ExternalProjects Message-ID: I?ve been using the Ninja generator on Linux and OS X lately, because it handles command output during parallel builds better. But big ?SuperBuild? projects ? Slicer being exhibit A ? which builds using the CMake ExternalProjects Module, have a couple of annoyances. 1. Since Ninja buffers command output, you won?t see the output of an ExternalProject build until it?s completed. This can take considerable time for larger projects. 2. Ninja gets the number of processes from the OS, and executes that many processes, even if it?s been called from another instance of Ninja. It doesn?t have GnuMake?s process pool and inter-instance communication. Cmake could generate ninja build files that would address these problems, somewhat. Ninja has a ?l flag that won?t start new jobs if the load is greater than . There?s also the ?console pool? facility that would allow ExternalProject builds to display output, though that would get back to the Gmake issue of different processes interleaving output. Obviously, Ninja could be fixed to behave better when run recursively, either by implementing Gmake style intra-instance communication. But I?m not sure that fits their design and performance goals. I?ve raised it on the Ninja list? Perhaps I?m simply bumping up against the limits of the ExternalProject module ? since ExternalProjects are essentially walled off from their parent Cmake projects and can be built according to any recipe, it may be too much to hope for much in the way of Ninja project optimization. ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantis at public.kitware.com Sun Jul 27 04:07:13 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 27 Jul 2014 04:07:13 -0400 Subject: [cmake-developers] [CMake 0015039]: CMake linked against libc++ on OS X 10.7 cuts lines at 1024 characters Message-ID: <81ec632e427199cfe72b1973df041515@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15039 ====================================================================== Reported By: Mojca Miklavec Assigned To: ====================================================================== Project: CMake Issue ID: 15039 Category: CMake Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-27 04:07 EDT Last Modified: 2014-07-27 04:07 EDT ====================================================================== Summary: CMake linked against libc++ on OS X 10.7 cuts lines at 1024 characters Description: As already reported (http://public.kitware.com/pipermail/cmake-developers/2014-June/010712.html) building CMake on OS X 10.7 against libc++ fails because some lines are cut at 1024 characters when reading from link.txt. If I manually execute a couple of commands that have been "cut", the build eventually succeeds, but the resulting cmake binary is "useless" because any project that requires lines longer than 1024 characters to compile code, fails to build as well. Steps to Reproduce: Compile CMake on OS X 10.7 using CC='/usr/bin/clang' CXX='/usr/bin/clang++' CXXFLAGS='-stdlib=libc++' Additional Information: Brad King wrote: The lines are read here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmcmd.cxx;hb=v3.0.0#l988 using the GetLineFromStream helper: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/SystemTools.cxx;hb=v3.0.0#l4157 Note the buffer size is 1024. Something must go wrong with the stream state to make it look like EOL or EOF to this code. Ben Boeckel wrote: The proper way to read lines from a file using iostream is: std::string line; while (std::getline(istr, line)) { // use line } Unfortunately, it looks like there's unavoidable extra logic in there. Maybe we could do: #ifdef BROKEN_STREAMS // crutch code #else // sanity #endif ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-27 04:07 Mojca Miklavec New Issue ====================================================================== From mantis at public.kitware.com Sun Jul 27 04:29:40 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Sun, 27 Jul 2014 04:29:40 -0400 Subject: [cmake-developers] [CMake 0015040]: CMake needs to support building against "/" on OS X with a deployment target set Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15040 ====================================================================== Reported By: Mojca Miklavec Assigned To: ====================================================================== Project: CMake Issue ID: 15040 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-27 04:29 EDT Last Modified: 2014-07-27 04:29 EDT ====================================================================== Summary: CMake needs to support building against "/" on OS X with a deployment target set Description: CMake doesn't allow setting -DCMAKE_OSX_DEPLOYMENT_TARGET="10.8" together with -DCMAKE_OSX_SYSROOT="/". According to an Apple engineer that's a problem/flaw. See also the whole discussion at https://trac.macports.org/ticket/44125 (If you are able to CC others, please add 'jeremyhu' at macports . org to this ticket.) I'm attaching his patch that is currently being used in MacPorts: https://trac.macports.org/browser/trunk/dports/devel/cmake/files/patch-Modules-Platform-Darwin.cmake.diff?rev=122338 Steps to Reproduce: Run cmake -DCMAKE_OSX_DEPLOYMENT_TARGET="10.8" -DCMAKE_OSX_SYSROOT="/" ... on any CMake-based project. The build always fails, complaining that CMAKE_OSX_SYSROOT should also be set. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-27 04:29 Mojca Miklavec New Issue 2014-07-27 04:29 Mojca Miklavec File Added: patch-Modules-Platform-Darwin.cmake.diff ====================================================================== From mantis at public.kitware.com Mon Jul 28 09:08:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 28 Jul 2014 09:08:11 -0400 Subject: [cmake-developers] [CMake 0015042]: Add CPACK_PACKAGE_COMPONENT_NAME that naming component packages gets more flexible Message-ID: <5894fae9699cdca888547190956de1e9@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15042 ====================================================================== Reported By: Lucas Betschart Assigned To: ====================================================================== Project: CMake Issue ID: 15042 Category: CPack Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-28 09:08 EDT Last Modified: 2014-07-28 09:08 EDT ====================================================================== Summary: Add CPACK_PACKAGE_COMPONENT_NAME that naming component packages gets more flexible Description: If I build my -dev package with cpack COMPONENT flag, it get this: opentxs-0.93.0-1.x86_64-dev.tar.gz (I add the version and system to the name), but I'd like to have opentxs-dev-0.93.0-1.x86_64.tar.gz Please add CPACK_PACKAGE_COMPONENT_NAME as a variable so one can use that in the package file name. So I could do something like this: set(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_COMPONENT_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_PACKAGE_RELEASE}.${CMAKE_SYSTEM_PROCESSOR}") Thx! Additional Information: In your source: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CPack/cmCPackGenerator.cxx;h=9336bedecad9ab0f0a6354cfe5597f670fb971f0;hb=HEAD#l1427 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-28 09:08 Lucas BetschartNew Issue ====================================================================== From brad.king at kitware.com Mon Jul 28 09:44:01 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 09:44:01 -0400 Subject: [cmake-developers] [patch] Qt plugins are missing when deploying In-Reply-To: References: Message-ID: <53D653A1.9070905@kitware.com> On 07/24/2014 03:57 AM, Mathieu MARACHE wrote: > I added two plugins qnativewifi and qtga that where missing in FindQt4.cmake Applied, thanks: FindQt4: Add nativewifi and qtga plugins http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b5052b0 -Brad From brad.king at kitware.com Mon Jul 28 10:02:23 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 10:02:23 -0400 Subject: [cmake-developers] Install in Build Tree In-Reply-To: <53D261B3.4000702@gmail.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D261B3.4000702@gmail.com> Message-ID: <53D657EF.9000800@kitware.com> On 07/25/2014 09:54 AM, Daniele E. Domenichelli wrote: >> Some projects also arrange their layout within the build tree to look >> like the install tree by setting CMAKE_RUNTIME_OUTPUT_DIRECTORY[_] >> and related variables appropriately. > > That's exactly what I would like to be able to do, but for "data files" > as well, and at the moment that is possible, but not in an easy way. Okay, that clarifies things. The proposal in 15035 makes more sense now. FYI, CMake solves this problem for locating its own resources when running in the build tree by looking for a file relative to the executable whose content tells it where to find the resources directly out of the source tree: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmSystemTools.cxx;hb=v3.0.0#l2187 -Brad From brad.king at kitware.com Mon Jul 28 10:11:39 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 10:11:39 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D2630A.1030106@gmail.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> Message-ID: <53D65A1B.3000202@kitware.com> On 07/25/2014 10:00 AM, Daniele E. Domenichelli wrote: > Sorry if I insist, but I still don't understand why not allowing to be > able to use CMakePackageConfigHelpers for the build tree I didn't mean to imply that the patch is not acceptable. After the revisions to the documentation from our discussion in another branch of this thread I think it is ready for testing in 'next'. -Brad From brad.king at kitware.com Mon Jul 28 10:19:28 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 10:19:28 -0400 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> Message-ID: <53D65BF0.8090106@kitware.com> On 07/24/2014 05:47 PM, Nick Overdijk wrote: > I'm using target_include_directories of A to get some include > directories into B well, so I can't use > target_link_libraries(A INTERFACE B), Can you clarify this with sample code please? > and I can't seem to use the OBJECT-way neither since B's sources > won't compile without A's INTERFACE_INCLUDE_DIRECTORIES... Usage requirements were designed with target_link_libraries as the main way to propagate them, but OBJECT libraries do not allow use with target_link_libraries. This is an open problem with the design of the two features. See also discussion here: http://www.cmake.org/Bug/view.php?id=14970 -Brad From brad.king at kitware.com Mon Jul 28 11:00:07 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Jul 2014 11:00:07 -0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <53D01E99.3090905@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> Message-ID: <53D66577.2050506@kitware.com> On 07/23/2014 04:44 PM, Brad King wrote: > These draft commits are now in 'next' for upstream testing. After squashing in one fixup for building with CMake < 2.8.9 this feature is now in master: CPack: Add an "IFW" generator for Qt Framework Installer http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=44850a26 CPackIFW: Replace use of strftime with cmTimestamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=73b336c9 Help: Add notes for topic 'cpack-ifw-generator' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b9be4d21 -Brad From daniele.domenichelli at gmail.com Mon Jul 28 11:07:41 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Mon, 28 Jul 2014 17:07:41 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D65A1B.3000202@kitware.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> <53D65A1B.3000202@kitware.com> Message-ID: <53D6673D.9080109@gmail.com> On 28/07/14 16:11, Brad King wrote: > On 07/25/2014 10:00 AM, Daniele E. Domenichelli wrote: >> Sorry if I insist, but I still don't understand why not allowing to be >> able to use CMakePackageConfigHelpers for the build tree > > I didn't mean to imply that the patch is not acceptable. After the > revisions to the documentation from our discussion in another branch > of this thread I think it is ready for testing in 'next'. Sorry, I misunderstood your email! I applied the changes you requested to the documentation, rebased, and merged to next for testing. Thanks, Daniele From mantis at public.kitware.com Mon Jul 28 11:20:41 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 28 Jul 2014 11:20:41 -0400 Subject: [cmake-developers] [CMake 0015043]: How to convert Visual Studio .props file into cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.gccxml.org/Bug/view.php?id=15043 ====================================================================== Reported By: Ravi Raman Assigned To: ====================================================================== Project: CMake Issue ID: 15043 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-07-28 11:20 EDT Last Modified: 2014-07-28 11:20 EDT ====================================================================== Summary: How to convert Visual Studio .props file into cmake Description: Hello, We are using CMake 3.0 on Windows. Our main objective is to convert Microsoft Visual Studio built solution to CMake 3.0 solution. In the process of doing so, we have come across many Visual Studio property files (.props) which get included in the Visual Studio project files (.vcxproj) files. For example in a Visual Studio project file , the Property file (test.props) gets included as follows: To achieve the same thing, in the CMakeLists file we are using the following command: set_target_properties(testproj PROPERTIES VS_PROPERTY_SHEETS "${TestCfg}/test.props") Note that we have set TestCfg appropriately in one of the .cmake files that we include in our CMakeLists.txt The cmake build is successful and the cmake VCX project also gets created. But that vcx project does not contain the entry of the test.props file. Please let us know what we are missing or doing wrong. Also, is there any other way to include .props files in cmake. Any help in this regard would be appreciated. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-28 11:20 Ravi Raman New Issue ====================================================================== From mantis at public.kitware.com Mon Jul 28 11:32:30 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Mon, 28 Jul 2014 11:32:30 -0400 Subject: [cmake-developers] [CMake 0015044]: How to convert existing Visual Studio .targets file to cmake Message-ID: The following issue has been SUBMITTED. ====================================================================== http://www.gccxml.org/Bug/view.php?id=15044 ====================================================================== Reported By: Ravi Raman Assigned To: ====================================================================== Project: CMake Issue ID: 15044 Category: CMake Reproducibility: always Severity: major Priority: high Status: new ====================================================================== Date Submitted: 2014-07-28 11:32 EDT Last Modified: 2014-07-28 11:32 EDT ====================================================================== Summary: How to convert existing Visual Studio .targets file to cmake Description: Hello, We are using CMake 3.0 on Windows. Our main objective is to convert Microsoft Visual Studio built solution to CMake 3.0 solution. In the process of doing so, we have come across many Visual Studio targets files (files with extension .targets) which get included in the Visual Studio project files (.vcxproj) files. For example in a Visual Studio project file , the targets file (test.targets) gets included as follows: To achieve the same thing, in the CMakeLists file we are using the following command: add_custom_targets() with the appropriate target name "test" Please let us know if this is the correct way to convert existing Visual Studio .targets files to cmake ? If this is incorrect, please let us know how to achieve it with a simple example. Thanks. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-28 11:32 Ravi Raman New Issue ====================================================================== From nilsgladitz at gmail.com Tue Jul 29 03:31:41 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 29 Jul 2014 09:31:41 +0200 Subject: [cmake-developers] CMAKE_${lang}_COMPILER_LINKER_OPTION_FLAG_EXECUTABLE Message-ID: <53D74DDD.6070006@gmail.com> While looking for places to add my new CMAKE_${lang}_LINKER_SUPPORTS_PDB I found the following in Windows-df.cmake: set(CMAKE_${lang}_COMPILER_LINKER_OPTION_FLAG_EXECUTABLE "/link") It looks suspicious because I don't think "lang" is actually set in that context. The only mention of "LINKER_OPTION_FLAG" seems to be Source/cmNinjaNormalTargetGenerator.cxx Nils From mantis at public.kitware.com Tue Jul 29 07:42:59 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Tue, 29 Jul 2014 07:42:59 -0400 Subject: [cmake-developers] [CMake 0015045]: FindCUDA.cmake passes directory COMPILE_DEFINITIONS to nvcc without handling generator expressions Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15045 ====================================================================== Reported By: Nils Gladitz Assigned To: James Bigler ====================================================================== Project: CMake Issue ID: 15045 Category: Modules Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 2014-07-29 07:42 EDT Last Modified: 2014-07-29 07:42 EDT ====================================================================== Summary: FindCUDA.cmake passes directory COMPILE_DEFINITIONS to nvcc without handling generator expressions Description: A colleague noticed this while using UseQt4.cmake which since 3.0 contains: set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$>:QT_NO_DEBUG>) To recreate the old behaviour generator expressions could be stripped with the new string(GENEX_STRIP) or perhaps even expanded with file(GENERATE). Steps to Reproduce: cmake_minimum_required(VERSION 3.0) set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $<$>:NOT_FOO> ) find_package(CUDA REQUIRED) cuda_add_library(empty empty.cu) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-29 07:42 Nils Gladitz New Issue 2014-07-29 07:42 Nils Gladitz Status new => assigned 2014-07-29 07:42 Nils Gladitz Assigned To => James Bigler ====================================================================== From brad.king at kitware.com Tue Jul 29 09:54:59 2014 From: brad.king at kitware.com (Brad King) Date: Tue, 29 Jul 2014 09:54:59 -0400 Subject: [cmake-developers] CMAKE_${lang}_COMPILER_LINKER_OPTION_FLAG_EXECUTABLE In-Reply-To: <53D74DDD.6070006@gmail.com> References: <53D74DDD.6070006@gmail.com> Message-ID: <53D7A7B3.3000505@kitware.com> On 07/29/2014 03:31 AM, Nils Gladitz wrote: > While looking for places to add my new CMAKE_${lang}_LINKER_SUPPORTS_PDB > I found the following in Windows-df.cmake: > > set(CMAKE_${lang}_COMPILER_LINKER_OPTION_FLAG_EXECUTABLE "/link") > > It looks suspicious because I don't think "lang" is actually set in that > context. > > The only mention of "LINKER_OPTION_FLAG" seems to be > Source/cmNinjaNormalTargetGenerator.cxx Running "git log -p -S_COMPILER_LINKER_OPTION_FLAG_" one can see how that was added to help with Ninja+MSVC and then refactored away later. Please drop both locations. Thanks, -Brad From konstantin at podsvirov.pro Tue Jul 29 13:47:14 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 29 Jul 2014 21:47:14 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <53D66577.2050506@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> Message-ID: <599601406656034@web5j.yandex.ru> Hello Developers! The topic 'cpack-ifw-generator' now in the branch 'master'. 28.07.2014, 18:58, "Brad King" : > After squashing in one fixup for building with CMake < 2.8.9 > this feature is now in master... This is good news for me and I hope for others. I hope the IFW generator have been users and fans. I have some news and changes. The source code is now available here: http://git.podsvirov.pro/?p=kitware/cmake.git Changes on the subject CPack IFW generator now in the branch 'cpack-ifw-generator'. You can clone code for the study: git clone -b cpack-ifw-generator git://podsvirov.pro/kitware/cmake.git Wish to check the generator in action you can use online-installer for your platform: Linux 32bit: http://ifw.podsvirov.pro/cmake/cmake-ifw-linux-32bit-online.run Linux 64bit: http://ifw.podsvirov.pro/cmake/cmake-ifw-linux-64bit-online.run Windows 32bit: http://ifw.podsvirov.pro/cmake/cmake-ifw-windows-32bit-online.exe Windows 64bit: http://ifw.podsvirov.pro/cmake/cmake-ifw-windows-64bit-online.exe (Unfortunately I don't have a device's Mac OS, and I can't test the code here) Presents online installers install CMake with the latest developments on the topic 'cpack-ifw-generator'. Note that the installer created using CPack IFW gererator and demonstrate his work. Updates go out about once a week. Last update on 28 July: - added some configuration variables for package installation information about the owner and tasks of the logo and icons for the installer. As before the HTML version of the documentation is available here: http://ifw.podsvirov.pro/cmake/doc/cmake-3.0/html Urge to try CPack IFW generator and write your feedback and suggestion to the mailing list or to me personally. Once again, thank Brad for his help in promoting the topic 'cpack-ifw-generator'. (Sorry for my English, I use a translator) Regards, Konstantin Podsvirov From nick at astrant.net Wed Jul 30 05:31:14 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 30 Jul 2014 11:31:14 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: <53D65BF0.8090106@kitware.com> References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> <53D65BF0.8090106@kitware.com> Message-ID: Here's the sample code: https://github.com/NickNick/cmake-interface-includes/commits/master . The second commit breaks the build. I sort of understand why it does, but that means I can't use the "INTERFACE"-trick, so to say, even with static libraries. Thanks for linking the other bug. On Mon, Jul 28, 2014 at 4:19 PM, Brad King wrote: > On 07/24/2014 05:47 PM, Nick Overdijk wrote: > > I'm using target_include_directories of A to get some include > > directories into B well, so I can't use > > target_link_libraries(A INTERFACE B), > > Can you clarify this with sample code please? > > > and I can't seem to use the OBJECT-way neither since B's sources > > won't compile without A's INTERFACE_INCLUDE_DIRECTORIES... > > Usage requirements were designed with target_link_libraries as > the main way to propagate them, but OBJECT libraries do not allow > use with target_link_libraries. This is an open problem with the > design of the two features. See also discussion here: > > http://www.cmake.org/Bug/view.php?id=14970 > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 30 09:16:48 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 09:16:48 -0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <599601406656034@web5j.yandex.ru> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> Message-ID: <53D8F040.1000505@kitware.com> On 07/29/2014 01:47 PM, Konstantin Podsvirov wrote: > I have some news and changes. > > The source code is now available here: > http://git.podsvirov.pro/?p=kitware/cmake.git New changes applied here: CPackIFW: Document cpack_ifw_configure_component DEPENDS option http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2340001 CPackIFW: Add package configuration variables http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7511b7f Thanks, -Brad From brad.king at kitware.com Wed Jul 30 09:32:46 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 09:32:46 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D6673D.9080109@gmail.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> <53D65A1B.3000202@kitware.com> <53D6673D.9080109@gmail.com> Message-ID: <53D8F3FE.2020005@kitware.com> On 07/28/2014 11:07 AM, Daniele E. Domenichelli wrote: > I applied the changes you requested to the documentation, rebased, and > merged to next for testing. Thanks. While reviewing the commits in 'next' again I realized that assuming paths are relative to CMAKE_BINARY_DIR may not be correct. Some projects may be nested inside others, and the CMAKE_BINARY_DIR may not be the proper location for a nested project. Instead the BUILD_TREE option should be followed by another argument specifying the base for relative paths, i.e. the in-build-tree prefix. -Brad From mantis at public.kitware.com Wed Jul 30 09:42:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 30 Jul 2014 09:42:22 -0400 Subject: [cmake-developers] [CMake 0015046]: visual studio configuration sometimes switches from x64 to win32 Message-ID: <77733e37feb1474c202e807afee3e32f@www.cmake.org> The following issue has been SUBMITTED. ====================================================================== http://www.cmake.org/Bug/view.php?id=15046 ====================================================================== Reported By: tim blechmann Assigned To: ====================================================================== Project: CMake Issue ID: 15046 Category: CMake Reproducibility: sometimes Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-30 09:42 EDT Last Modified: 2014-07-30 09:42 EDT ====================================================================== Summary: visual studio configuration sometimes switches from x64 to win32 Description: i'm configuring my windows/64bit builds using the "Visual Studio 12 2013 Win64" generator. however sometimes when running cmake on this existing build folder, the configuration switches from x64 to win32 (likewise the generator is switched to "Visual Studio 12 2013"). while i have seen this a couple of time on different machines, i haven't been able to find a reproducer. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-30 09:42 tim blechmann New Issue ====================================================================== From brad.king at kitware.com Wed Jul 30 09:58:05 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 09:58:05 -0400 Subject: [cmake-developers] LZMA support In-Reply-To: <53CFCA08.1090605@kitware.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> Message-ID: <53D8F9ED.40900@kitware.com> On 07/23/2014 10:43 AM, Brad King wrote: > I've merged the topic to 'next' for testing, but without the CPack > or ExternalProject pieces. Likely some more portability fixes > will be required after testing on the dashboard. Once that is clean > I will add the other changes again on top of the revised topic. This is all now in master as of commit 6370c90f. I've updated issues 13072, 13515, 14504, and 14519 accordingly. Thanks! -Brad From konstantin at podsvirov.pro Wed Jul 30 10:30:17 2014 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 30 Jul 2014 18:30:17 +0400 Subject: [cmake-developers] CPack IFW generator In-Reply-To: <53D8F040.1000505@kitware.com> References: <2019241404927050@web7g.yandex.ru> <53C449BB.3070506@gmail.com> <2681081405582381@web7g.yandex.ru> <53D01E99.3090905@kitware.com> <53D66577.2050506@kitware.com> <599601406656034@web5j.yandex.ru> <53D8F040.1000505@kitware.com> Message-ID: <20851406730617@web26j.yandex.ru> Hi guys! 30.07.2014, 17:15, "Brad King" : > New changes applied here: > > CPackIFW: Document cpack_ifw_configure_component DEPENDS option > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2340001 > > CPackIFW: Add package configuration variables > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7511b7f Thank You Brad! The code is now in the branch 'next' so soon it will get to 'master' :-) Regards, Konstantin Podsvirov From brad.king at kitware.com Wed Jul 30 10:51:53 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 10:51:53 -0400 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> <53D65BF0.8090106@kitware.com> Message-ID: <53D90689.8000706@kitware.com> On 07/30/2014 05:31 AM, Nick Overdijk wrote: > https://github.com/NickNick/cmake-interface-includes/commits/master Thanks. For reference, the summary is: cmake_minimum_required(VERSION 2.8.12) project(FOO CXX) add_library(foo foo/foo.cpp) target_include_directories(foo INTERFACE foo) add_library(bar bar/bar.cpp) target_link_libraries(bar foo) # reduces parallel compilation #target_link_libraries(bar INTERFACE foo) # compiles bar without foo reqs With CMake 3.0 you might be able to hack something up with INTERFACE libraries, but that will increase complexity. The INTERFACE workaround commented out in the above example is really only good when no usage requirements need to be propagated. Otherwise, I think you're stuck with the reduced parallelism until CMake can be taught to detect when it is safe to drop such dependencies as I explained earlier. FWIW, I've been building large projects this way for years and rarely been bothered by this. Usually each library has so many sources that parallelism within each target is enough. -Brad From nick at astrant.net Wed Jul 30 11:09:05 2014 From: nick at astrant.net (Nick Overdijk) Date: Wed, 30 Jul 2014 17:09:05 +0200 Subject: [cmake-developers] CMake generates Makefiles that don't parallelize as much as they could. In-Reply-To: <53D90689.8000706@kitware.com> References: <53CFAC65.5000000@kitware.com> <53CFB52C.3090500@kitware.com> <53D65BF0.8090106@kitware.com> <53D90689.8000706@kitware.com> Message-ID: True, I was just bothered by it when we got distcc running with a good amount of cores. Thanks for your effort. :) I'll try and make something with the things I've learned (I'm thinking of making some functions that propagate usage requirements yet link with INTERFACE or something along those lines, of course only usable for static libs). On Wed, Jul 30, 2014 at 4:51 PM, Brad King wrote: > On 07/30/2014 05:31 AM, Nick Overdijk wrote: > > https://github.com/NickNick/cmake-interface-includes/commits/master > > Thanks. For reference, the summary is: > > cmake_minimum_required(VERSION 2.8.12) > project(FOO CXX) > add_library(foo foo/foo.cpp) > target_include_directories(foo INTERFACE foo) > add_library(bar bar/bar.cpp) > target_link_libraries(bar foo) # reduces parallel compilation > #target_link_libraries(bar INTERFACE foo) # compiles bar without foo reqs > > With CMake 3.0 you might be able to hack something up with INTERFACE > libraries, but that will increase complexity. > > The INTERFACE workaround commented out in the above example is really > only good when no usage requirements need to be propagated. Otherwise, > I think you're stuck with the reduced parallelism until CMake can be > taught to detect when it is safe to drop such dependencies as I > explained earlier. FWIW, I've been building large projects this way > for years and rarely been bothered by this. Usually each library has > so many sources that parallelism within each target is enough. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman-k-williams at uiowa.edu Wed Jul 30 11:06:13 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Wed, 30 Jul 2014 15:06:13 +0000 Subject: [cmake-developers] adding command line flags for CMAKE_MAKE_PROGRAM Message-ID: I was trying to get ExternalProjects generated with the Ninja generator to do a better job of handling multiple CPUs and load, so I tried the na?ve solution below. I needed to add flags to the program named in CMAKE_MAKE_PROGRAM. This is difficult because CMAKE_MAKE_PROGRAM is a string; I can pass it as part of an ExternalProjects? CMAKE_ARGS, but then the resulting build tries to run ?/usr/bin/ninja ?j 32? as the command, instead of adding ?j 32 to ninja?s command line. Any ideas, or am I asking for a CMAKE_MAKE_PROGRAM_FLAGS command? Or to modify the generator? the only alternative is to explicitly set the BUILD_COMMAND for every ExternalProject_add command. #------------------------------ # For ninja generator, propagate ninja flags #------------------------------ if(CMAKE_GENERATOR MATCHES ".*Ninja.*") if(NOT DEFINED PROCESSOR_COUNT) # Unknown: set(PROCESSOR_COUNT 1) # Linux: if(CMAKE_SYSTEM_NAME MATCHES ".*Linux.*") set(cpuinfo_file "/proc/cpuinfo") if(EXISTS "${cpuinfo_file}") file(STRINGS "${cpuinfo_file}" procs REGEX "^processor.: [0-9]+$") list(LENGTH procs PROCESSOR_COUNT) endif() # Mac: elseif(APPLE) find_program(cmd_sys_pro "system_profiler") if(cmd_sys_pro) execute_process(COMMAND ${cmd_sys_pro} OUTPUT_VARIABLE info) string(REGEX REPLACE "^.*Total Number Of Cores: ([0-9]+).*$" "\\1" PROCESSOR_COUNT "${info}") endif() # Windows: elseif(WIN32) set(PROCESSOR_COUNT "$ENV{NUMBER_OF_PROCESSORS}") endif() endif() set(CMAKE_MAKE_PROGRAM ${CMAKE_MAKE_PROGRAM} -l ${PROCESSOR_COUNT}) endif() ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 30 11:35:47 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 11:35:47 -0400 Subject: [cmake-developers] ExternalProject: adding command line flags for CMAKE_MAKE_PROGRAM In-Reply-To: References: Message-ID: <53D910D3.1030209@kitware.com> On 07/30/2014 11:06 AM, Williams, Norman K wrote: > I was trying to get ExternalProjects generated with the Ninja > generator to do a better job of handling multiple CPUs and load, > so I tried the na?ve solution below. For reference in the archives, your previous post about this was here: CMake, Ninja generator, and ExternalProjects http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10543 > I needed to add flags to the program named in CMAKE_MAKE_PROGRAM. The relevant part of the ExternalProject module source is the block that constructs the default BUILD_COMMAND when not using a Makefile generator: # Drive the project with "cmake --build". get_target_property(cmake_command ${name} _EP_CMAKE_COMMAND) if(cmake_command) set(cmd "${cmake_command}") else() set(cmd "${CMAKE_COMMAND}") endif() set(args --build ${binary_dir} --config ${CMAKE_CFG_INTDIR}) At build time, "cmake --build" loads the CMAKE_MAKE_PROGRAM from the CMakeCache.txt of the build tree, at least for the Ninja generator. When running "cmake --build" by hand one can specify additional args: cmake --build . -- $ExtraArgs Everything after the "--" option will be given to the native tool. Perhaps one could add a special-case here when cmake_generator is "Ninja" to extend the "cmake --build" command with th needed options to ninja. > the only alternative is to explicitly set the BUILD_COMMAND for > every ExternalProject_add command. That would also work with existing CMake releases, but would have to be conditional on the generator in use. -Brad From daniele.domenichelli at gmail.com Wed Jul 30 11:57:59 2014 From: daniele.domenichelli at gmail.com (Daniele E. Domenichelli) Date: Wed, 30 Jul 2014 17:57:59 +0200 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D8F3FE.2020005@kitware.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> <53D65A1B.3000202@kitware.com> <53D6673D.9080109@gmail.com> <53D8F3FE.2020005@kitware.com> Message-ID: <53D91607.6090300@gmail.com> Hello Brad, On 30/07/14 15:32, Brad King wrote: > Thanks. While reviewing the commits in 'next' again I realized > that assuming paths are relative to CMAKE_BINARY_DIR may not be > correct. Some projects may be nested inside others, and the > CMAKE_BINARY_DIR may not be the proper location for a nested > project. Instead the BUILD_TREE option should be followed by > another argument specifying the base for relative paths, i.e. > the in-build-tree prefix. Ok, looks reasonable but I have a few questions... I never used multiple project calls, so I don't know how it works, would PROJECT_BINARY_DIR be an appropriate replacement for CMAKE_BINARY_DIR? configure_package_config_file has an INSTALL_DESTINATION argument, I was assuming that one would pass that if the destination isn't of the config file isn't CMAKE_BINARY_DIR. In this way if INSTALL_DESTINATION is a relative path, it will consider it relative to CMAKE_BINARY_DIR, like other places in CMake. How would you like me to handle this argument? Should INSTALL_DESTINATION always be relative to CMAKE_BINARY_DIR or should it be relative to BUILD_TREE? Maybe BUILD_TREE is no longer an appropriate name if you can set it to any folder, maybe RELATIVE_DIR or something similar would be more appropriate? Cheers, Daniele From brad.king at kitware.com Wed Jul 30 13:23:18 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 13:23:18 -0400 Subject: [cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree In-Reply-To: <53D91607.6090300@gmail.com> References: <53C6A065.7010201@gmail.com> <53CD2DF9.70601@gmail.com> <53CE20A3.7090502@gmail.com> <53CE418C.9090507@gmail.com> <53D00155.5000002@kitware.com> <53D2630A.1030106@gmail.com> <53D65A1B.3000202@kitware.com> <53D6673D.9080109@gmail.com> <53D8F3FE.2020005@kitware.com> <53D91607.6090300@gmail.com> Message-ID: <53D92A06.80102@kitware.com> On 07/30/2014 11:57 AM, Daniele E. Domenichelli wrote: > I never used multiple project calls, so I don't know how it works, would > PROJECT_BINARY_DIR be an appropriate replacement for CMAKE_BINARY_DIR? No, because we don't know if the most-nested project() call is the right one either. > Should INSTALL_DESTINATION always be relative to CMAKE_BINARY_DIR or > should it be relative to BUILD_TREE? The purpose of INSTALL_DESTINATION is to help the generated file compute the installation prefix relative to itself. Therefore it needs to be treated relative to the same place all other paths will be treated relative to. This is BUILD_TREE when the option is specified. > Maybe BUILD_TREE is no longer an appropriate name if you can set it to > any folder, maybe RELATIVE_DIR or something similar would be more > appropriate? The purpose of the BUILD_TREE option is now to specify a different value to be used anywhere ${CMAKE_INSTALL_PREFIX} is now. I think the name "INSTALL_PREFIX" may be best. This approach generalizes the feature even to the case of preparing a package config file for a prefix besides the current value of CMAKE_INSTALL_PREFIX even when it really will be installed. Basically in the implementation you can replace any occurence of ${CMAKE_INSTALL_PREFIX} with a ${installPrefix} local that is set to either CMAKE_INSTALL_PREFIX or the value of the INSTALL_PREFIX option. -Brad From mantis at public.kitware.com Wed Jul 30 13:30:38 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 30 Jul 2014 13:30:38 -0400 Subject: [cmake-developers] [CMake 0015047]: BundleUtilities' fixup_bundle does not check to see if two libs are the same up to symlinks Message-ID: <7cc31c44d67811d6f81e6ca476284a00@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15047 ====================================================================== Reported By: Jordi Guti?rrez Hermoso Assigned To: ====================================================================== Project: CMake Issue ID: 15047 Category: Modules Reproducibility: have not tried Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-30 13:30 EDT Last Modified: 2014-07-30 13:30 EDT ====================================================================== Summary: BundleUtilities' fixup_bundle does not check to see if two libs are the same up to symlinks Description: I'm using cmake's BundleUtilities to create an app bundle. I am using homebrew's wxmac package to create an application of my own. With wxmac, my binary links (amongst other things) to /usr/local/lib/libwx_baseu-3.0.dylib /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib But /usr/local/lib/libwx_osx_cocoau_core-3.0.dylib itself also links to libwx_baseu-3.0.dylib, but not to the symlink in /usr/local/lib but to the original in /usr/local/Cellar which actually has a longer but compatible version name: libwx_baseu-3.0.0.1.0.dylib (note the extra dots in the version number). Of course, the 3.0.0.1.0 library is the same as the 3.0 library, as the latter is jus a symlink to the former. Thus BundleUtilities thinks that there is a dependency of a dependency and copies the libwx_baseu library twice, once for 3.0 and again for 3.0.0.1.0 and sets the path twice in my binary. This creates a segfaulty executable. :-( Steps to Reproduce: It's a bit complicated to easily reproduce this. Basically, use fixup_bundle, create a library that links both to foo.dylib and bar.dylib, and make sure that bar.dylib is a symlink to baz.dylib and that foo.dylib itself links to baz. In ASCII art: binary | \ | \ foo bar ..... baz | | \_________________/ where the dots indicate a filesystem symlink and the solid lines indicate dynamic library linking. Additional Information: (aside: homebrew sets up symlinks in /usr/local/lib that point to the actual wxmac libraries in /usr/local/Cellar/wxmac/3.0.1, similar to how most GNU/Linux systems handle /usr/lib and /usr/local/lib ) ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-30 13:30 Jordi Guti?rrez HermosoNew Issue ====================================================================== From mantis at public.kitware.com Wed Jul 30 15:05:21 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 30 Jul 2014 21:05:21 +0200 Subject: [cmake-developers] [CMake 0015048]: Semicolon in AIX compiler warning FAIL_REFEX causes it to match other output Message-ID: <82b3f25d7a114c133952dfb74135eec2@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15048 ====================================================================== Reported By: Erik Lindahl Assigned To: ====================================================================== Project: CMake Issue ID: 15048 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-30 21:05 CEST Last Modified: 2014-07-30 21:05 CEST ====================================================================== Summary: Semicolon in AIX compiler warning FAIL_REFEX causes it to match other output Description: In CMakeCheckCompilerFlagCommonPatterns.cmake of CMake-3.0, the FAIL_REGEX string for AIX contains a semicolon. This appears to cause the string to be split in two entries (since CMake uses semicolon as a separator for lists). Since the part after the semicolon is merely the word "ignored", any compiler producing that word in the output will have a failure triggered. Steps to Reproduce: We found this when using the Intel 12.1.0 compiler on Windows HPC 2008 since that emits the linker warning "LINK : warning LNK4224: /INCREMENTAL:YES is no longer supported; ignored", which caused the above test to trigger for the "ignored" word. Additional Information: Suggest to replace semicolon with a period to match any character in the regular expression. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-30 21:05 Erik Lindahl New Issue ====================================================================== From daniel at pfeifer-mail.de Wed Jul 30 15:42:56 2014 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 30 Jul 2014 21:42:56 +0200 Subject: [cmake-developers] LZMA support In-Reply-To: <53D8F9ED.40900@kitware.com> References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> <53D8F9ED.40900@kitware.com> Message-ID: 2014-07-30 15:58 GMT+02:00 Brad King : > On 07/23/2014 10:43 AM, Brad King wrote: > > I've merged the topic to 'next' for testing, but without the CPack > > or ExternalProject pieces. Likely some more portability fixes > > will be required after testing on the dashboard. Once that is clean > > I will add the other changes again on top of the revised topic. > > This is all now in master as of commit 6370c90f. I've updated > issues 13072, 13515, 14504, and 14519 accordingly. > Great! I think we should add packaging options like 'CPACK_BINARY_7Z' to 'Modules/CPack.cmake'. Maybe the options should be reordered alphabetically, to make it obvious where to add new package generators. By the way: CPACK_BINARY_IFW should be added to the 'mark_as_advanced' list too. cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CPack.patch Type: text/x-patch Size: 3610 bytes Desc: not available URL: From brad.king at kitware.com Wed Jul 30 16:01:22 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 30 Jul 2014 16:01:22 -0400 Subject: [cmake-developers] LZMA support In-Reply-To: References: <8D1748718A8DA2B-197C-1CCB8@webmail-d168.sysops.aol.com> <53CFCA08.1090605@kitware.com> <53D8F9ED.40900@kitware.com> Message-ID: <53D94F12.1030304@kitware.com> On 07/30/2014 03:42 PM, Daniel Pfeifer wrote: > I think we should add packaging options like 'CPACK_BINARY_7Z' to 'Modules/CPack.cmake'. Thanks. Patch applied: CPack: Add lzma-compressed package options http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d93e099 > Maybe the options should be reordered alphabetically, to make it obvious where to add new package generators. Yes, this can be done as a follow-up to the other changes. > By the way: CPACK_BINARY_IFW should be added to the 'mark_as_advanced' list too. Yes, thanks. CPack: Mark CPACK_BINARY_IFW option as advanced http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cabc2cd -Brad From mantis at public.kitware.com Wed Jul 30 16:53:34 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Wed, 30 Jul 2014 22:53:34 +0200 Subject: [cmake-developers] [CMake 0015049]: Add detection for Fujitsu compilers Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15049 ====================================================================== Reported By: Erik Lindahl Assigned To: ====================================================================== Project: CMake Issue ID: 15049 Category: CMake Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-30 22:53 CEST Last Modified: 2014-07-30 22:53 CEST ====================================================================== Summary: Add detection for Fujitsu compilers Description: Fujitsu users their own compilers (based on an old version of Clang) on K. By default the CMake compiler IDs are set to Unknown, but when using the GNU compatibility flags the Fujitsu compiler adds the _GNUC_ define (bad), although it is not really 100% compatible with GCC-4.1.2. To work around this we manually set the compiler IDs to "Fujitsu", but it is probably a good idea to have this in the default distribution too, which the two attached patches accomplish (tested). Unfortunately the version cannot be extracted from the source level. If you want that, it can be detected from the output with the -V flag. Examples: klogin9$ fccpx -V fccpx: Fujitsu C/C++ Compiler Driver Version 1.2.0 P-id: L30000-07 (Jul 30 2013 08:58:18) K-1.2.0-15 klogin9$ FCCpx -V FCCpx: Fujitsu C/C++ Compiler Driver Version 1.2.0 P-id: L30000-07 (Jul 30 2013 08:58:18) K-1.2.0-15 klogin9$ frtpx -V frtpx: Fujitsu Fortran Driver Version 1.2.0 P-id: L30000-07 (Jul 30 2013 08:57:22) K-1.2.0-15 ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-30 22:53 Erik Lindahl New Issue 2014-07-30 22:53 Erik Lindahl File Added: Fujitsu.patch ====================================================================== From bill.hoffman at kitware.com Wed Jul 30 18:10:36 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 30 Jul 2014 18:10:36 -0400 Subject: [cmake-developers] scan-build of CMake Message-ID: <53D96D5C.3080506@kitware.com> I am working on scan-build integration with ctest/CDash and did a build of CMake. The results show up in the warning section of the build: http://open.cdash.org/viewBuildError.php?type=1&buildid=3429991 I excluded a few things in STL, but the rest of this might be worth looking at if anyone has the time. :) -Bill From mantis at public.kitware.com Thu Jul 31 03:49:22 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 31 Jul 2014 09:49:22 +0200 Subject: [cmake-developers] [CMake 0015050]: Enable OpenMP flag detection with Fujitsu compilers Message-ID: <73bdc7dfc87c0fc0b3891daa8f3cd88a@public.kitware.com> The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15050 ====================================================================== Reported By: Erik Lindahl Assigned To: ====================================================================== Project: CMake Issue ID: 15050 Category: CMake Reproducibility: N/A Severity: feature Priority: low Status: new ====================================================================== Date Submitted: 2014-07-31 09:49 CEST Last Modified: 2014-07-31 09:49 CEST ====================================================================== Summary: Enable OpenMP flag detection with Fujitsu compilers Description: The Fujitsu compilers use the flag "-KopenMP" to enable OpenMP, which presently isn't checked by CMake. The attached patch to FindOpenMP.cmake adds it. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-31 09:49 Erik Lindahl New Issue 2014-07-31 09:49 Erik Lindahl File Added: FindOpenMP.cmake.patch ====================================================================== From mantis at public.kitware.com Thu Jul 31 05:24:11 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 31 Jul 2014 11:24:11 +0200 Subject: [cmake-developers] [CMake 0015051]: Detect more fujitsu compiler warnings Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15051 ====================================================================== Reported By: Erik Lindahl Assigned To: ====================================================================== Project: CMake Issue ID: 15051 Category: CMake Reproducibility: N/A Severity: feature Priority: low Status: new ====================================================================== Date Submitted: 2014-07-31 11:24 CEST Last Modified: 2014-07-31 11:24 CEST ====================================================================== Summary: Detect more fujitsu compiler warnings Description: The attached patch to CMakeCheckCompilerFlagCommonPatterns.cmake adds detection for incorrect suboptions with the Fujitsu compilers. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-31 11:24 Erik Lindahl New Issue 2014-07-31 11:24 Erik Lindahl File Added: CMakeCheckCompilerFlagCommonPatterns.cmake.patch ====================================================================== From nilsgladitz at gmail.com Thu Jul 31 06:55:01 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 31 Jul 2014 12:55:01 +0200 Subject: [cmake-developers] configure_file() missing output file regeneration Message-ID: <53DA2085.2010908@gmail.com> The output file regeneration introduced in ad502502 and refined by 38571f2c does not seem to work with the visual studio (tested 2010, reportedly also 2012) and Ninja generators. I merged the topic "output-tracking" which extends the RunCMake.configure_file test to find out where it actually does/does not work. I have since then found 9465242d which apparently already tried to fix this for Ninja. Nils From brad.king at kitware.com Thu Jul 31 09:12:41 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 31 Jul 2014 09:12:41 -0400 Subject: [cmake-developers] configure_file() missing output file regeneration In-Reply-To: <53DA2085.2010908@gmail.com> References: <53DA2085.2010908@gmail.com> Message-ID: <53DA40C9.7010709@kitware.com> On 07/31/2014 06:55 AM, Nils Gladitz wrote: > I merged the topic "output-tracking" which extends the > RunCMake.configure_file test to find out where it actually does/does not > work. No need for that. Just do "git grep GetOutputFiles" and you will see that no generators even query that except Makefile and Ninja. Therefore Xcode and VS generators are missing this support. -Brad From nilsgladitz at gmail.com Thu Jul 31 09:12:44 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 31 Jul 2014 15:12:44 +0200 Subject: [cmake-developers] configure_file() missing output file regeneration In-Reply-To: <53DA40C9.7010709@kitware.com> References: <53DA2085.2010908@gmail.com> <53DA40C9.7010709@kitware.com> Message-ID: <53DA40CC.1040303@gmail.com> On 07/31/2014 03:12 PM, Brad King wrote: > On 07/31/2014 06:55 AM, Nils Gladitz wrote: >> I merged the topic "output-tracking" which extends the >> RunCMake.configure_file test to find out where it actually does/does not >> work. > > No need for that. Just do "git grep GetOutputFiles" and you will > see that no generators even query that except Makefile and Ninja. > Therefore Xcode and VS generators are missing this support. Are they intentionally left out? Nils From brad.king at kitware.com Thu Jul 31 09:38:10 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 31 Jul 2014 09:38:10 -0400 Subject: [cmake-developers] configure_file() missing output file regeneration In-Reply-To: <53DA40CC.1040303@gmail.com> References: <53DA2085.2010908@gmail.com> <53DA40C9.7010709@kitware.com> <53DA40CC.1040303@gmail.com> Message-ID: <53DA46C2.1030407@kitware.com> On 07/31/2014 09:12 AM, Nils Gladitz wrote: >> No need for that. Just do "git grep GetOutputFiles" and you will >> see that no generators even query that except Makefile and Ninja. >> Therefore Xcode and VS generators are missing this support. > > Are they intentionally left out? I don't think so. However, see below. Actually I just dug in to the history of this and found that the whole feature was attempted and reverted in 2006: ENH: add support for re-running cmake if the cmakefiles change, 2006-04-10 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c06f8e2 ENH: fix re-run of cmake based on configured files that are done with copy if different and never change, 2006-04-11 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa415043 Then the fix that would have made it work was done in 2009 by considering these outputs to be by-products that are expected to exist but not necessarily be newer than the inputs: BUG: Fix OS X AppBundle/FW byproducts dependencies, 2009-02-06 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22827489 Then the original feature was finally restored in 2013: cmMakefile: Track configured files so we can regenerate them, 2013-06-18 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad502502 and later refined as you already mentioned. The problem for VS and Xcode is that these "output" files may not be newer than the inputs, so they cannot be simply listed as build outputs of the rule to re-run CMake or it will run every time. The Makefile generator solves this with the cmake_check_build_system build target that runs every time and does custom analysis: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmake.cxx;hb=v3.0.0#l1971 Such always-run targets do not look clean to IDE builds. -Brad From nilsgladitz at gmail.com Thu Jul 31 09:48:19 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 31 Jul 2014 15:48:19 +0200 Subject: [cmake-developers] configure_file() missing output file regeneration In-Reply-To: <53DA46C2.1030407@kitware.com> References: <53DA2085.2010908@gmail.com> <53DA40C9.7010709@kitware.com> <53DA40CC.1040303@gmail.com> <53DA46C2.1030407@kitware.com> Message-ID: <53DA4923.1050608@gmail.com> On 07/31/2014 03:38 PM, Brad King wrote: > The problem for VS and Xcode is that these "output" files may not > be newer than the inputs, so they cannot be simply listed as build > outputs of the rule to re-run CMake or it will run every time. > The Makefile generator solves this with the cmake_check_build_system > build target that runs every time and does custom analysis: > > http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmake.cxx;hb=v3.0.0#l1971 > > Such always-run targets do not look clean to IDE builds. Hm alright ... 2.8.12 has the following changelog entry: CMake: Removal of configured files will retrigger CMake when issuing a build command From which I took that this was implemented for all generators. But it sounds like this may not actually be possible/feasible. Thanks for clarifying. Nils From sean at rogue-research.com Thu Jul 31 12:09:33 2014 From: sean at rogue-research.com (Sean McBride) Date: Thu, 31 Jul 2014 12:09:33 -0400 Subject: [cmake-developers] scan-build of CMake In-Reply-To: <53D96D5C.3080506@kitware.com> References: <53D96D5C.3080506@kitware.com> Message-ID: <20140731160933.1222910725@mail.rogue-research.com> On Wed, 30 Jul 2014 18:10:36 -0400, Bill Hoffman said: >I am working on scan-build integration with ctest/CDash and did a build >of CMake. The results show up in the warning section of the build: > >http://open.cdash.org/viewBuildError.php?type=1&buildid=3429991 Sweet! Looking forward to turning that on some of our dashboards. For those that don't know, when Bill refers to 'scan-build' he's talking about the clang static analyzer: Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From bill.hoffman at kitware.com Thu Jul 31 12:16:33 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 31 Jul 2014 12:16:33 -0400 Subject: [cmake-developers] scan-build of CMake In-Reply-To: <20140731160933.1222910725@mail.rogue-research.com> References: <53D96D5C.3080506@kitware.com> <20140731160933.1222910725@mail.rogue-research.com> Message-ID: <53DA6BE1.6000906@kitware.com> On 7/31/2014 12:09 PM, Sean McBride wrote: > Sweet! Looking forward to turning that on some of our dashboards. > > For those that don't know, when Bill refers to 'scan-build' he's talking about the clang static analyzer: > > It is pretty easy to setup. You actually do not need to change ctest or CDash for this one. Just do a normal build, but change the compilers: set(ENV{CC} /usr/share/clang/scan-build/ccc-analyzer) set(ENV{CXX} /usr/share/clang/scan-build/c++-analyzer) Then all the warnings just show up in the build warnings. You can even exclude things like this: set(CTEST_CUSTOM_WARNING_EXCEPTION ".*stl_uninitialized.h:75:19: warning: Forming reference to null pointer.*" ".*stl_vector.h:771:9: warning: Returning null reference.*" "warning: Value stored to 'yymsg' is never read" "warning: Value stored to 'yytoken' is never read" ) I just found a bug from one of these already. :) -Bill From mantis at public.kitware.com Thu Jul 31 13:48:47 2014 From: mantis at public.kitware.com (Mantis Bug Tracker) Date: Thu, 31 Jul 2014 13:48:47 -0400 Subject: [cmake-developers] [CMake 0015052]: INTERFACE_INCLUDE_DIRECTORIES does not allow non-existent directories, but INCLUDE_DIRECTORIES does Message-ID: The following issue has been SUBMITTED. ====================================================================== http://public.kitware.com/Bug/view.php?id=15052 ====================================================================== Reported By: dpantele Assigned To: ====================================================================== Project: CMake Issue ID: 15052 Category: CMake Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2014-07-31 13:48 EDT Last Modified: 2014-07-31 13:48 EDT ====================================================================== Summary: INTERFACE_INCLUDE_DIRECTORIES does not allow non-existent directories, but INCLUDE_DIRECTORIES does Description: It is a duplicate of http://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=14495 , but I think that Stephen Kelly was not right there. When using add_library(IMPORTED) with INTERFACE_INCLUDE_DIRECTORIES CMake checks existence of the directory in the configuration-time. However, if we declare the same path in INCLUDE_DIRECTORY of the dependent target, everything work fine. This is not consistent. Steps to Reproduce: 1. Unzip cmake-include-issue.zip 2. Try to build, build will fail 3. Replace "include(inc1.txt)' on line 25 of CMakeLists.txt with "include(inc2.txt)", effectively replacing set_target_properties(sub PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${source_dir}/include" ) with target_include_directories(main PRIVATE "${source_dir}/include") 4. Now everything works as expected ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2014-07-31 13:48 dpantele New Issue 2014-07-31 13:48 dpantele File Added: cmake-include-issue.zip ======================================================================