[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
