On 11/04/2014 06:38 PM, Eric Wing wrote:
This would be really useful to me.
No one plans to work on it AFAIK. You'd have to dig in yourself.
Sorry,
-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
Bump. With CMake 3.1 on the horizon, I was wondering if there was any
progress on this.
This would be really useful to me. I am basically invoking command
line cmake.exe so I can pass all the right options, including my own
CMake Initial Cache file. I ship an entire self-contained SDK of
sorts
Well I've tried to make the problem as clear as possible but somehow it
seems it still wasn't clear enough.
In my opinion the solution which was proposed by Mathew was also pretty
clear - also not absolutly complete as he stated himself.
How should we proceed? I think Mathew understood what's my
On 11/06/2013 02:55 PM, physhh . wrote:
How should we proceed? I think Mathew understood what's my problem.
This thread has covered use cases in which it makes sense to apply
(or not apply) command-line parameters in cmake-gui for various
cases. No one automatic behavior is going to satisfy
+1
I like the idea of the [Apply Command Line Parameters button appear
whenever -Dvar=value parameters were passed.]
Would also be nice if parameter like -G ... could also be considered for
the first configuration. Within some of our project, I envision user
downloading a bat script named
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
-D var:type=value
-U globbing_expr
-G generator-name
-T toolset-name
It would appear that ccmake is
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?
+1 for Mathews solution. To bad it's just on the developers list.
I will simply cite him:
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
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
On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke matthew.woeh...@kitware.com
wrote:
On 2013-11-05 14:36, Alexander Neundorf wrote:
I tried the following a few times in the past and noticed everytime that
it
does not work:
$ cd src
src/ $ mkdir build
src/ $ cd build
src/build/ $ cmake-gui
Wouldn't it then be possible to write a simple shell script for those
people who really want that use case which calls cmake with -U and
afterwards call cmake-gui?
Sorry if I didn't understood it as it was ment.
For me the thing is:
I prefer a simple solution which allows the same stuff which is
As I see it, folks that are used to cmake/ccmake tend to want
cmake-gui
to work more like that. Whereas folks that are used to doing
everything
from GUI's and hardly if ever touch a command line want it to work
like
we're suggesting. Both points of view are IMO valid (though I tend
towards
On 2013-11-05 17:40, David Cole wrote:
I would simply like to point out, with all due respect, that in the
non-CLI use case, it is IMPOSSIBLE to pass command line parameters.
1. I can modify my shortcut / .desktop file (which I previously stated
as a use case for the feature).
2. I can
On Nov 5, 2013, at 6:40 PM, Matthew Woehlke matthew.woeh...@kitware.com
wrote:
On 2013-11-05 17:40, David Cole wrote:
I would simply like to point out, with all due respect, that in the
non-CLI use case, it is IMPOSSIBLE to pass command line parameters.
1. I can modify my shortcut /
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
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
16 matches
Mail list logo
