[cmake-developers] [CMake 0014544]: Remove edit_cache target from ninja output
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=14544 == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 14544 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-11-04 05:32 EST Last Modified: 2013-11-04 05:32 EST == Summary:Remove edit_cache target from ninja output Description: Full thread is at: http://bugs.debian.org/712241 in summary: $ ninja edit_cache does not do anything. So please remove the non-working edit_cache target from ninja output. == Issue History Date ModifiedUsername FieldChange == 2013-11-04 05:32 Mathieu MalaterreNew 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] CMake 2.8.12 transitive link regression?
On 11/02/2013 07:29 AM, Brad King wrote: Policy CMP0022's NEW behavior is supposed to be that the link interface is exactly specified by INTERFACE_LINK_LIBRARIES. Therefore in this case the plain tll signature should go ahead and populate *both* INTERFACE_LINK_LIBRARIES *and* LINK_LIBRARIES. After working through the details of this over the weekend the fix and a bunch of tests are now in master. It ended up taking several commits. The main one is: CMP0022: Plain target_link_libraries must populate link interface http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef10b87c Two other important changes are: Do not export INTERFACE_LINK_LIBRARIES from non-linkable targets http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23d21b78 CMP0022: Warn about a given target at most once http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a561a03 I plan to include all this in 2.8.12.1. Please test ASAP. Thanks, -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] CMake 2.8.12 transitive link regression?
On Monday, November 04, 2013 09:48:57 AM Brad King wrote: On 11/02/2013 07:29 AM, Brad King wrote: Policy CMP0022's NEW behavior is supposed to be that the link interface is exactly specified by INTERFACE_LINK_LIBRARIES. Therefore in this case the plain tll signature should go ahead and populate *both* INTERFACE_LINK_LIBRARIES *and* LINK_LIBRARIES. After working through the details of this over the weekend the fix and a bunch of tests are now in master. It ended up taking several commits. The main one is: CMP0022: Plain target_link_libraries must populate link interface http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef10b87c Two other important changes are: Do not export INTERFACE_LINK_LIBRARIES from non-linkable targets http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23d21b78 CMP0022: Warn about a given target at most once http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a561a03 I plan to include all this in 2.8.12.1. Please test ASAP. Thanks, -Brad The problem I reported before indeed appears fixed. But I see 2 others new problems. 1) cmake_minimum_required(VERSION 2.8) add_library(foo SHARED foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES ) add_executable(exe exe.cpp) target_link_libraries(exe bar) With 2.8.12.1, I now get a new warning that I did not get with 2.8.12. I'm not sure why I'm getting that warning because the linking of exe looks correct. CMake Warning (dev) in CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run cmake --help-policy CMP0022 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Target bar has an INTERFACE_LINK_LIBRARIES property which differs from its LINK_INTERFACE_LIBRARIES properties. INTERFACE_LINK_LIBRARIES: foo LINK_INTERFACE_LIBRARIES: 2) cmake_minimum_required(VERSION 2.8.12) add_library(foo SHARED foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES ) add_executable(exe exe.cpp) target_link_libraries(exe bar) I get no warning or error, but my LINK_INTERFACE_LIBRARIES property was not respected and it linked both foo and bar into exe. This appears to be a regression from 2.8.12 to 2.8.12.1. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] CMake 2.8.12 transitive link regression?
On 11/04/2013 10:31 AM, Clinton Stimpson wrote: But I see 2 others new problems. Those are features and they work together as intended. 1) cmake_minimum_required(VERSION 2.8) add_library(foo SHARED foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES ) add_executable(exe exe.cpp) target_link_libraries(exe bar) With 2.8.12.1, I now get a new warning that I did not get with 2.8.12. I'm not sure why I'm getting that warning because the linking of exe looks correct. CMake Warning (dev) in CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run cmake --help-policy CMP0022 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Target bar has an INTERFACE_LINK_LIBRARIES property which differs from its LINK_INTERFACE_LIBRARIES properties. INTERFACE_LINK_LIBRARIES: foo LINK_INTERFACE_LIBRARIES: This is a correct warning according to the definition of CMP0022. The bug you reported in 2.8.12.0 also caused it to not warn here. Prior to my fix CMake did not track the new INTERFACE_LINK_LIBRARIES value correctly for the plain tll signature so it didn't realize that things would change and therefore did not warn. 2) cmake_minimum_required(VERSION 2.8.12) add_library(foo SHARED foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES ) add_executable(exe exe.cpp) target_link_libraries(exe bar) I get no warning or error, but my LINK_INTERFACE_LIBRARIES property was not respected and it linked both foo and bar into exe. This appears to be a regression from 2.8.12 to 2.8.12.1. This is also correct behavior. The NEW behavior of CMP0022 is to ignore LINK_INTERFACE_LIBRARIES and use the new INTERFACE_LINK_LIBRARIES which is now populated by the tll call. The warning you get when the policy is not set is telling you exactly what will change when the policy is set to NEW. Therefore it gives you a chance to fix your code before setting the policy (by bumping the min req version or explicitly). This is exactly how policies are intended to work. It was very unfortunate that 2.8.12.0 was released without giving projects any release candidates with a correct CMP0022 impl. -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] Cross compiling toolchain variables
Brad King wrote: On 10/30/2013 05:27 PM, Stephen Kelly wrote: Brad King wrote: I want to make sure that downstream uses the same GL headers and libraries as the ones used to build Qt itself. The PATHS is populated with information from qmake, and I wanted to prevent cmake finding different headers and libraries. I've just staged a patch to remove that behavior for mac though: https://codereview.qt-project.org/#change,69605 Can you point me to the source of the qmake logic that uses -isysroot plus paths not inside the SDK? I'd like to understand why qmake is generating paths that don't actually exist and depend on -isysroot to be found, or if I'm misunderstanding your explanation. Here's the relevant file as far as I know: https://qt.gitorious.org/qt/qtbase/source/stable:mkspecs/features/mac/sdk.prf The issue could be related to order of execution. Maybe my cmake-related code is executed before QMAKE_INCDIR_OPENGL is populated in that file. Ok. I thought a mac sdk was 'isolated' and self-contained as far as system APIs are concerned (which seems similar to CMAKE_SYSROOT). Where does the isolation break-down? Honestly I don't see much of a distinction. The main problem is that the two of us are not educated enough in the ways of Mac development to have this debate ;) Clinton, can you help? Do you respond to offers and promises of cookies? I suppose with the default root path mode of searching re-rooted paths and then the original paths then treating the OSX SDK path as one of the rerooting prefixes makes sense. That way any library provided by the system SDK will be found for the proper target version and otherwise the search will fall back to looking elsewhere. Right. We'll have to resolve this while combining CMAKE_SYSROOT and CMAKE_OSX_SYSROOT. Yes, I think so too. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake 2.8.12 transitive link regression?
On Monday, November 04, 2013 10:40:15 AM Brad King wrote: On 11/04/2013 10:31 AM, Clinton Stimpson wrote: But I see 2 others new problems. Those are features and they work together as intended. 1) cmake_minimum_required(VERSION 2.8) add_library(foo SHARED foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES ) add_executable(exe exe.cpp) target_link_libraries(exe bar) With 2.8.12.1, I now get a new warning that I did not get with 2.8.12. I'm not sure why I'm getting that warning because the linking of exe looks correct. CMake Warning (dev) in CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run cmake --help-policy CMP0022 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Target bar has an INTERFACE_LINK_LIBRARIES property which differs from its LINK_INTERFACE_LIBRARIES properties. INTERFACE_LINK_LIBRARIES: foo LINK_INTERFACE_LIBRARIES: This is a correct warning according to the definition of CMP0022. The bug you reported in 2.8.12.0 also caused it to not warn here. Prior to my fix CMake did not track the new INTERFACE_LINK_LIBRARIES value correctly for the plain tll signature so it didn't realize that things would change and therefore did not warn. 2) cmake_minimum_required(VERSION 2.8.12) add_library(foo SHARED foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES ) add_executable(exe exe.cpp) target_link_libraries(exe bar) I get no warning or error, but my LINK_INTERFACE_LIBRARIES property was not respected and it linked both foo and bar into exe. This appears to be a regression from 2.8.12 to 2.8.12.1. This is also correct behavior. The NEW behavior of CMP0022 is to ignore LINK_INTERFACE_LIBRARIES and use the new INTERFACE_LINK_LIBRARIES which is now populated by the tll call. The warning you get when the policy is not set is telling you exactly what will change when the policy is set to NEW. Therefore it gives you a chance to fix your code before setting the policy (by bumping the min req version or explicitly). This is exactly how policies are intended to work. It was very unfortunate that 2.8.12.0 was released without giving projects any release candidates with a correct CMP0022 impl. Ok. Yes, that threw me off when the cmp0022 behavior wasn't correct in 2.8.12.0. And I agree that it is fixed in 2.8.12.1. Thanks, Clint -- 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] CMake 2.8.12 transitive link regression?
On Monday, November 04, 2013 09:16:11 AM Clinton Stimpson wrote: On Monday, November 04, 2013 10:40:15 AM Brad King wrote: On 11/04/2013 10:31 AM, Clinton Stimpson wrote: But I see 2 others new problems. Those are features and they work together as intended. 1) cmake_minimum_required(VERSION 2.8) add_library(foo SHARED foo.cpp) add_library(bar SHARED bar.cpp) target_link_libraries(bar foo) set_target_properties(bar PROPERTIES LINK_INTERFACE_LIBRARIES ) add_executable(exe exe.cpp) target_link_libraries(exe bar) With 2.8.12.1, I now get a new warning that I did not get with 2.8.12. I'm not sure why I'm getting that warning because the linking of exe looks correct. CMake Warning (dev) in CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run cmake --help-policy CMP0022 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Target bar has an INTERFACE_LINK_LIBRARIES property which differs from its LINK_INTERFACE_LIBRARIES properties. INTERFACE_LINK_LIBRARIES: foo LINK_INTERFACE_LIBRARIES: This is a correct warning according to the definition of CMP0022. The bug you reported in 2.8.12.0 also caused it to not warn here. Prior to my fix CMake did not track the new INTERFACE_LINK_LIBRARIES value correctly for the plain tll signature so it didn't realize that things would change and therefore did not warn. And I think that is part of why I submitted bug http://cmake.org/Bug/view.php?id=14512 where I was not getting a warning when I should have. It was possible to go from CMake 2.8.10 to CMake 2.8.12 and not get any warning about behavior change. Thanks for fixing this. Clint -- 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] [CMake] Forwarding parameters to cmake through cmake-gui
My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? (This is all my opinion, and may be mine alone, and should be discussed on the developer's list to see if it is shared by most other CMake devs, or if somebody objects to it for backwards compatibility reasons. I am adding the CMake dev list on the cc line...) On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. ccmake and cmake-gui *should* behave (in *my* opinion) as follows: - on startup, load the CMakeCache.txt values (if there are any) from the previous run - then apply the -D arguments so that any -D arguments given on the command line overwrite previous cache entries (just like command line cmake does already) - then put the user in charge and wait for user input This is, apparently, NOT the way that ccmake behaves today, but I think it should be changed to be like that. Please chime in, especially if you have a differing opinion. David C. -- 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] [CMake] Forwarding parameters to cmake through cmake-gui
On 11/04/2013 03:47 PM, David Cole wrote: ccmake and cmake-gui *should* behave (in *my* opinion) as follows: - on startup, load the CMakeCache.txt values (if there are any) from the previous run - then apply the -D arguments so that any -D arguments given on the command line overwrite previous cache entries (just like command line cmake does already) - then put the user in charge and wait for user input This is, apparently, NOT the way that ccmake behaves today, but I think it should be changed to be like that. I agree, and there is not too much concern for compatibility in this case due to the use of an interactive workflow. -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] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-04 15:47, David Cole wrote: My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. There are two mostly separate issues here. As far as the bug, the ccmake behavior is (IMO, but seems generally shared) is just wrong. physhh's questions (above) don't apply to this case because there is no concept of interactively selecting the build directory in ccmake. So fixing this is, if not easy, at least easy to understand how it should behave. As far as cmake-gui, there are no backward compatibility issues because right now it just doesn't support -D at all. It does however get more complicated... - What should happen with a -D option if there is not initially a build directory selected? - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. ccmake and cmake-gui *should* behave (in *my* opinion) as follows: - on startup, load the CMakeCache.txt values (if there are any) from the previous run - then apply the -D arguments so that any -D arguments given on the command line overwrite previous cache entries (just like command line cmake does already) - then put the user in charge and wait for user input I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? -- Matthew -- 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 0014545]: cmake crash
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14545
==
Reported By:Orion Poplawski
Assigned To:
==
Project:CMake
Issue ID: 14545
Category: CMake
Reproducibility:have not tried
Severity: crash
Priority: normal
Status: new
==
Date Submitted: 2013-11-04 22:24 EST
Last Modified: 2013-11-04 22:24 EST
==
Summary:cmake crash
Description:
See https://bugzilla.redhat.com/show_bug.cgi?id=1026030 for more info, but:
/usr/bin/cmake -E cmake_automoc
/home/strous/src/stellarium-0.12.4/plugins/Exoplanets/src/CMakeFiles/Exoplanets-static_automoc.dir/
led to:
Program terminated with signal 11, Segmentation fault.
http://public.kitware.com/Bug/view.php?id=0 cmake::ExecuteCMakeCommand
(args=std::vector of length 3, capacity 4 = {...}) at
/usr/src/debug/cmake-2.8.12/Source/cmake.cxx:1740
1740const char *config = args[3].empty() ? 0 : args[3].c_str();
Thread 1 (Thread 0x7f0a8ccef840 (LWP 10873)):
http://public.kitware.com/Bug/view.php?id=0 cmake::ExecuteCMakeCommand
(args=std::vector of length 3, capacity 4 = {...}) at
/usr/src/debug/cmake-2.8.12/Source/cmake.cxx:1740
automoc = {QtMajorVersion = , Sources = , Headers = ,
IncludeProjectDirsBefore = false, Srcdir = , Builddir = , MocExecutable =
, MocCompileDefinitionsStr = , MocIncludesStr = , MocOptionsStr = ,
ProjectBinaryDir = , ProjectSourceDir = , TargetName = ,
CurrentCompileSettingsStr = , OldCompileSettingsStr = , OutMocCppFilename =
, MocIncludes = empty std::list, MocDefinitions = empty std::list, MocOptions
= std::vector of length 0, capacity 0, Verbose = false, ColorOutput = true,
RunMocFailed = false, GenerateAll = false, RelaxedMode = 124}
config = optimized out
automocSuccess = optimized out
http://public.kitware.com/Bug/view.php?id=1 0x0048d6ec in do_cmake
(ac=4, av=0x7fff0a364068) at
/usr/src/debug/cmake-2.8.12/Source/cmakemain.cxx:513
Seems like it's testing if the argument is empty, but not if the argument exists
at all first.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-11-04 22:24 Orion PoplawskiNew 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] [CMake] Forwarding parameters to cmake through cmake-gui
Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both UI. It would accept the same set of options: -C initial-cache = Pre-load a script to populate the cache. -D var:type=value = Create a cmake cache entry. -U globbing_expr = Remove matching entries from CMake cache. -G generator-name = Specify a makefile generator. -T toolset-name = Specify toolset name if supported by generator. Jc On Mon, Nov 4, 2013 at 5:29 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-04 15:47, David Cole wrote: My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. There are two mostly separate issues here. As far as the bug, the ccmake behavior is (IMO, but seems generally shared) is just wrong. physhh's questions (above) don't apply to this case because there is no concept of interactively selecting the build directory in ccmake. So fixing this is, if not easy, at least easy to understand how it should behave. As far as cmake-gui, there are no backward compatibility issues because right now it just doesn't support -D at all. It does however get more complicated... - What should happen with a -D option if there is not initially a build directory selected? - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. ccmake and cmake-gui *should* behave (in *my* opinion) as follows: - on startup, load the CMakeCache.txt values (if there are any) from the previous run - then apply the -D arguments so that any -D arguments given on the command line overwrite previous cache entries (just like command line cmake does already) - then put the user in charge and wait for user input I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? -- Matthew -- 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 -- +1 919 869 8849 -- 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] Combinatorial validation with cmake
Hi there, I have been using cmake for a while now, but just for compilation.. Now, I am trying to use ctest/cdash for doing my tools validation. I need to do a combinatorial validation running my tests multiple times and in a random order. So I found the --schedule-option to run tests in a random order.. But I don't know how to specify ctest to run a test multiple times. If it is not possible, is there someone which tool I can use? Thanks for your help. Sébastien. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Distinction between Windows Compilers
Hi, Is there an Way to choose diffrent Windows Compilers Versions for (Win64 and Win32)? For Example: If i want to do a Windows 64-Bit build build cmake should use: x86_64-w64-mingw32-g++.exe (but not Cygwin and NOT Mingw/Msys) OR Visual C/C++ Win64 Compiler If i want to do a Windows 32-Bit build it is: i686-w64-mingw32-g++.exe OR MS VC++ Win32 Compiler I figured out if i use IF(MINGW) it will not distinct between the diffreent Windows GCC branches, how can i archive this and stop if the Compiler is Cygwin/Msys? Drav -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Distinction between Windows Compilers
On 4 November 2013 14:45, dravion.sm...@gmx.net dravion.sm...@gmx.net wrote: Hi, Is there an Way to choose diffrent Windows Compilers Versions for (Win64 and Win32)? http://cmake.org/cmake/help/v2.8.12/cmake.html#section_Generators It is possible to append a space followed by the platform name to create project files for a specific target platform. E.g. Visual Studio 10 Win64 will create project files for the x64 processor; Visual Studio 10 IA64 for Itanium. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Distinction between Windows Compilers
Am 04.11.2013 16:09, schrieb Mateusz Loskot: On 4 November 2013 14:45, dravion.sm...@gmx.net dravion.sm...@gmx.net wrote: Hi, Is there an Way to choose diffrent Windows Compilers Versions for (Win64 and Win32)? http://cmake.org/cmake/help/v2.8.12/cmake.html#section_Generators It is possible to append a space followed by the platform name to create project files for a specific target platform. E.g. Visual Studio 10 Win64 will create project files for the x64 processor; Visual Studio 10 IA64 for Itanium. Best regards, Sorry but this doesnt help. The Question is how to distinct between MinGW or Cygwin and Mingw-m64 (wich is 32 and 64-Bit on Windows).Distinct between VC++ 32 or 64 Bit is easy as cake. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Distinction between Windows Compilers
On 4 November 2013 15:16, dravion.sm...@gmx.net dravion.sm...@gmx.net wrote: Am 04.11.2013 16:09, schrieb Mateusz Loskot: On 4 November 2013 14:45, dravion.sm...@gmx.net dravion.sm...@gmx.net wrote: Hi, Is there an Way to choose diffrent Windows Compilers Versions for (Win64 and Win32)? http://cmake.org/cmake/help/v2.8.12/cmake.html#section_Generators It is possible to append a space followed by the platform name to create project files for a specific target platform. E.g. Visual Studio 10 Win64 will create project files for the x64 processor; Visual Studio 10 IA64 for Itanium. Best regards, Sorry but this doesnt help. The Question is how to distinct between MinGW or Cygwin and Mingw-m64 (wich is 32 and 64-Bit on Windows).Distinct between VC++ 32 or 64 Bit is easy as cake. I don't care about MinGW/Cygwin myself, but AFAIR, there is no detection mechanism for those, only -m64 flag juggling. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Distinction between Windows Compilers
On 11/4/2013 10:21 AM, Mateusz Loskot wrote: I don't care about MinGW/Cygwin myself, but AFAIR, there is no detection mechanism for those, only -m64 flag juggling. You could look at the compiler id and related variables: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_LANG_COMPILER_ID -Bill -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Distinction between Windows Compilers
On 4 November 2013 15:38, Bill Hoffman bill.hoff...@kitware.com wrote: On 11/4/2013 10:21 AM, Mateusz Loskot wrote: I don't care about MinGW/Cygwin myself, but AFAIR, there is no detection mechanism for those, only -m64 flag juggling. You could look at the compiler id and related variables: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_LANG_COMPILER_ID Right, but that's not at the generator level which is, AFAIU, what OP is looking for. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-02 07:58, David Cole wrote: physhh wrote: The question is: What is the expected behavior? ccmake and cmake-gui are interactive programs meant to prompt the user to fill in the cache values properly before typing 'c' or clicking 'Configure'. -D is a convenient way to give cache values an initial value that is different from their natural 'default' values. Using -D with ccmake and cmake-gui makes total sense, but it should only be used by the program to set the initial value that users see in the UI. After that point, the user should be in charge, and if he sets something different in the UI, the user value should win. I think Matthew's bug report is correct: the UI value should be used and then stored in the cache for subsequent runs. The -D values to ccmake and cmake-gui should only be used for initializing UI entries. Therefore, they should *NOT* be passed to the internal CMake instance used for configuring. My thoughts exactly. Thanks, David. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proper way to export a library
On 2013-11-02 13:38, Cyrille Faucheux wrote:
[...] from what I understood from Matthew first answer (implicit compile
flags [...] for imported tagets), I was under the impression that I could
get MYPROJECT_STATIC automatically defined when linking another program
against a static version of my library (through its imported target).
Yes and no. *You* have to set the flag as part of your library's
interface compile definitions. But once you do that, cmake should export
that, and anyone linking to your library (via imported target) should
automatically pick up the flag.
I've looked the documentation of target_compile_definitions, but it seems
to be about compiling the library, not linking against its imported target.
Am I right?
No; at least not entirely in the case of 't_c_d({PUBLIC|INTERFACE})'. A
PUBLIC definition is used both to compile your library and by anyone
linking to it. An INTERFACE definition is used *only* by other targets
linking to it.
See also the INTERFACE_COMPILE_DEFINITIONS property and note in the
t_c_d documentation how t_c_d affects that property.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forwarding parameters to cmake through cmake-gui
My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On Mon, Nov 4, 2013 at 4:57 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-02 07:58, David Cole wrote: physhh wrote: The question is: What is the expected behavior? ccmake and cmake-gui are interactive programs meant to prompt the user to fill in the cache values properly before typing 'c' or clicking 'Configure'. -D is a convenient way to give cache values an initial value that is different from their natural 'default' values. Using -D with ccmake and cmake-gui makes total sense, but it should only be used by the program to set the initial value that users see in the UI. After that point, the user should be in charge, and if he sets something different in the UI, the user value should win. I think Matthew's bug report is correct: the UI value should be used and then stored in the cache for subsequent runs. The -D values to ccmake and cmake-gui should only be used for initializing UI entries. Therefore, they should *NOT* be passed to the internal CMake instance used for configuring. My thoughts exactly. Thanks, David. -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Distinction between Windows Compilers
Am 04.11.2013 16:44, schrieb Mateusz Loskot: You could look at the compiler id and related variables: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_LANG_COMPILER_ID Right, but that's not at the generator level which is, AFAIU, what OP is looking for. Best regards, Yeah. MinGW, Cygwin and Mingw-m64 are basicly GNU Compiler Toolchains on Windows but only the Mingw-m64 Project is a fully featured Win64-Native Standalone Compiler and can be compared to VC++ Intel ICC when it comes to native targetting Win64. If i run x86_64-w64-mingw32-g++.exe --version it returns the String (rubenvb-4.8.0) 4.8.0 Is there an way to evaluate this string to do a manual fingerprinting.Its ok if the Generator is MinGW make files but inside the make process the switching to the diffrent GNU Windows Target Compilers would be usefull. Drav -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forwarding parameters to cmake through cmake-gui
My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? (This is all my opinion, and may be mine alone, and should be discussed on the developer's list to see if it is shared by most other CMake devs, or if somebody objects to it for backwards compatibility reasons. I am adding the CMake dev list on the cc line...) On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. ccmake and cmake-gui *should* behave (in *my* opinion) as follows: - on startup, load the CMakeCache.txt values (if there are any) from the previous run - then apply the -D arguments so that any -D arguments given on the command line overwrite previous cache entries (just like command line cmake does already) - then put the user in charge and wait for user input This is, apparently, NOT the way that ccmake behaves today, but I think it should be changed to be like that. Please chime in, especially if you have a differing opinion. David C. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
On 11/04/2013 03:47 PM, David Cole wrote: ccmake and cmake-gui *should* behave (in *my* opinion) as follows: - on startup, load the CMakeCache.txt values (if there are any) from the previous run - then apply the -D arguments so that any -D arguments given on the command line overwrite previous cache entries (just like command line cmake does already) - then put the user in charge and wait for user input This is, apparently, NOT the way that ccmake behaves today, but I think it should be changed to be like that. I agree, and there is not too much concern for compatibility in this case due to the use of an interactive workflow. -Brad -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Combinatorial validation with cmake
On 2013-11-04 10:59- PULVERAIL, Sebastien wrote: Hi there, I have been using cmake for a while now, but just for compilation.. Now, I am trying to use ctest/cdash for doing my tools validation. I need to do a combinatorial validation running my tests multiple times and in a random order. So I found the --schedule-option to run tests in a random order.. But I don't know how to specify ctest to run a test multiple times. If it is not possible, is there someone which tool I can use? Thanks for your help. Hi Sébastien: If what you want to do is run ctest (say) 1000 times, then under bash on Linux or bash.exe on MSYS/Windows, the following should work: ncount=1000 for count in $(seq $ncount); do echo executing ctest for count = $count out of $ncount ctest done 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 __ -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] spoof Not Run dashboard status
Can a test return a value to indicate that it could not be run? The use case I'm thinking of is for VTK's rendering tests. When a test is run on a driver with known bugs, the test is skipped internally, and shows up as passed in the dashboard. I suspect that it's done this way to avoid polluting the dashboard, and it's probably a good idea to keep it like this. However, I think it's an issue that it's difficult to tell which tests are being skipped on which systems and it would be very useful if these tests showed up in the dashboard as not run rather than passed. Burlen -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both UI. It would accept the same set of options: -C initial-cache = Pre-load a script to populate the cache. -D var:type=value = Create a cmake cache entry. -U globbing_expr = Remove matching entries from CMake cache. -G generator-name = Specify a makefile generator. -T toolset-name = Specify toolset name if supported by generator. Jc On Mon, Nov 4, 2013 at 5:29 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-04 15:47, David Cole wrote: My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. There are two mostly separate issues here. As far as the bug, the ccmake behavior is (IMO, but seems generally shared) is just wrong. physhh's questions (above) don't apply to this case because there is no concept of interactively selecting the build directory in ccmake. So fixing this is, if not easy, at least easy to understand how it should behave. As far as cmake-gui, there are no backward compatibility issues because right now it just doesn't support -D at all. It does however get more complicated... - What should happen with a -D option if there is not initially a build directory selected? - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. ccmake and cmake-gui *should* behave (in *my* opinion) as follows: - on startup, load the CMakeCache.txt values (if there are any) from the previous run - then apply the -D arguments so that any -D arguments given on the command line overwrite previous cache entries (just like command line cmake does already) - then put the user in charge and wait for user input I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? -- Matthew -- 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 -- +1 919 869 8849 -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] spoof Not Run dashboard status
Am Montag, 4. November 2013, 16:09:04 schrieb burlen: Can a test return a value to indicate that it could not be run? The use case I'm thinking of is for VTK's rendering tests. When a test is run on a driver with known bugs, the test is skipped internally, and shows up as passed in the dashboard. I suspect that it's done this way to avoid polluting the dashboard, and it's probably a good idea to keep it like this. However, I think it's an issue that it's difficult to tell which tests are being skipped on which systems and it would be very useful if these tests showed up in the dashboard as not run rather than passed. http://cmake.org/Bug/view.php?id=8466 Eike signature.asc Description: This is a digitally signed message part. -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.12-4827-g7e551eb
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 7e551ebaa64302843d31770fa0e116f931b5bb3d (commit) via 4dc41c1865c74bd0bc191ab07488c5fac479802c (commit) from 16d8630a82203f01ddd17fc2f5150b265752bb19 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e551ebaa64302843d31770fa0e116f931b5bb3d commit 7e551ebaa64302843d31770fa0e116f931b5bb3d Merge: 16d8630 4dc41c1 Author: Peter Kuemmel syntheti...@gmx.net AuthorDate: Mon Nov 4 06:40:31 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 06:40:31 2013 -0500 Merge topic 'ninja-edit-cache' into next 4dc41c1 Ninja: run cmake-gui for target edit_cache http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4dc41c1865c74bd0bc191ab07488c5fac479802c commit 4dc41c1865c74bd0bc191ab07488c5fac479802c Author: Peter Kümmel syntheti...@gmx.net AuthorDate: Mon Nov 4 12:34:19 2013 +0100 Commit: Peter Kümmel syntheti...@gmx.net CommitDate: Mon Nov 4 12:34:25 2013 +0100 Ninja: run cmake-gui for target edit_cache Ninja can't run commands interactively, this will never work with ninja by design, so start cmake-gui instead. http://cmake.org/Bug/view.php?id=14544 diff --git a/Modules/CMakeGenericSystem.cmake b/Modules/CMakeGenericSystem.cmake index 8a14aea..a7e22fc 100644 --- a/Modules/CMakeGenericSystem.cmake +++ b/Modules/CMakeGenericSystem.cmake @@ -65,6 +65,7 @@ if(CMAKE_GENERATOR MATCHES Ninja) Enable/Disable output of compile commands during generation. ) mark_as_advanced(CMAKE_EXPORT_COMPILE_COMMANDS) + set(CMAKE_EDIT_COMMAND cmake-gui CACHE STRING use cmake-gui for target edit_cache FORCE) endif() # GetDefaultWindowsPrefixBase diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx index 4fe5033..f626232 100644 --- a/Source/cmGlobalGenerator.cxx +++ b/Source/cmGlobalGenerator.cxx @@ -2152,7 +2152,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets) cpackCommandLines.push_back(singleLine); (*targets)[editCacheTargetName] = this-CreateGlobalTarget( - editCacheTargetName, Running CMake cache editor..., + editCacheTargetName, Running cmake-gui ..., cpackCommandLines, depends, 0); } else --- Summary of changes: Modules/CMakeGenericSystem.cmake |1 + Source/cmGlobalGenerator.cxx |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4830-g0c95f28
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 0c95f285c0a98d3b3beb7af7a753150d1c08081f (commit)
via f212615d3e799edc57128bccdc501120d753c6ee (commit)
via e405380d06052ca7e86ab9ca297f3e89fe866932 (commit)
from 7e551ebaa64302843d31770fa0e116f931b5bb3d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c95f285c0a98d3b3beb7af7a753150d1c08081f
commit 0c95f285c0a98d3b3beb7af7a753150d1c08081f
Merge: 7e551eb f212615
Author: Peter Kuemmel syntheti...@gmx.net
AuthorDate: Mon Nov 4 07:21:19 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 4 07:21:19 2013 -0500
Merge topic 'ninja-dont-parse-empty-depsflag' into next
f212615 Ninja: don't parse empty string
e405380 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f212615d3e799edc57128bccdc501120d753c6ee
commit f212615d3e799edc57128bccdc501120d753c6ee
Author: Peter Kümmel syntheti...@gmx.net
AuthorDate: Mon Nov 4 13:18:47 2013 +0100
Commit: Peter Kümmel syntheti...@gmx.net
CommitDate: Mon Nov 4 13:20:27 2013 +0100
Ninja: don't parse empty string
diff --git a/Source/cmNinjaTargetGenerator.cxx
b/Source/cmNinjaTargetGenerator.cxx
index a6f8159..26eadbe 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -398,11 +398,14 @@ cmNinjaTargetGenerator
depfile = $DEP_FILE;
const std::string flagsName = CMAKE_DEPFILE_FLAGS_ + lang;
std::string depfileFlags = mf-GetSafeDefinition(flagsName.c_str());
-cmSystemTools::ReplaceString(depfileFlags, DEPFILE, $DEP_FILE);
-cmSystemTools::ReplaceString(depfileFlags, OBJECT, $out);
-cmSystemTools::ReplaceString(depfileFlags, CMAKE_C_COMPILER,
- mf-GetDefinition(CMAKE_C_COMPILER));
-flags += + depfileFlags;
+if (!depfileFlags.empty())
+ {
+ cmSystemTools::ReplaceString(depfileFlags, DEPFILE, $DEP_FILE);
+ cmSystemTools::ReplaceString(depfileFlags, OBJECT, $out);
+ cmSystemTools::ReplaceString(depfileFlags, CMAKE_C_COMPILER,
+ mf-GetDefinition(CMAKE_C_COMPILER));
+ flags += + depfileFlags;
+ }
}
vars.Flags = flags.c_str();
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
Source/cmNinjaTargetGenerator.cxx | 13 -
2 files changed, 9 insertions(+), 6 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-596-gae57fb8
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via ae57fb8ef6bd047f5c11851dfbebe7a0b7960fc4 (commit) via 35fbc10079fcbce51f542347cf74c57e3164b85e (commit) via 9d9f102f5371a19e45fff5034f97b2f9f6d523f9 (commit) from f3698f7c4a19470eb2152ce5acfbce564cc6d4f5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae57fb8ef6bd047f5c11851dfbebe7a0b7960fc4 commit ae57fb8ef6bd047f5c11851dfbebe7a0b7960fc4 Merge: f3698f7 35fbc10 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 07:53:47 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 07:53:47 2013 -0500 Merge topic 'robust-ctest_empty_binary_directory' 35fbc10 CTest: more aggressive implementation of ctest_empty_binary_directory() 9d9f102 Tests: added test for ctest_empty_binary_directory() --- Summary of changes: Source/CTest/cmCTestScriptHandler.cxx | 63 +++- Source/CTest/cmCTestScriptHandler.h |3 + Tests/CMakeLists.txt | 11 Tests/CTestTestEmptyBinaryDirectory/test.cmake.in | 66 + 4 files changed, 140 insertions(+), 3 deletions(-) create mode 100644 Tests/CTestTestEmptyBinaryDirectory/test.cmake.in hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-603-geb3761a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via eb3761ae68ea643ee7a2a290f03017e67c888a6b (commit) via af4c1096f6878053042f3e64610c9f7fda6399cb (commit) via 6bdea066e673f0720e6faae42a4e144803679996 (commit) from a9c8f7b3007f83fd69be2f58b18d39e6cfd120eb (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb3761ae68ea643ee7a2a290f03017e67c888a6b commit eb3761ae68ea643ee7a2a290f03017e67c888a6b Merge: a9c8f7b af4c109 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 07:54:03 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 07:54:03 2013 -0500 Merge topic 'constify' af4c109 cmGeneratorTarget: Make some accessors const. 6bdea06 cmTarget: Make some accessors const. --- Summary of changes: Source/cmGeneratorTarget.cxx | 23 --- Source/cmGeneratorTarget.h | 20 ++-- Source/cmTarget.cxx | 14 +++--- Source/cmTarget.h| 14 +++--- 4 files changed, 36 insertions(+), 35 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-612-gb4a1f44
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via b4a1f442bb5c1260e87ae7e8e488c8ccef16 (commit)
via b51696f003a945e7f9de0b551afd707416cc09fa (commit)
via 25b7f87ecadb400db0d206e938ec1d2771d735a7 (commit)
via 0a561a03475f4ed1e017802970a8f17998fe05c3 (commit)
via 23d21b78e125c11a0d901eb987e5f616026ff8fd (commit)
via ef10b87cc1e87343a778c89d8a41d7e11ca08a7c (commit)
via 0e06788c0a5bd2a85db4b1559d13ead30ea5be0e (commit)
via c0f4a6107412dc7bdbd810b86407016af723cb79 (commit)
via 4b0cfa7004c1a2f5069affa4e673a24d9cf6a075 (commit)
from eb3761ae68ea643ee7a2a290f03017e67c888a6b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b4a1f442bb5c1260e87ae7e8e488c8ccef16
commit b4a1f442bb5c1260e87ae7e8e488c8ccef16
Merge: eb3761a b51696f
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 07:54:20 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 4 07:54:20 2013 -0500
Merge topic 'policy-CMP0022-fixes-for-master'
b51696f CMP0022: Update target_link_libraries plain signature documentation
25b7f87 Merge branch 'policy-CMP0022-fixes' into
policy-CMP0022-fixes-for-master
0a561a0 CMP0022: Warn about a given target at most once
23d21b7 Do not export INTERFACE_LINK_LIBRARIES from non-linkable targets
ef10b87 CMP0022: Plain target_link_libraries must populate link interface
0e06788 CMP0022: Add test for target_link_libraries plain signature
c0f4a61 CMP0022: Add unit test for null pointer check and message.
4b0cfa7 Merge branch 'output-CMP0022-entries' into policy-CMP0022-fixes
---
Summary of changes:
Help/command/target_link_libraries.rst | 17 +-
Source/cmExportFileGenerator.cxx |5 +
Source/cmTarget.cxx| 252 +---
Source/cmTargetLinkLibrariesCommand.cxx| 10 +-
.../target_link_libraries/cmp0022/CMakeLists.txt |7 +
.../cmp0022/onlyplainlib1.cpp | 13 +
.../target_link_libraries/cmp0022/onlyplainlib1.h | 14 +
.../cmp0022/onlyplainlib2.cpp |8 +
.../target_link_libraries/cmp0022/onlyplainlib2.h |7 +
.../cmp0022/onlyplainlib_user.cpp |7 +
...es-stderr.txt = CMP0022-NOWARN-exe-stderr.txt} |0
Tests/RunCMake/CMP0022/CMP0022-NOWARN-exe.cmake|7 +
...stderr.txt = CMP0022-NOWARN-shared-stderr.txt} |0
Tests/RunCMake/CMP0022/CMP0022-NOWARN-shared.cmake |8 +
.../CMP0022/CMP0022-WARN-empty-old-stderr.txt |8 +-
.../CMP0022/CMP0022-WARN-static-stderr.txt |8 +-
Tests/RunCMake/CMP0022/CMP0022-WARN-stderr.txt |6 +-
Tests/RunCMake/CMP0022/CMP0022-WARN-tll-stderr.txt |4 +-
Tests/RunCMake/CMP0022/CMP0022-WARN.cmake |5 +
...es-stderr.txt = CMP0022-export-exe-stderr.txt} |0
Tests/RunCMake/CMP0022/CMP0022-export-exe.cmake|9 +
Tests/RunCMake/CMP0022/RunCMakeTest.cmake |3 +
.../CMP0022/{empty_vs6_1.cpp = empty_vs6_4.cpp} |0
23 files changed, 237 insertions(+), 161 deletions(-)
create mode 100644
Tests/CMakeCommands/target_link_libraries/cmp0022/onlyplainlib1.cpp
create mode 100644
Tests/CMakeCommands/target_link_libraries/cmp0022/onlyplainlib1.h
create mode 100644
Tests/CMakeCommands/target_link_libraries/cmp0022/onlyplainlib2.cpp
create mode 100644
Tests/CMakeCommands/target_link_libraries/cmp0022/onlyplainlib2.h
create mode 100644
Tests/CMakeCommands/target_link_libraries/cmp0022/onlyplainlib_user.cpp
copy Tests/RunCMake/CMP0022/{CMP0022-NOWARN-static-link_libraries-stderr.txt
= CMP0022-NOWARN-exe-stderr.txt} (100%)
create mode 100644 Tests/RunCMake/CMP0022/CMP0022-NOWARN-exe.cmake
copy Tests/RunCMake/CMP0022/{CMP0022-NOWARN-static-link_libraries-stderr.txt
= CMP0022-NOWARN-shared-stderr.txt} (100%)
create mode 100644 Tests/RunCMake/CMP0022/CMP0022-NOWARN-shared.cmake
copy Tests/RunCMake/CMP0022/{CMP0022-NOWARN-static-link_libraries-stderr.txt
= CMP0022-export-exe-stderr.txt} (100%)
create mode 100644 Tests/RunCMake/CMP0022/CMP0022-export-exe.cmake
copy Tests/RunCMake/CMP0022/{empty_vs6_1.cpp = empty_vs6_4.cpp} (100%)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-593-gf3698f7
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via f3698f7c4a19470eb2152ce5acfbce564cc6d4f5 (commit) via 53d6ebb36079bd30c9033e4374fd8d31a2928b6a (commit) via 193029c4aaad7a13f0b6efed59a1c88af0dc6714 (commit) from e405380d06052ca7e86ab9ca297f3e89fe866932 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f3698f7c4a19470eb2152ce5acfbce564cc6d4f5 commit f3698f7c4a19470eb2152ce5acfbce564cc6d4f5 Merge: e405380 53d6ebb Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 07:53:25 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 07:53:25 2013 -0500 Merge topic 'cpack-drag-n-drop-rez' 53d6ebb cpack: For DragNDrop generator, add sysroot option when calling Rez. 193029c cpack: For DragNDrop generator, add sysroot option when calling Rez. --- Summary of changes: Modules/CPack.cmake|5 + Source/CPack/cmCPackDragNDropGenerator.cxx |7 ++- Tests/CPackComponentsForAll/CMakeLists.txt |3 ++- .../CPackComponentsForAll/license.txt |4 +--- 4 files changed, 14 insertions(+), 5 deletions(-) copy Templates/CPack.GenericLicense.txt = Tests/CPackComponentsForAll/license.txt (90%) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-598-g1d99808
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 1d998085be4d17def0e1163bf078603a21d16880 (commit) via 8c6363a62f8ea61c6a572e4ffd08ce3e970f47b5 (commit) from ae57fb8ef6bd047f5c11851dfbebe7a0b7960fc4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d998085be4d17def0e1163bf078603a21d16880 commit 1d998085be4d17def0e1163bf078603a21d16880 Merge: ae57fb8 8c6363a Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 07:53:51 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 07:53:51 2013 -0500 Merge topic 'improve-tgt-INCLUDE_DIRECTORIES-docs' 8c6363a cmTarget: Improve INCLUDE_DIRECTORIES property docs (#13188). --- Summary of changes: Help/prop_tgt/INCLUDE_DIRECTORIES.rst | 13 - 1 files changed, 8 insertions(+), 5 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4839-g4e0fedf
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 4e0fedf1bd71495627eb49a52a8de8e52bdefa98 (commit) via b4a1f442bb5c1260e87ae7e8e488c8ccef16 (commit) via eb3761ae68ea643ee7a2a290f03017e67c888a6b (commit) via a9c8f7b3007f83fd69be2f58b18d39e6cfd120eb (commit) via 1d998085be4d17def0e1163bf078603a21d16880 (commit) via ae57fb8ef6bd047f5c11851dfbebe7a0b7960fc4 (commit) via f3698f7c4a19470eb2152ce5acfbce564cc6d4f5 (commit) from 478711dd7ceddfe48cbeecdba32a01b7345934ac (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4e0fedf1bd71495627eb49a52a8de8e52bdefa98 commit 4e0fedf1bd71495627eb49a52a8de8e52bdefa98 Merge: 478711d b4a1f44 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 07:54:38 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 4 07:54:38 2013 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-600-ga9c8f7b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via a9c8f7b3007f83fd69be2f58b18d39e6cfd120eb (commit) via 12d10a00ac03ad206e00cbec321e76415e2adbe0 (commit) from 1d998085be4d17def0e1163bf078603a21d16880 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a9c8f7b3007f83fd69be2f58b18d39e6cfd120eb commit a9c8f7b3007f83fd69be2f58b18d39e6cfd120eb Merge: 1d99808 12d10a0 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 07:53:57 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 07:53:57 2013 -0500 Merge topic 'doc-CMAKE_INCLUDE_DIRECTORIES_BEFORE' 12d10a0 Add missing documentation for include dirs related variables. (#12611) --- Summary of changes: Help/command/include_directories.rst |2 +- Help/manual/cmake-variables.7.rst |2 ++ Help/variable/CMAKE_INCLUDE_DIRECTORIES_BEFORE.rst |8 .../CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE.rst |8 4 files changed, 19 insertions(+), 1 deletions(-) create mode 100644 Help/variable/CMAKE_INCLUDE_DIRECTORIES_BEFORE.rst create mode 100644 Help/variable/CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE.rst hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4844-gf603d52
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via f603d527cc244247ede1256b5d43bb9432627b7d (commit) via e9654c632ac735d5fd5a7e1999fbb747410ac7c3 (commit) via 23087ebcca82e7de4d3927d585db7a212a7270c6 (commit) via 603fe9253f74d92c6a571cd53d96b91761b4335f (commit) via 0aa97b6bb798570ea0611153a5614ea5a9ea9875 (commit) from 4e0fedf1bd71495627eb49a52a8de8e52bdefa98 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f603d527cc244247ede1256b5d43bb9432627b7d commit f603d527cc244247ede1256b5d43bb9432627b7d Merge: 4e0fedf e9654c6 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 08:35:58 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 08:35:58 2013 -0500 Merge topic 'policy-CMP0022-fixes-for-master' into next e9654c6 Fix INTERFACE_LINK_LIBRARIES documentation typos 23087eb Merge branch 'policy-CMP0022-fixes' into policy-CMP0022-fixes-for-master 603fe92 Fix summary documentation of INTERFACE_LINK_LIBRARIES 0aa97b6 Fix spelling in INTERFACE_LINK_LIBRARIES documentation (#14542) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e9654c632ac735d5fd5a7e1999fbb747410ac7c3 commit e9654c632ac735d5fd5a7e1999fbb747410ac7c3 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 08:33:36 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 4 08:33:38 2013 -0500 Fix INTERFACE_LINK_LIBRARIES documentation typos Apply the changes from commit 603fe925 (Fix summary documentation of INTERFACE_LINK_LIBRARIES, 2013-11-04) and commit 0aa97b6b (Fix spelling in INTERFACE_LINK_LIBRARIES documentation, 2013-11-04) to the new location of the same documentation. diff --git a/Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst b/Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst index 24c2441..64ac46e 100644 --- a/Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst +++ b/Help/prop_tgt/INTERFACE_LINK_LIBRARIES.rst @@ -1,12 +1,12 @@ INTERFACE_LINK_LIBRARIES -List public interface libraries for a shared library or executable. +List public interface libraries for a library. This property contains the list of transitive link dependencies. When the target is linked into another target the libraries listed (and recursively their link interface libraries) will be provided to the -other target also. This property is overriden by the +other target also. This property is overridden by the LINK_INTERFACE_LIBRARIES or LINK_INTERFACE_LIBRARIES_CONFIG property if policy CMP0022 is OLD or unset. diff --git a/Help/prop_tgt/LINK_INTERFACE_LIBRARIES.rst b/Help/prop_tgt/LINK_INTERFACE_LIBRARIES.rst index 75c2a31..435e25e 100644 --- a/Help/prop_tgt/LINK_INTERFACE_LIBRARIES.rst +++ b/Help/prop_tgt/LINK_INTERFACE_LIBRARIES.rst @@ -16,7 +16,7 @@ the default set is non-empty. This property is initialized by the value of the variable CMAKE_LINK_INTERFACE_LIBRARIES if it is set when a target is created. This property is ignored for STATIC libraries. -This property is overriden by the INTERFACE_LINK_LIBRARIES property if +This property is overridden by the INTERFACE_LINK_LIBRARIES property if policy CMP0022 is NEW. This property is deprecated. Use INTERFACE_LINK_LIBRARIES instead. diff --git a/Help/prop_tgt/LINK_INTERFACE_LIBRARIES_CONFIG.rst b/Help/prop_tgt/LINK_INTERFACE_LIBRARIES_CONFIG.rst index 1a7a941..08bd650 100644 --- a/Help/prop_tgt/LINK_INTERFACE_LIBRARIES_CONFIG.rst +++ b/Help/prop_tgt/LINK_INTERFACE_LIBRARIES_CONFIG.rst @@ -7,7 +7,7 @@ This is the configuration-specific version of LINK_INTERFACE_LIBRARIES. If set, this property completely overrides the generic property for the named configuration. -This property is overriden by the INTERFACE_LINK_LIBRARIES property if +This property is overridden by the INTERFACE_LINK_LIBRARIES property if policy CMP0022 is NEW. This property is deprecated. Use INTERFACE_LINK_LIBRARIES instead. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23087ebcca82e7de4d3927d585db7a212a7270c6 commit 23087ebcca82e7de4d3927d585db7a212a7270c6 Merge: b4a1f44 603fe92 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 08:32:16 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 4 08:32:16 2013 -0500 Merge branch 'policy-CMP0022-fixes' into policy-CMP0022-fixes-for-master http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=603fe9253f74d92c6a571cd53d96b91761b4335f commit 603fe9253f74d92c6a571cd53d96b91761b4335f Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 08:28:57 2013
[Cmake-commits] CMake branch, next, updated. v2.8.12-4846-gcd64cb0
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via cd64cb070608961ca65e4fb72ccdc33a7e14ce3b (commit)
via a06debcde91866c005e88cb9d805a3351859aeef (commit)
from f603d527cc244247ede1256b5d43bb9432627b7d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd64cb070608961ca65e4fb72ccdc33a7e14ce3b
commit cd64cb070608961ca65e4fb72ccdc33a7e14ce3b
Merge: f603d52 a06debc
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 08:52:29 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 4 08:52:29 2013 -0500
Merge topic 'FindPHP4-no-cache-output' into next
a06debc FindPHP4: Drop extra content from reported PHP4_INCLUDE_PATH
(#14540)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a06debcde91866c005e88cb9d805a3351859aeef
commit a06debcde91866c005e88cb9d805a3351859aeef
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 08:51:46 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 4 08:51:46 2013 -0500
FindPHP4: Drop extra content from reported PHP4_INCLUDE_PATH (#14540)
The set() call for this variable left out the CACHE keyword. It does
not need to be cached anyway, so drop the other CACHE set() signature
arguments.
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722475
Reported-by: Modestas Vainius mo...@debian.org
Inspired-by: Mathieu Malaterre ma...@debian.org
diff --git a/Modules/FindPHP4.cmake b/Modules/FindPHP4.cmake
index 51a89f3..25fff8c 100644
--- a/Modules/FindPHP4.cmake
+++ b/Modules/FindPHP4.cmake
@@ -46,7 +46,7 @@ if(PHP4_FOUND_INCLUDE_PATH)
foreach(php4_path Zend main TSRM)
set(php4_paths ${php4_paths} ${PHP4_FOUND_INCLUDE_PATH}/${php4_path})
endforeach()
- set(PHP4_INCLUDE_PATH ${php4_paths} INTERNAL PHP4 include paths)
+ set(PHP4_INCLUDE_PATH ${php4_paths})
endif()
find_program(PHP4_EXECUTABLE NAMES php4 php )
---
Summary of changes:
Modules/FindPHP4.cmake |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4857-g9027cc3
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 9027cc39da581e6f17f87bc4bd63898e66ec96f3 (commit)
via 193c05d72f3c643d05e5f8bf634d93376998d547 (commit)
from 04db04c7d3d15e8b9947ade652162194b880d9c6 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9027cc39da581e6f17f87bc4bd63898e66ec96f3
commit 9027cc39da581e6f17f87bc4bd63898e66ec96f3
Merge: 04db04c 193c05d
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Nov 4 10:15:36 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 4 10:15:36 2013 -0500
Merge topic 'target_compile_features' into next
193c05d Move test files to the correct location.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=193c05d72f3c643d05e5f8bf634d93376998d547
commit 193c05d72f3c643d05e5f8bf634d93376998d547
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Oct 30 21:13:44 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Nov 4 16:14:36 2013 +0100
Move test files to the correct location.
diff --git
a/Tests/CMakeCommands/target_compiler_features/lib_delegating_constructors.cpp
b/Tests/CMakeCommands/target_compile_features/lib_delegating_constructors.cpp
similarity index 100%
rename from
Tests/CMakeCommands/target_compiler_features/lib_delegating_constructors.cpp
rename to
Tests/CMakeCommands/target_compile_features/lib_delegating_constructors.cpp
diff --git
a/Tests/CMakeCommands/target_compiler_features/lib_delegating_constructors.h
b/Tests/CMakeCommands/target_compile_features/lib_delegating_constructors.h
similarity index 100%
rename from
Tests/CMakeCommands/target_compiler_features/lib_delegating_constructors.h
rename to
Tests/CMakeCommands/target_compile_features/lib_delegating_constructors.h
diff --git a/Tests/CMakeCommands/target_compiler_features/lib_user.cpp
b/Tests/CMakeCommands/target_compile_features/lib_user.cpp
similarity index 100%
rename from Tests/CMakeCommands/target_compiler_features/lib_user.cpp
rename to Tests/CMakeCommands/target_compile_features/lib_user.cpp
---
Summary of changes:
.../lib_delegating_constructors.cpp|0
.../lib_delegating_constructors.h |0
.../lib_user.cpp |0
3 files changed, 0 insertions(+), 0 deletions(-)
rename Tests/CMakeCommands/{target_compiler_features =
target_compile_features}/lib_delegating_constructors.cpp (100%)
rename Tests/CMakeCommands/{target_compiler_features =
target_compile_features}/lib_delegating_constructors.h (100%)
rename Tests/CMakeCommands/{target_compiler_features =
target_compile_features}/lib_user.cpp (100%)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4860-g2e2047b
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 2e2047be1371469be2449b96720ee372d30ce76d (commit)
via e27f90430f75a2d3d0957d26ac38432c27725c16 (commit)
via 1abe6cf39a5b5d4a564a1a535337f91b64709ff9 (commit)
from 9027cc39da581e6f17f87bc4bd63898e66ec96f3 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e2047be1371469be2449b96720ee372d30ce76d
commit 2e2047be1371469be2449b96720ee372d30ce76d
Merge: 9027cc3 e27f904
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Nov 4 10:16:39 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 4 10:16:39 2013 -0500
Merge topic 'target_compile_features' into next
e27f904 Base the target_compile_features command on cmTargetPropCommandBase.
1abe6cf cmTarget: Transitively evaluate compiler features.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e27f90430f75a2d3d0957d26ac38432c27725c16
commit e27f90430f75a2d3d0957d26ac38432c27725c16
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Oct 30 21:13:44 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Nov 4 16:16:01 2013 +0100
Base the target_compile_features command on cmTargetPropCommandBase.
This gives us 'free' handling of IMPORTED, ALIAS, INTERFACE,
non-compilable and missing targets.
diff --git a/Source/cmTargetCompileFeaturesCommand.cxx
b/Source/cmTargetCompileFeaturesCommand.cxx
index 4217eb3..6948717 100644
--- a/Source/cmTargetCompileFeaturesCommand.cxx
+++ b/Source/cmTargetCompileFeaturesCommand.cxx
@@ -15,51 +15,50 @@ bool cmTargetCompileFeaturesCommand::InitialPass(
std::vectorstd::string const args,
cmExecutionStatus )
{
- if (args.size() 3)
-{
- this-SetError(called with wrong number of arguments.);
- return false;
-}
- cmTarget *target = this-Makefile-FindTargetToUse(args[0].c_str());
+ return this-HandleArguments(args, COMPILE_FEATURES, NO_FLAGS);
+}
- if(!target)
-{
-this-SetError(specified invalid target.);
-return false;
-}
+void cmTargetCompileFeaturesCommand
+::HandleImportedTarget(const std::string tgt)
+{
+ cmOStringStream e;
+ e Cannot specify compile features for imported target \
+ tgt \.;
+ this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
+}
- if(target-IsImported())
-{
-this-SetError(may not be used with an IMPORTED target.);
-return false;
-}
+void cmTargetCompileFeaturesCommand
+::HandleMissingTarget(const std::string name)
+{
+ cmOStringStream e;
+ e Cannot specify compile features for target \ name \
+ which is not built by this project.;
+ this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
+}
- const bool interfaceOnly = args[1] == INTERFACE;
- if(args[1] != PRIVATE args[1] != PUBLIC !interfaceOnly)
+//
+std::string cmTargetCompileFeaturesCommand
+::Join(const std::vectorstd::string content)
+{
+ std::string defs;
+ std::string sep;
+ for(std::vectorstd::string::const_iterator it = content.begin();
+it != content.end(); ++it)
{
-this-SetError(called with invalid arguments.);
-return false;
+defs += sep + *it;
+sep = ;;
}
+ return defs;
+}
- for (size_t i = 2; i args.size(); ++i)
+//
+void cmTargetCompileFeaturesCommand
+::HandleDirectContent(cmTarget *tgt, const std::vectorstd::string content,
+ bool, bool)
+{
+ for(std::vectorstd::string::const_iterator it = content.begin();
+it != content.end(); ++it)
{
-std::string feature = args[i];
-
-if (!interfaceOnly)
- {
- bool result = this-Makefile-AddRequiredTargetFeature(target,
-feature.c_str());
-
- if (!result)
-{
-this-SetError(specified unknown feature.);
-return false;
-}
- }
-if (interfaceOnly || args[1] == PUBLIC)
- {
- target-AppendProperty(INTERFACE_COMPILE_FEATURES, feature.c_str());
- }
+this-Makefile-AddRequiredTargetFeature(tgt, it-c_str());
}
- return true;
}
diff --git a/Source/cmTargetCompileFeaturesCommand.h
b/Source/cmTargetCompileFeaturesCommand.h
index 63beeca..9386c84 100644
--- a/Source/cmTargetCompileFeaturesCommand.h
+++ b/Source/cmTargetCompileFeaturesCommand.h
@@ -12,9 +12,9 @@
#ifndef cmTargetCompileFeaturesCommand_h
#define cmTargetCompileFeaturesCommand_h
-#include cmCommand.h
+#include
[Cmake-commits] CMake branch, next, updated. v2.8.12-4862-g6c6cc6d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 6c6cc6d68206513ccbf8facb7021c1640a55bb0b (commit) via d1e8a0240b6218628af0992c8cc3e89d7609a311 (commit) from 2e2047be1371469be2449b96720ee372d30ce76d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6c6cc6d68206513ccbf8facb7021c1640a55bb0b commit 6c6cc6d68206513ccbf8facb7021c1640a55bb0b Merge: 2e2047b d1e8a02 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 11:10:14 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 11:10:14 2013 -0500 Merge topic 'doc-tool-usage' into next d1e8a02 Help: Refine manual/*.1.rst usage summaries http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1e8a0240b6218628af0992c8cc3e89d7609a311 commit d1e8a0240b6218628af0992c8cc3e89d7609a311 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 11:03:33 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 4 11:06:14 2013 -0500 Help: Refine manual/*.1.rst usage summaries Use a parsed-literal block to list possible command-line signatures. Add an Options section header before the list of options. diff --git a/Help/manual/ccmake.1.rst b/Help/manual/ccmake.1.rst index 0c4f47e..a5fe191 100644 --- a/Help/manual/ccmake.1.rst +++ b/Help/manual/ccmake.1.rst @@ -6,10 +6,9 @@ ccmake(1) Synopsis -:: +.. parsed-literal:: - ccmake path-to-source - ccmake path-to-existing-build + ccmake [options] (path-to-source | path-to-existing-build) Description === @@ -25,6 +24,9 @@ in each directory of a source tree with the name CMakeLists.txt. Users build a project by using CMake to generate a build system for a native tool on their platform. +Options +=== + .. include:: OPTIONS_BUILD.txt .. include:: OPTIONS_HELP.txt diff --git a/Help/manual/cmake-gui.1.rst b/Help/manual/cmake-gui.1.rst index ff01332..032b51f 100644 --- a/Help/manual/cmake-gui.1.rst +++ b/Help/manual/cmake-gui.1.rst @@ -6,11 +6,10 @@ cmake-gui(1) Synopsis -:: +.. parsed-literal:: - cmake-gui [options] - cmake-gui [options] path-to-source - cmake-gui [options] path-to-existing-build + cmake-gui [options] + cmake-gui [options] (path-to-source | path-to-existing-build) Description === @@ -25,6 +24,9 @@ in each directory of a source tree with the name CMakeLists.txt. Users build a project by using CMake to generate a build system for a native tool on their platform. +Options +=== + .. include:: OPTIONS_HELP.txt See Also diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst index f74402e..b1f1dc0 100644 --- a/Help/manual/cmake.1.rst +++ b/Help/manual/cmake.1.rst @@ -6,10 +6,13 @@ cmake(1) Synopsis -:: +.. parsed-literal:: - cmake [options] path-to-source - cmake [options] path-to-existing-build + cmake [options] (path-to-source | path-to-existing-build) + cmake [(-Dvar=value)...] -P cmake-script-file + cmake --build dir [options] [-- build-tool-options...] + cmake -E command [options] + cmake --find-package options... Description === @@ -25,6 +28,9 @@ in each directory of a source tree with the name CMakeLists.txt. Users build a project by using CMake to generate a build system for a native tool on their platform. +Options +=== + .. include:: OPTIONS_BUILD.txt * ``-E``: CMake command mode. diff --git a/Help/manual/cpack.1.rst b/Help/manual/cpack.1.rst index 22e5d5a..5967d6f 100644 --- a/Help/manual/cpack.1.rst +++ b/Help/manual/cpack.1.rst @@ -6,9 +6,9 @@ cpack(1) Synopsis -:: +.. parsed-literal:: - cpack -G generator [options] + cpack -G generator [options] Description === @@ -24,6 +24,8 @@ in each directory of a source tree with the name CMakeLists.txt. Users build a project by using CMake to generate a build system for a native tool on their platform. +Options +=== * ``-G generator``: Use the specified generator to generate package. diff --git a/Help/manual/ctest.1.rst b/Help/manual/ctest.1.rst index 4a5f12e..ed9195e 100644 --- a/Help/manual/ctest.1.rst +++ b/Help/manual/ctest.1.rst @@ -6,9 +6,9 @@ ctest(1) Synopsis -:: +.. parsed-literal:: - ctest [options] + ctest [options] Description === @@ -18,6 +18,8 @@ CMake-generated build trees created for projects that use the ENABLE_TESTING and ADD_TEST commands have testing support. This program will run the tests and report results. +Options +=== * ``-C cfg, --build-config cfg``: Choose configuration to test.
[Cmake-commits] CMake branch, next, updated. v2.8.12-4864-g0ae0278
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 0ae02782f5c1f62959bc62e7c01c89b54e0df271 (commit) via 0fa9aea2936eea1081b088caca29bad731437773 (commit) from 6c6cc6d68206513ccbf8facb7021c1640a55bb0b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ae02782f5c1f62959bc62e7c01c89b54e0df271 commit 0ae02782f5c1f62959bc62e7c01c89b54e0df271 Merge: 6c6cc6d 0fa9aea Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 11:18:17 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Nov 4 11:18:17 2013 -0500 Merge topic 'remove-cmake-i-wizard' into next 0fa9aea Help: Drop mention of cmake -i wizard mode http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0fa9aea2936eea1081b088caca29bad731437773 commit 0fa9aea2936eea1081b088caca29bad731437773 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Nov 4 11:07:16 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Nov 4 11:16:22 2013 -0500 Help: Drop mention of cmake -i wizard mode The parent commit removed support for this mode, so do not mention it in the documentation. diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst index 46190b5..c9d23db 100644 --- a/Help/manual/cmake.1.rst +++ b/Help/manual/cmake.1.rst @@ -14,8 +14,7 @@ Description The cmake executable is the CMake command-line interface. It may be used to configure projects in scripts. Project configuration settings -may be specified on the command line with the -D option. The -i -option will cause cmake to interactively prompt for such settings. +may be specified on the command line with the -D option. CMake is a cross-platform build system generator. Projects specify their build process with platform-independent CMake listfiles included diff --git a/Help/variable/CMAKE_EDIT_COMMAND.rst b/Help/variable/CMAKE_EDIT_COMMAND.rst index 24d26b5..a5c13f4 100644 --- a/Help/variable/CMAKE_EDIT_COMMAND.rst +++ b/Help/variable/CMAKE_EDIT_COMMAND.rst @@ -4,4 +4,4 @@ CMAKE_EDIT_COMMAND Full path to cmake-gui or ccmake. This is the full path to the CMake executable that can graphically -edit the cache. For example, cmake-gui, ccmake, or cmake -i. +edit the cache. For example, cmake-gui or ccmake. --- Summary of changes: Help/manual/cmake.1.rst |3 +-- Help/variable/CMAKE_EDIT_COMMAND.rst |2 +- 2 files changed, 2 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4866-gd1e4f97
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via d1e4f972b67d314dbc75022b67e6e2fa72e2a130 (commit)
via 2e388cc3c2c0f670b9f1f53a0fbc1217db3c72e3 (commit)
from 0ae02782f5c1f62959bc62e7c01c89b54e0df271 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1e4f972b67d314dbc75022b67e6e2fa72e2a130
commit d1e4f972b67d314dbc75022b67e6e2fa72e2a130
Merge: 0ae0278 2e388cc
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 16:30:46 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 4 16:30:46 2013 -0500
Merge topic 'clear-evaluation-files' into next
2e388cc file(GENERATE): Clear internal records between configures
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e388cc3c2c0f670b9f1f53a0fbc1217db3c72e3
commit 2e388cc3c2c0f670b9f1f53a0fbc1217db3c72e3
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 16:10:07 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 4 16:14:49 2013 -0500
file(GENERATE): Clear internal records between configures
In the CMake interactive dialogs cmGlobalGenerator::Configure may
run more than once. Clear the cmGlobalGenerator::EvaluationFiles
data between configures to avoid accessing deleted data.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 7f2b592..5fefeba 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -848,6 +848,14 @@ void cmGlobalGenerator::Configure()
delete this-LocalGenerators[i];
}
this-LocalGenerators.clear();
+ for(std::vectorcmGeneratorExpressionEvaluationFile*::const_iterator
+ li = this-EvaluationFiles.begin();
+ li != this-EvaluationFiles.end();
+ ++li)
+{
+delete *li;
+}
+ this-EvaluationFiles.clear();
this-TargetDependencies.clear();
this-TotalTargets.clear();
this-ImportedTargets.clear();
---
Summary of changes:
Source/cmGlobalGenerator.cxx |8
1 files changed, 8 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4868-g14e7472
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 14e747219e33d8ce8e4e344b62a21084ffcf20b9 (commit)
via 2377210994eb7a829e68a41919a550d2025185c8 (commit)
from d1e4f972b67d314dbc75022b67e6e2fa72e2a130 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=14e747219e33d8ce8e4e344b62a21084ffcf20b9
commit 14e747219e33d8ce8e4e344b62a21084ffcf20b9
Merge: d1e4f97 2377210
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 18:28:06 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 4 18:28:06 2013 -0500
Merge topic 'fix-autogen-definitions' into next
2377210 cmQtAutogen: Skip during bootstrap of CMake
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2377210994eb7a829e68a41919a550d2025185c8
commit 2377210994eb7a829e68a41919a550d2025185c8
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 18:26:11 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Nov 4 18:26:11 2013 -0500
cmQtAutogen: Skip during bootstrap of CMake
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index ead3508..2ffd478 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1097,10 +1097,12 @@ void cmGlobalGenerator::Generate()
this-FinalizeTargetCompileDefinitions();
+#ifdef CMAKE_BUILD_WITH_CMAKE
// Iterate through all targets and set up automoc for those which have
// the AUTOMOC, AUTOUIC or AUTORCC property set
AutogensType autogens;
this-CreateQtAutoGeneratorsTargets(autogens);
+#endif
// For each existing cmLocalGenerator
unsigned int i;
@@ -1134,11 +1136,13 @@ void cmGlobalGenerator::Generate()
// Create per-target generator information.
this-CreateGeneratorTargets();
+#ifdef CMAKE_BUILD_WITH_CMAKE
for (AutogensType::iterator it = autogens.begin(); it != autogens.end();
++it)
{
it-first.SetupAutoGenerateTarget(it-second);
}
+#endif
// Trace the dependencies, after that no custom commands should be added
// because their dependencies might not be handled correctly
---
Summary of changes:
Source/cmGlobalGenerator.cxx |4
1 files changed, 4 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-618-gf6f7531
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via f6f7531353a7154e1409ea7de72e79dd45c29366 (commit) from f4253d7bf644ce93eb1fb909432317d47423a788 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6f7531353a7154e1409ea7de72e79dd45c29366 commit f6f7531353a7154e1409ea7de72e79dd45c29366 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Nov 5 00:01:07 2013 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Nov 5 00:01:07 2013 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 47caddd..b68fdaf 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 12) -set(CMake_VERSION_TWEAK 20131104) +set(CMake_VERSION_TWEAK 20131105) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
