On 2013-11-05 09:25, David Cole wrote:
Matthew Woehlke wrote:
- What should happen with a -D option if there is not initially a
build directory selected?
It should add UI entries even though there is no build directory
selected, and set them according to the -D values. Then, the -D values
should be forgotten about and never applied again during that session,
regardless of future user actions.
Also, you could require that for -D args to work properly, the current
directory *is* the binary directory at startup time (just like cmake and
ccmake). If you're passing -D arguments to the gui program, then you
have control over its launching point, and can set the current directory
to be whatever you like.
If launched without a build directory, you could choose the last known
build directory (if there is one) just like cmake-gui does now.
If no build directory, no -D args.
[...]
I think you're vastly over complicating the solution to a very simple
problem.
If you read physsh's question that lead to this:
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.
...it seems very explicit that your proposal is inadequate for his use case.
Besides, I don't think the parallel holds: cmake-gui != ccmake.
In ccmake, there is no concept of choosing / changing the build
directory - one *must* run it with $PWD == ${CMAKE_BINARY_DIR} - so it
makes sense to only apply -D/etc. to the initial build directory.
This is very much not the case with cmake-gui; it might be launched from
a desktop / launcher menu shortcut where all bets as to $PWD are off,
and anyway it may not even start with $PWD as the build directory.
The ability to change the build directory after launching, which is
unique to cmake-gui, is IMHO very much worth handling -D/etc. options
differently for that reason.
Again, looking at physsh's comments, I think we should be considering
the case of someone that wants to always pass the same -D/etc. arguments
'by default'. One might conceivably (expect to be able to) do this by
modifying the cmake-gui shortcut to include the desired options. For
that to work, cmake-gui would need to apply the options to any
newly-configured project, even if it wasn't the initially selected
project. (For that matter, one might conceivably want to configure
several projects, or at least several build directories, in one
'session', with the options applied to all of them.) I think this is a
very reasonable use case that should be supported, and I tried to
address that in my proposal.
--
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
