On 8/10/07, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
> >
> >
> > It might be reasonable, however, to show OPTIONS resolved at the
> > current scope. And to note whether conditional options exist, i.e.
> > "Warning: conditional options detected. You are advised to run
> >
Brandon Van Every wrote:
It might be reasonable, however, to show OPTIONS resolved at the
current scope. And to note whether conditional options exist, i.e.
"Warning: conditional options detected. You are advised to run
(CMakeSetup|CCMake) and resolve them iteravely." Or the opposite:
"All o
On 8/10/07, Eric Noulard <[EMAIL PROTECTED]> wrote:
>
> I think I perfectly understand your point but I would
> say that adding "pre-parsing" phase where
> The main CMakeLists.txt "pre-parsed" in order to list
> the OPTION and their desc statement would indeed be feasible
>
> cmake -p would show IN
On 8/10/07, Eric Noulard <[EMAIL PROTECTED]> wrote:
>
> I think there is a confusion here.
>./configure does not give you "full help" unless the writer
>of the configure scripts did it using --enable-xx or --with-xxx.
>I may well write ugly configure.
Eric Noulard wrote:
2007/8/10, Bill Hoffman <[EMAIL PROTECTED]>:
The process for configuring a cmake project has to be iterative because
options can
be nested inside if statements. ccmake, cmake -i and CMakeSetup all do
the following:
1. Configure
2. Write CMakeCache.txt
3. Did the CMakeCa
2007/8/10, Bill Hoffman <[EMAIL PROTECTED]>:
>
> The process for configuring a cmake project has to be iterative because
> options can
> be nested inside if statements. ccmake, cmake -i and CMakeSetup all do
> the following:
>
> 1. Configure
> 2. Write CMakeCache.txt
> 3. Did the CMakeCache.txt c
. (lots of stuff).
Since CMake is a language that is parsed when cmake is run, there is no
way to present the user
with all possible options until you run cmake. Options can be included
inside an if statement.
This is actually a good thing. For example, if the user enables
VTK_PARAL
2007/8/10, gga <[EMAIL PROTECTED]>:
> Brandon Van Every wrote:
> > On 8/8/07, gga <[EMAIL PROTECTED]> wrote:
> >> I know I can pass -D symbols to cmake to modify its behavior and that
> >> windows also has its ugly CmakeSetup gui.
> >
> > "Ugly?" Geez, what are you, a candidate for Windows Aero or
Brandon Van Every wrote:
> On 8/8/07, gga <[EMAIL PROTECTED]> wrote:
>> I know I can pass -D symbols to cmake to modify its behavior and that
>> windows also has its ugly CmakeSetup gui.
>
> "Ugly?" Geez, what are you, a candidate for Windows Aero or something?
>
No, I am a candidate for someth
Alexander Neundorf wrote:
On Thursday 09 August 2007 13:52, Brandon Van Every wrote:
On 8/9/07, Olivier Delannoy <[EMAIL PROTECTED]> wrote:
Instead of adding a new series of option to the cmake tool, why not
adding a convenient script generated based on the content of
CMakeLists files t
On Thursday 09 August 2007 13:52, Brandon Van Every wrote:
> On 8/9/07, Olivier Delannoy <[EMAIL PROTECTED]> wrote:
> > Instead of adding a new series of option to the cmake tool, why not
> > adding a convenient script generated based on the content of
> > CMakeLists files that is called configure
On 8/9/07, Olivier Delannoy <[EMAIL PROTECTED]> wrote:
> Instead of adding a new series of option to the cmake tool, why not
> adding a convenient script generated based on the content of
> CMakeLists files that is called configure and follow the autoconf way
> of things. This can be a macro which
Instead of adding a new series of option to the cmake tool, why not
adding a convenient script generated based on the content of
CMakeLists files that is called configure and follow the autoconf way
of things. This can be a macro which is used when CPack is used or
something like that.
On 8/9/07,
On 8/8/07, Philip Lowman <[EMAIL PROTECTED]> wrote:
>
> I don't know where -DUSE_FOO or -D USE_FOO came from, it doesn't appear
> to be legal in 2.4.6.
Oops. Guess I haven't done enough of these to remember how I did them.
> The fact that people don't even know the proper way to define variables
Andreas Pakulat wrote:
>> The fact that people don't even know the proper way to define variables
>> at the command line (myself included) should be proof positive that
>> CMake could use some improvement when operating in command line mode.
>
> Or that people should start reading documentations ;
On Wednesday 08 August 2007 13:05, Andreas Pakulat wrote:
> On 08.08.07 12:46:56, Philip Lowman wrote:
...
> > Actually, it's more like this:
> >
> > cmake -D USE_FOO=BOOL:ON .
> > or
> > cmake -D USE_FOO=BOOL:OFF .
>
> Not quite, the BOOL: is not needed.
It depends.
If you want it to go in the ca
On 08.08.07 12:46:56, Philip Lowman wrote:
> Brandon Van Every wrote:
> > On 8/8/07, Philip Lowman <[EMAIL PROTECTED]> wrote:
> >> I love CMake, but there have been times when I wished that
> >>
> >> --enable-foo would simply be a shortcut to set a boolean variable
> >> ENABLE_FOO to true.
> >
> >
Brandon Van Every wrote:
> On 8/8/07, Philip Lowman <[EMAIL PROTECTED]> wrote:
>> I love CMake, but there have been times when I wished that
>>
>> --enable-foo would simply be a shortcut to set a boolean variable
>> ENABLE_FOO to true.
>
> Some would say that's not nice because you don't get exact
On 8/8/07, Philip Lowman <[EMAIL PROTECTED]> wrote:
>
> In defense of the original post,
>
> --enable-foo is much more readable than -DENABLE_FOO or -DUSE_FOO.
No it isn't, and it's not much of a defense. "Slightly more readable"
I'd accept. Let's refrain from religious hyperbole when contemplat
On 8/8/07, gga <[EMAIL PROTECTED]> wrote:
>
> I know I can pass -D symbols to cmake to modify its behavior and that
> windows also has its ugly CmakeSetup gui.
"Ugly?" Geez, what are you, a candidate for Windows Aero or something?
Cheers,
Brandon Van Every
___
2007/8/8, Philip Lowman <[EMAIL PROTECTED]>:
> Eric Noulard wrote:
> >> However, neither approach seems to me as clean as what's available under
> >> autotools.
> >
> > I personnally think the OPTION CMake macro is just as good
> > as AC_ARG_ENABLE is.
>
> Almost. Automake has a neat feature the o
On Wednesday 08 August 2007 10:19, Philip Lowman wrote:
> Eric Noulard wrote:
> > 2007/8/8, gga <[EMAIL PROTECTED]>:
> >> I'm currently using cmake for a variety of projects. Love it.
> >> However, one feature I find myself missing more and more is one from
> >> autotools configure scripts: AC_ARG
On 8/8/07, Philip Lowman <[EMAIL PROTECTED]> wrote:
> Eric Noulard wrote:
...
>
> --enable-foo is much more readable than -DENABLE_FOO or -DUSE_FOO.
> Having implemented USE_FOO arguments for every single one of our
> optional dependencies and looked at them on a CMake command line I can
> attest t
Eric Noulard wrote:
> 2007/8/8, gga <[EMAIL PROTECTED]>:
>> I'm currently using cmake for a variety of projects. Love it.
>> However, one feature I find myself missing more and more is one from
>> autotools configure scripts: AC_ARG_ENABLE().
>> That is, the ability to allow the configuration scri
2007/8/8, gga <[EMAIL PROTECTED]>:
> I'm currently using cmake for a variety of projects. Love it.
> However, one feature I find myself missing more and more is one from
> autotools configure scripts: AC_ARG_ENABLE().
> That is, the ability to allow the configuration script (ie. cmake) to be
> run
I'm currently using cmake for a variety of projects. Love it.
However, one feature I find myself missing more and more is one from
autotools configure scripts: AC_ARG_ENABLE().
That is, the ability to allow the configuration script (ie. cmake) to be
run with arbitrary flags to turn on or turn off
26 matches
Mail list logo
