ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurdoch...@yahoo.com>
Subject RE: suggestion for if/unless syntax change
Date Fri, 22 Mar 2002 23:50:59 GMT


> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> Sent: Friday, 22 March 2002 6:09 PM
> To: Ant Developers List
> Subject: Re: suggestion for if/unless syntax change
>
>
> From: "Adam Murdoch" <adammurdoch_ml@yahoo.com>
>
> >
> >
> > > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> > >
> > >
> > > So, is there a way to test if a property is set? Is this
> coordinated with
> > > other things like <condition>, <available>, etc?
> > >
> > > All this things need to play toguether, well.
> >
> >
> > Absolutely.  There's a bunch of condition implementations, and
> you can use
> > whichever one you like, or invent your own.  The goal is to allow any
> > condition to be use whereever the standard if/unless conditions
> are.  At the
> > moment, conditions can only be used in a few places:
> <condition>, <waitfor>,
> > <fileset>, and (almost) <if>.  More on the way ...
> >
> > BTW, <available> is just a condition now, rather than a task.
> And it's been
> > split up into <class-available>, <resource-available>,
> <file-exists>, etc.
> >
> >
>
> Humm. I think we are mixing two different things: (1) "if"
> attribute of <target>, <exclude>, etc;
> and (2) <if> task. They are kind of different things, in my opinion.
>
> What I meant by coordinate, was that if the attribute now checks
> for "false", then
> <available> and such should set things to "false" when the
> condition is false.
> They work the way they do in ANT1.x because the "if" attribute
> works the way it does.
>

Ah, I understand now.  Yes, <condition> probably should do something when
the condition is false.  This would be different to the way things work in
ant 1, where <available> and <condition> do nothing when the condition is
false.  For example:

ant -Dsome-prop=true

<condition property="some-prop">
  <some-false-condition/>
</condition>

=> some-prop is 'true'

or

<condition property="some-prop">
  <some-true-condition/>
</condition>

<condition property="some-prop">
  <some-false-condition/>
</condition>

=> some-prop is 'true'

Different isn't necessarily bad, though.


> > >
> > > IMHO, a much more useful thing (instead of changing completely
> > > the meaning of 'if')
> > > is to actually let it check for a particular value. I guess I
> > > wrote such a patch
> > > in ANT 1.1 (or was it 1.0).
> > >
> > >     <target .... if='prop=true'/>
> > >
> > > this is a fully backward compatible and more useful thing to
> have, IMO.
> > >
> >
> > Well, arguably more useful.  This is why we want to get away
> from forcing a
> > particular test, and let the build file writer decide which is
> more useful
> > for them.  on the other hand, we do want to come up with a reasonable
> > default test, to use as shorthand.
> >
>
> Notice I am talking about the "if" attribute, not the <if> task.
> You cannot change
> the implementation of it (I do not think).
>

Sure you can.  You just need to come up with some way to describe which
condition implementation to use.  Something like:

<target>
  <my-homemade-condition someprop="blah"/>
  <task/>
  <task/>
</target>

And make

<target if="someprop">
  ...
</target>

shorthand for

<target>
  <is-set property="someprop"/>
  ...
</target>

In myrmidon, we have done away with the "if" and "unless" attributes for
<target> altogether, now that we have an <if> task.  So now the answer to
the question 'do we test is-set/is-not-set or is-true/is-not-true?' is:  It
doesn't matter - let the build file writer tell us what they want.


Adam


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message