|
Notes |
|
|
(0034341)
|
|
Peter Kuemmel
|
|
2013-11-04 06:42
|
|
|
cmake-gui (the Qt GUI) is called instead. |
|
|
|
(0034348)
|
|
Brad King
|
|
2013-11-04 09:32
|
|
I see this commit proposed:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4dc41c18 [^]
but that makes changes that affect generators other than Ninja. In particular:
- editCacheTargetName, "Running CMake cache editor...",
+ editCacheTargetName, "Running cmake-gui ...",
The reason the generic "CMake cache editor" description is given is because it may be ccmake if cmake-gui was not built.
Also, this hunk:
+ set(CMAKE_EDIT_COMMAND cmake-gui CACHE STRING "use cmake-gui for target edit_cache" FORCE)
while in a Ninja-specific branch is better implemented in C++ code, perhaps with help from a virtual function override in cmGlobalNinjaGenerator.
|
|
|
|
(0034386)
|
|
Peter Kuemmel
|
|
2013-11-05 05:35
|
|
I've reverted, changing editCacheTargetName in a non-ninja file was by accident, it's clear that ccmake is the default, somehow I've overseen that is is a general file.
I always wonder what's better: changing the cmake or the C++ file. Is there a rule? |
|
|
|
(0034388)
|
|
Brad King
|
2013-11-05 08:01
(edited on: 2013-11-05 08:02) |
|
Re 0014544:0034386: It is not always clear whether something is better in module code or in C++ code, but in this case CMAKE_EDIT_COMMAND is managed exclusively by C++ code currently so this should remain to be the case.
|
|
|
|
(0034396)
|
|
Peter Kuemmel
|
|
2013-11-05 11:49
|
|
|
|
|
(0034398)
|
|
Brad King
|
|
2013-11-05 12:42
|
|
Re 0014544:0034396: I dug a bit deeper here. The value of CMAKE_EDIT_COMMAND is set here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmake.cxx;hb=v2.8.12#l1014 [^]
and is forced by ccmake or cmake-gui to point to itself. That way the edit_cache target always matches the most recent dialog used on the tree. However, for Ninja we cannot honor ccmake, so the Ninja generator could simply ignore CMAKE_EDIT_COMMAND altogether and always use cmake-gui if it exists. |
|
|
|
(0034399)
|
|
Peter Kuemmel
|
|
2013-11-05 13:02
|
|
|
Yes, I also read this comment, but maybe someone has defined CMAKE_EDIT_COMMAND by the command line. I just used the most conservative version, but I have no problem with removing the def reading, so decide, your choice ;) |
|
|
|
(0034400)
|
|
Brad King
|
|
2013-11-05 13:06
|
|
|
Re 0014544:0034399: How does 0a39685f change anything by default? The CMAKE_EDIT_COMMAND will still be set to ccmake first unless one uses cmake-gui to create the build tree, and then GetEditCacheCommand will still use the value. Also, the fallback assumes "cmake-gui" is in the PATH without checking if it was even built with the current version of CMake. |
|
|
|
(0034401)
|
|
Peter Kuemmel
|
|
2013-11-05 13:20
|
|
|
0a39685f returns the value of CMAKE_EDIT_COMMAND regardless where it comes from. But when it is overwritten somewhere else, it makes no sense to read (don't now if, and also don't care, all this ping-pong from C++ to cmake, command-line, defaults, defines in same shipped cmake files, ...). So I will just set cmake-gui. |
|
|
|
(0034456)
|
|
Brad King
|
|
2013-11-18 08:24
|
|
After some internal refactoring to simplify lookup of CMake executable locations, I then refactored selection of the edit_cache dialog across all generators:
Refactor tool selection for edit_cache
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=684063c0 [^]
Now it always uses cmake-gui for Ninja and for Makefile generators when an "extra" generator for an IDE is in use that also won't have a terminal. |
|
|
|
(0036013)
|
|
Robert Maynard
|
|
2014-06-02 08:37
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|