So ...
> if(cond1)
>block of statements
> elseif(cond2)
>block of statements
> elseif(cond3)
>block of statements
>
> ...
>
> elseif(condn)
>block of statements
> else(cond1)
>block of statements
> endif(cond1)
And with LOOSE set
> if(cond1)
>block of statements
> elsei
On 9/16/06, Filipe Sousa <[EMAIL PROTECTED]> wrote:
Not anymore. You can doSET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS 1)IF(cond1)ELSE()ENDIF()Wow, I never knew about that option.I think adding adding an ELSEIF extension should not be a high priority, since the same thing can be accomplished with existin
David C Thompson wrote:
What if you named the construct something other than ELSEIF? For
instance:
ONEOF( LABEL )
CONDITION( cond_1 )
statements here if cond_1 is true
OR_CONDITION( cond_2 )
statements here if cond_1 is false and cond_2 is true
... (more OR_CONDITION st
Alan W. Irwin wrote:
On 2006-09-17 20:27-0700 Brandon J. Van Every wrote:
... some rhetorical questions trying to convince me (and I guess
others) that I should not use CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS.
I just don't think you value the social build engineering aspects of
this particular lang
On 2006-09-18 15:33-0700 David C Thompson wrote:
What if you named the construct something other than ELSEIF? For
instance:
ONEOF( LABEL )
CONDITION( cond_1 )
statements here if cond_1 is true
OR_CONDITION( cond_2 )
statements here if cond_1 is false and cond_2 is true
... (
Brad King wrote:
> Alan W. Irwin wrote:
> > So far all but one of those who responded to the discussion are in support
> > of the idea, but it is also fair to say that only a handful of subscribers
> > to this list have responded yet.
> >
> > I am particularly interested in the opinion of Bill Hof
On 2006-09-18 10:24-0400 Brad King wrote:
This is a reasonable request. I'll have to discuss it with the other
developers but it is at least worth putting in the bug tracker. Please
put in the request. At least then the final discussion will be
documented in an easy-to-reference place.
I am
Alan W. Irwin wrote:
> So far all but one of those who responded to the discussion are in support
> of the idea, but it is also fair to say that only a handful of subscribers
> to this list have responded yet.
>
> I am particularly interested in the opinion of Bill Hoffman, Brad King, and
> other
principal topic which is whether "elseif" should be
implemented for CMake or not.
I'd like to vote in favour of an ELSEIF construct
JB
--
John Biddiscombe,email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre | Tel
On 2006-09-17 20:27-0700 Brandon J. Van Every wrote:
... some rhetorical questions trying to convince me (and I guess
others) that I should not use CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS.
Regardless of such argumentation, the basic point remains,
CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS is already in the CM
Alan W. Irwin wrote:
Agreed. I wish I had known about that CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS
variable before the CMake build system was completed for PLplot. It
would
have made my life a whole lot easier.
"A whole lot" easier? Just how many nested IF..ELSE..ENDIF statements
does your co
Philip Lowman wrote:
Requiring the user to specify "else(cond1)" and "endif(cond1)" may
prevent a few mistakes but it also gets kinda annoying as conditionals
get longer or change.
Agreed on being annoying as things get longer. It's a tradeoff between
safety and brevity.
It's *SUPPOSED* to
On 2006-09-17 17:47-0700 Philip Lowman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Sep 16, 2006 at 01:39:57PM -0700, Alan W. Irwin wrote:
if(cond1)
block of statements
elseif(cond2)
block of statements
elseif(condn)
block of statements
else(cond1)
block of statement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Sep 16, 2006 at 01:39:57PM -0700, Alan W. Irwin wrote:
> if(cond1)
> block of statements
> elseif(cond2)
> block of statements
> elseif(condn)
> block of statements
> else(cond1)
> block of statements
> endif(cond1)
>
> original propo
On Sat, 2006-09-16 at 13:39 -0700, Alan W. Irwin wrote:
> To my mind those additional endelseif statements in this alternative
> proposal go against the whole reason for my first proposal which is to
> reduce the clutter that occurs in the equivalent existing form now present
> in the language. Als
Alan W. Irwin wrote:
On 2006-09-16 12:11-0700 Brandon J. Van Every wrote:
It is the CMake language style to force the user to bracket their
conditional with matching conditions. Personally I think this is a
good design choice, especially as conditionals are nested deeper and
deeper, as it do
Alan W. Irwin wrote:
> To my mind those additional endelseif statements in this alternative
> proposal go against the whole reason for my first proposal which is to
> reduce the clutter that occurs in the equivalent existing form now present
> in the language. Also, demanding those extra endelseif
Brandon J. Van Every wrote:
> Alan W. Irwin wrote:
>
> You can make a feature request with http://www.cmake.org/Bug/
>
>
> The bug tracker, which contains the feature requests, is also searchable.
>
> I do not agree that it's an obvious extension to the CMake language. If
> elseif is introduc
My proposal was
if(cond1)
block of statements
elseif(cond2)
block of statements
elseif(cond3)
block of statements
...
elseif(condn)
block of statements
else(cond1)
block of statements
endif(cond1)
I should have clarified that proposal was to replace the the following
equivalent that
Alan W. Irwin wrote:
I would like to request an elseif extension to the cmake language.
You can make a feature request with http://www.cmake.org/Bug/
if(cond1)
block of statements
elseif(cond2)
block of statements
elseif(cond3)
block of statements
...
elseif(condn)
block of statem
20 matches
Mail list logo
