Return-Path: 
 <ant-user-return-12935-apmail-jakarta-ant-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org
Received: (qmail 75698 invoked by uid 500); 26 Sep 2001 05:46:19 -0000
Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:ant-user@jakarta.apache.org>
List-Help: <mailto:ant-user-help@jakarta.apache.org>
List-Unsubscribe: <mailto:ant-user-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-user-subscribe@jakarta.apache.org>
Reply-To: ant-user@jakarta.apache.org
Delivered-To: mailing list ant-user@jakarta.apache.org
Received: (qmail 75689 invoked from network); 26 Sep 2001 05:46:19 -0000
Date: Tue, 25 Sep 2001 22:47:52 -0700
From: "Frank E. Weiss" <frankw@well.com>
Subject: Re: suggestions
To: ant-user@jakarta.apache.org
Message-id: <3BB16C08.36772148@well.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <A5EC347F51CFD411A47200508B68543C8E280B@ukexch001.digitalrum.net>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

The reason ant is so intriguing (to me) is because sometimes it almost seems to
be wanting to be prolog. This is not such a stretch. Consider if/unless to be
guarded clauses, or targets. Consider the depends mechanism a form of functional
programming, whereby a computation is done inside-out. Is lazy evaluation in
there somewhere, too?

But seriously, this leads to another idea, conditional depends. For  example
(with a change of depends from an attribute of the target to a child of the
target, which is actually better XML, IMHO):

<target name="mytarget">
    <depends target="do-if-foo" if="${my-var-is-foo}"/>
    <depends target="do-if-bar" if="${my-var-is-bar}"/>
</target>

For those wanting to criticize this form as not providing an ordering for
depends, I offer that XML has a concept of document order of nodes.

This also allows for using an if construct when building the dependencies,
thereby being able to prune a whole subtree of dependant targets.

I'd also ask the developers to consider real if expressions. Can't ant leverage
the XPath expression parser from Xalan?

P.S. Currently, the depends attribute always implies an AND. For example:

<target name="foo" depends="bar,mung"/>

means foo depends on bar AND mung. It seems like many users are also looking for
an OR form of depends. Like: "foo depends on (bar if property do-bar) OR (mung
if property do-mung)".

Mike Roberts wrote:

> Just come across this if-evaluation problem today. A complete hack I came up
> with is:
>
>     <target name="hack_preparer" if="myvar">
>         <delete dir="touchdir"/>
>         <mkdir dir="touchdir"/>
>         <touch file="touchdir/${myvar}"/>
>
>         <available file="touchdir/foo" property="my_var_is_foo"/>
>         <available file="touchdir/bar" property="my_var_is_bar"/>
>         <delete dir="touchdir"/>
>     </target>
>
>     <target name="do_if_foo" if="my_var_is_foo">
>     </target>
>
>     <target name="do_if_bar" if="my_var_is_bar">
>     </target>
>
>     <target name="mytarget" depends="hack_preparer">
>         <antcall target="do_if_foo"/>
>         <antcall target="do_if_bar"/>
>     </target>
>
> I know that the ant philosophy is that I should use a different property for
> different scenarios. What I actually what conditional
> evaluation for is that I want to check for special cases of a property, and
> otherwise use the property value itself (so, a variant of the above hack)
>
> eg:
>
> - 'build trunk' will build from the single trunk location
> - 'build 1.3' will build branch number 1.3
>
> The only clean solution I can find, while keeping the user skill down, is to
> do more stuff in my ant wrapper script. I don't like this
> though since I'd rather keep all my ant wrapper scripts the same.
>
> Mike
>