ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gle...@ca.ibm.com
Subject Re: A question about "available" and doing conditionals in a build xml file.
Date Wed, 17 May 2000 21:39:20 GMT




FYI, I only created the ifdef and ifnotdef tasks so I wouldn't have to keep
patching the Target class for every release of ant.  I come from a Windows
background of using comercial libraries (except for my time in university,
anyway).

The problem with using "unless" is that it implies that the property in
question must be set.  So

<target name="blah" unless="unless.property">
  ...
</target>

only works if you have set "unless.property" at some point.  How do I set
"couldnt.find.generated" (from discussion below) with available?  Can't do
it currently, as available only tests for positives, not negatives.

Personally, I'd like an ifnot attribute in the Target class that was
mutually exclusive to if.  It gets around having to have these ifdef and
ifnotdef tasks, which does let you deal with negatives, but its not very
clean.  To set two properties relative to another, you need to do something
like

<ifdef prop="some.property" set="ok" unset="reject" />
<ifnotdef prop="some.property" unset="ok" set="reject" />

Not very tidy, but it does work.  Mariusz, you proposed below to replace
the "prop" attribute with "test," and "set" with "property."  Ok so far,
but what do you do with "unset"?  If you have a series of conditional Tasks
that depend on these values (for example, I have an Excho_ex task that has
an if attribute to only write the message if the property exists), you have
to be able to remove property values.

At any rate, I'd be happy to do the "ifnot" patch for Target if anyone
wants it.

Glenn McAllister
TID - Software Developer - VisualAge for Java
IBM Toronto Lab, (416) 448-3805
"An approximate answer to the right question is better than the
right answer to the wrong question." - John W. Tukey


Well, I am also pretty new to the issue with conditional tasks, but
if Ant allows to have targets with "if", there is really no big
difference to allow targets with "ifnot" or "unless". That would make the
example below given by Glenn much simpler and shorter (and it would mean
no need for ifdef and ifnotdef tasks).

I also like the idea of available + ifdef + ifnotdef `tasks (if we can
have
only if in targets).

Would it be possible for those three tasks to have the same way for
setting a property?  In proposed by Glenn solution attribute
"property" means two different things in "available" and "if*def" tasks,
which can be confusing. Maybe:
<available file="some_well_known_file" property="a.property"/>
...
<ifnotdef test="a.property" property="another.property"/>
<ifdef test="a.property" property="another.property"/>

Mariusz


-----------
Glenn wrote:

> There is a pretty easy way around your problem if you are willing to
create
> more targets in your build, use a custom task, and use the "if" attribute
> of the target.
>
> Try something like the following:
>
> <target name="compile_src"
> depends="check_idl2java,do_idl2java,do_java_compile">
>   <!-- dummy target used to control the order of execution -->
> </target>
>
> <target name="check_idl2java">
>   <available file="some_well_known_file" property="found.generated"/>
>   <ifnotdef property="found.generated" set="couldnt.find.generated"/>
> </target>
>
> <target name="do_idl2java" if="couldnt.find.generated"
> depends="check_idl2java">
>   <!-- do your idl to java compilation --->
> </target>
>
> <target name="do_java_compile" depends="do_idl2java">
>   <!-- yadda yadda yadda -->
> </target>
>
> The ifnotdef task simply checks at execute and init time if the property
> specified by the "property" attribute exists.  If it does, it sets the
> property specified by the "set" attribute to "true", or to a specified
> value if there is an = in the text.  There is also an "unset" attribute
you
> can use to remove a property.  I have a corresponding ifdef task that
does
> the logical opposite.
>
> Here's the code for the ifnotdef task.  I've moved it from our
> com.ibm.id.tools.ant.taskdefs package to the
> org.apache.tools.ant.taskdefs.optional to make incorporating it a little
> easier for you.  Sorry for the poor indenting, but VisualAge for Java
> doesn't do the best job of exporting code from its repository to a file.
> :-(

[....]

>
> Glenn McAllister
> TID - Software Developer - VisualAge for Java
> IBM Toronto Lab, (416) 448-3805
> "An approximate answer to the right question is better than the
> right answer to the wrong question." - John W. Tukey
>





Mime
View raw message