On Dec 18, 2007 10:02 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote:
>
> What about doing the opposite of what Alex' patch did? What about
> making Y, YES, 1, ON synonyms? It's more or less what Brandon proposed
> but without introducing a BOOL(variable bool_value) command.
That's the exact op
On Tuesday 18 December 2007, Bill Hoffman wrote:
> > Attached is a patch which removes "Y" and "N" from the recognized values
> > for true/false.
> > This patch may break stuff. I don't know if there are many people who
> > rely on "N" and "Y".
>
> I am sure it will break something I don't thi
On Dec 18, 2007 11:14 AM, Mike Jackson wrote:
> On Dec 18, 2007, at 10:07 AM, James Bigler wrote:
> > On Dec 18, 2007, at 7:48 AM, Bill Hoffman wrote:
> >> James Bigler wrote:
> >>
> >>> I also agree that trying to maintain backwards compatibility to
> >>> the detriment of the future can become a h
On Dec 18, 2007, at 10:07 AM, James Bigler wrote:
On Dec 18, 2007, at 7:48 AM, Bill Hoffman wrote:
James Bigler wrote:
I also agree that trying to maintain backwards compatibility to
the detriment of the future can become a hinderance. I just had
a collegue who was extreemly frustrated
On Dec 18, 2007, at 7:48 AM, Bill Hoffman wrote:
James Bigler wrote:
I also agree that trying to maintain backwards compatibility to
the detriment of the future can become a hinderance. I just had a
collegue who was extreemly frustrated for several hours with why
his build didn't work, o
Quoting Bill Hoffman <[EMAIL PROTECTED]>:
Mike Jackson wrote:
I might kindly disagree. There are many instances where backward
compatibility was broken in order to clean things up and move on.
Vtk 4.x to 5.x was one of those. My code broke with the 5.x release
BUT it was for the better.
James Bigler wrote:
I also agree that trying to maintain backwards compatibility to the
detriment of the future can become a hinderance. I just had a collegue
who was extreemly frustrated for several hours with why his build didn't
work, only to discover that he should have been using ADD_S
Mike Jackson wrote:
I might kindly disagree. There are many instances where backward
compatibility was broken in order to clean things up and move on.
Vtk 4.x to 5.x was one of those. My code broke with the 5.x release BUT
it was for the better. And more importantly I was given plenty of noti
Alexander Neundorf wrote:
On Monday 17 December 2007, Brandon Van Every wrote:
I propose the addition of a BOOL type to the CMake language.
bool(variable [value])
would declare a variable of type BOOL, with an optional value
supplied. Any SET commands performed on the variable in its scope
On Dec 18, 2007, at 9:16 AM, Bill Hoffman wrote:
Alexander Neundorf wrote:
On Monday 17 December 2007, Brandon Van Every wrote:
I propose the addition of a BOOL type to the CMake language.
bool(variable [value])
would declare a variable of type BOOL, with an optional value
supplied. Any
Alexander Neundorf wrote:
On Monday 17 December 2007, Brandon Van Every wrote:
I propose the addition of a BOOL type to the CMake language.
bool(variable [value])
would declare a variable of type BOOL, with an optional value
supplied. Any SET commands performed on the variable in its scope
On Monday 17 December 2007, Brandon Van Every wrote:
> I propose the addition of a BOOL type to the CMake language.
>
> bool(variable [value])
>
> would declare a variable of type BOOL, with an optional value
> supplied. Any SET commands performed on the variable in its scope
> would be subject
On Monday 17 December 2007, Brandon Van Every wrote:
> On Dec 17, 2007 2:19 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> > To supplement Brandon's Boolean wishlist, I would like to see some way to
> > specify a non-default precedence of Boolean operators. Most languages
> > use parentheses for t
On Dec 17, 2007 2:19 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote:
> To supplement Brandon's Boolean wishlist, I would like to see some way to
> specify a non-default precedence of Boolean operators. Most languages use
> parentheses for this, and ideally that would be true for CMake as well.
>
> Pe
To supplement Brandon's Boolean wishlist, I would like to see some way to
specify a non-default precedence of Boolean operators. Most languages use
parentheses for this, and ideally that would be true for CMake as well.
Then a test of Boolean inequality of A and B would be
IF((A AND NOT B) OR (N
I propose the addition of a BOOL type to the CMake language.
bool(variable [value])
would declare a variable of type BOOL, with an optional value
supplied. Any SET commands performed on the variable in its scope
would be subject to boolean type constraint. A BOOL can take on the
following val
16 matches
Mail list logo
