ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject RE: OS detection: am I missing the obvious?
Date Thu, 09 Nov 2000 03:38:24 GMT
> From: Peter Donald []
> At 05:12  8/11/00 -0800, you wrote:
> >--- Diane Holt <> wrote:
> >> 
> >> I'm not trying to re-open this debate, honestly, but
> >> I just have to say
> >> that I find it interesting that you think heading
> >> towards something like
> >> "configure" is desirable, just to avoid having a
> >> test-for-value.
> >

Diane, see what you did, you make me get into this again :-(

> >That being said, adding an equality operator is: 1)
> >powerful, 2) simple to implement 3) clearly
> >understandable 4) maintainable. It is certainly less
> >hairy than scripting.
> But if we are going to have equality we may as well have 
> innequality. And
> if wee have inequality we may aswell have negation and 
> perhaps conjunction
> and then disjunction, perhaps relational operators aswell - 
> then of course
> we see the need for approximation, containment, and the full regular
> expression suite ;)
> We end up with  if="(A || !B) && (C~D || D^(E:F)) == !(A || 
> Z)" and that is
> less than simple and completely unmaintainable.

As I showed in a previous message, you can already, TODAY,
do conjunction, disjunction and negation based on property existance.
The expressive power is there already.

Actually, if you know the possible values that a property can have
you are able to test for them as follows:

 <property name="prop.${prop}" value="true" />

assumming the possible values for "prop" are "a", "b", "c"; you
can now do:

  <target .... if="prop.a" />
  <target .... if="prop.b" />
  <target .... if="prop.c" />

the only thing you cannot do is compare two properties which may be useful
if the property values may be complicated.

  <target .... if="prop=${otherprop}" />

So, except for this last feature (which you cannot do because ifs attributes
are not expanded), it is possible to do all this things the "purist" are
afraid of.
So, the argument for equality checking is more one for easy notation than
anything else.

> Configure with respect to ant will be deciding if various 
> facilities are
> available (ie java1.1/java1.2/java1.3) or particular archives (ie
> servlet.jar/ejb.jar/etc) and possibly other configurable 
> properties (like
> install directory). I hope that all of these will be placed into a
> properties file which ant can read in and run with.

This is exactly what <available> is doing today. I see no reason for
having yet another generator just for this.

BTW, those of you using my PATCH for theif with equality. 
If you would prefer not needing to patch the sources, you can use the <case>
task I posted some time ago. Just compile it, put it in a jar in ant/lib and
declare it with a <taskdef> in your build and you can achieve the same thing

without the need to alter ANT sources.

That task may have not made it into the distribution, but it works just
You may want to put it in a different package or file location.

Jose Alberto

View raw message