So, just to get clarification -
You are ok with <available> (and other such tasks that currently overwrite
properties) unsetting properties if the condition fails?
That is my preference simply because it makes sense. If overriding a
property is necessary, the -D switch will do it so only builds that were
relying on strange effects would be breaking, I think. Or ones that relied
on the existence of a property even after a failed <available>.
What backwards compatibility issues will we have? Are the other committers
on board with this change? I don't want to go to the effort of patching
these things if its not an acceptable change. I'm not sure when/if I'll get
around to patching it, but this seems like an important issue.
Thanks,
Erik
----- Original Message -----
From: "Stefan Bodewig" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 26, 2001 9:01 AM
Subject: Re: <available> / <condition> breaking immutability
> On Sun, 25 Nov 2001, Erik Hatcher <[EMAIL PROTECTED]>
> wrote:
>
> > why does <available> and <condition> (and <uptodate>, <tstamp>, and
> > some others) break non-user property immutability? Is this
> > inadvertent or intentional?
>
> inadvertent AFAIK.
>
> > I'm (mostly?) of the opinion that <available> and such tasks that
> > set a property based on some condition should force the
> > setting/unsetting of the specified non-user property.
>
> I can follow you here - of course this would be breaking backwards
> compatibilty (sigh), but I'd consider builds that relied on
> <available> not doing what it is supposed to do broken.
>
> Stefan
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
