[cmake-developers] merge session today
Brad and I reviewed all the topics on the CMake stage today, and merged the following topic branches into 'master'. These changes will be in CMake 2.8.10-rc2. As soon as we have a clean dashboard (hopefully tomorrow) for the "Nightly 2.8 Release" section, we'll make the next release candidate. test-ctest-memcheck FortranCInterface-verify-flags codeblocks-cdefs suncc-compile-fix Fix-XXX_ON_ABSOLUTE_INSTALL_DESTINATION-handling fix-some-CPackDoc-typos CPack-ArchiveGen-andDESTIR_ON AutomocFixDuplicatedFiles_13572 fix-postgres-debian fix-13578-wrong-reg-key generator-expression-bug-fixes fix-INCLUDE_DIRECTORIES-multiconfig refactor-CTestUseLaunchers Cheers, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013595]: CMAKE_COMMAND handles spaces in path poorly when used in CMAKE_CXX_LINK_EXECUTABLE
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13595
==
Reported By:Matt Coffin
Assigned To:
==
Project:CMake
Issue ID: 13595
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-10-17 14:52 EDT
Last Modified: 2012-10-17 14:52 EDT
==
Summary:CMAKE_COMMAND handles spaces in path poorly when
used in CMAKE_CXX_LINK_EXECUTABLE
Description:
When ${CMAKE_COMMAND} is used from within CMAKE_CXX_LINK_EXECUTABLE, spaces in
the pathname are not handled as escape characters, so the executable cannot be
found. This happens when using a custom toolchain most often. The problem is
easily remedied by manually editing link.txt and putting backslashes before the
spaces in the path, but this should really be something that CMake handles
itself, right? Sorry if there's poor formatting or lack of information. I can
grab more info if need be. Its my first bug post.
Steps to Reproduce:
The following toolchain file for cross-compiling for powerpc-wrs-vxworks will
reproduce the problem nicely. But I suspect any use of ${CMAKE_COMMAND} in
CMAKE_CXX_LINK_EXECUTABLE will reproduce the same problem as it is all about how
spaces are handled when the executable's path is written to link.txt.
The toolchain file can be found at https://github.com/mcoffin/cmake_vxworks.
If you wish to build a cross-compiler environment identical to mine, the patches
for GCC and relevant build scripts are at
https://github.com/rbmj/vxworks-gcc-patches.
WPILib for GCC is at https://github.com/rbmj/wpilib, but I can't imagine that
one would need all of this to reproduce the problem, I'm just simply offering my
setup just in case
Additional Information:
There is a space by default in the installation path for CMake on OSX, so this
problem will most likely effect all users that installed to the default location
under OSX. I just realized I can attach files, so I'll toss in the "culprit"
link.txt that is generated by that toolchain file. Just look at the last line to
see why the space causes a problem.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-10-17 14:52 Matt CoffinNew Issue
2012-10-17 14:52 Matt CoffinFile Added: link.txt
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013594]: ADD_SUBDIRECTORY to look for CMakeSubLists.txt in addition to CMakeLists.txt
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13594 == Reported By:tfry Assigned To: == Project:CMake Issue ID: 13594 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2012-10-17 07:40 EDT Last Modified: 2012-10-17 07:40 EDT == Summary:ADD_SUBDIRECTORY to look for CMakeSubLists.txt in addition to CMakeLists.txt Description: Wish: If ADD_SUBDIRECTORY() fails to locate a CMakeLists.txt-file in the specified directory, it should look for CMakeSubLists.txt, instead. Documentation will encourage to use the file name "CMakeLists.txt" for cmake files which are valid as a top-level build file, and "CMakeSubLists.txt" for cmake files which rely on being included from a parent directory. Rationale: One common build error that users of my project run into is that they point cmake to a subdirectory of the sources, rather than the top-level directory containing the main CMakeLists.txt. Admittedly, this type of error is "encouraged" by a somewhat unlucky directory naming scheme. However, it can easily be hit in many projects. Users running into this will hit rather unhelpful error messages, typically about undefined macros. One way around this is to guard the CMakeLists.txt in each subdirectory, e.g. by checking whether the PROJECT_NAME, or some other indicative variable has been set. However, this check would need to be added to each CMakeLists.txt, decreasing the signal-to-noise-ratio in the build files. With the change as outlined, above, I could rename those CMakeLists.txt-files, which are not meant to be used as top-level cmake files to CMakeSubLists.txt. Cmake files, which *can* be used as top-level cmake files will continue to be named CMakeLists.txt. Thus, only those cmake files which can stand for themselves will be considered by the cmake-command, while CMakeSubLists.txt-files will only be considered when included using ADD_SUBDIRECTORY(). Projects not updating the naming scheme for cmake files will not be affected by this change (but will not benefit from the new feature, either). == Issue History Date ModifiedUsername FieldChange == 2012-10-17 07:40 tfry New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] EXCLUDE_FROM_DEFAULT_BUILD testing
On 10/17/2012 3:24 AM, Petr Kmoch wrote: > I'm a bit confused. We occasionally use MSBuild for driving builds at > work, but we always feed it solution files. How do you run it so that it > doesn't read them? And how does it then cope with project dependencies etc.? I haven't fully investigated yet, but all of the dashboard builds that failed the tests were using MSBuild as the tool. Try building with CMAKE_MAKE_PROGRAM set to MSBuild.exe instead of devenv.exe and run the test. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] EXCLUDE_FROM_DEFAULT_BUILD testing
On Tue, Oct 16, 2012 at 5:26 PM, Brad King wrote: > On 10/16/2012 11:04 AM, Brad King wrote: > > I tested it locally on VS 6, 7.1, 8, 9, 10, and 11 all with > > spaces in the path. I need to investigate the failures on > > the dashboard to identify the problem. > > Since we're trying to keep the dashboard as clean as possible > right now (to more directly test any changes meant to fix any > regressions in 2.8.10-rc1) I'm reverting the change: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69e305f2 > > until after the final 2.8.10 release and when we've resolved > these failures. We can restore the topic later. > OK, I understand release candidate mode is not the time to add new features :-) > > The problem is that MSBuild may be used as the build tool > instead of devenv, especially for VS Express editions. The > MSBuild tool doesn't even read the .sln so this property does > not make sense. One option is to run the test only when the > build tool is devenv. > I'm a bit confused. We occasionally use MSBuild for driving builds at work, but we always feed it solution files. How do you run it so that it doesn't read them? And how does it then cope with project dependencies etc.? Anyway, the test only makes sense in cases where the property applies, so if MSBuild doesn't honour the build/don't build settings in the .sln, there's no point in running it with MSBuild. Petr -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
