Return-Path: <szinn@patronix.com>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 45485 invoked from network); 12 Oct 2000 22:11:20 -0000
Received: from cr102266-a.ktchnr1.on.wave.home.com (HELO gateway.patronix.com)
 (qmailr@24.114.144.198)
  by locus.apache.org with SMTP; 12 Oct 2000 22:11:20 -0000
Received: (qmail 8412 invoked from network); 12 Oct 2000 22:09:05 -0000
Received: from unknown (HELO mocha) (192.168.0.129)
  by 192.168.0.100 with SMTP; 12 Oct 2000 22:09:05 -0000
From: "Scotte Zinn" <szinn@patronix.com>
To: <ant-dev@jakarta.apache.org>
Subject: RE: [PATCH] New <case> task
Date: Thu, 12 Oct 2000 18:11:41 -0400
Message-ID: <004a01c03499$66da5840$0100000a@patronix.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <20001012123001.20623.qmail@web117.yahoomail.com>
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

> -----Original Message-----
> From: Diane Holt [mailto:holtdl@yahoo.com]
> Sent: Thursday, October 12, 2000 8:30 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: [PATCH] New <case> task
>
>
>
> As for the whole "scripting" thing...
>
> Personally, I find the limitation imposed on the if/unless to
> only that of
> set/not-set rather than also being able to test for value,
> just to try and
> keep Ant from having a "scripting" capability, rather odd.
> Testing whether
> something is set or not-set is still "scripting" -- you're still
> determining what will and won't be done, based on some criteria. Yes,
> there are all kinds of ways to work around this limitation,
> but they all
> get cumbersome and, I find, make the whole process far more
> complicated
> than it really needs to be. I would love to be able to do
> something like:
>   <property name="out.dir" value="${debug.dir}" if="sane=true"/>
>   <property name="out.dir" value="${release.dir}" if="sane=false"/>

I was thinking of a similar extension to property:

<property name="out.dir" value="${debug.dir}" if="sane" hasValue="true"/>
<property name="out.dir" value="${release.dir}" unless="sane"
hasValue="true"/>

> It's clean, it's concise, it's human-readable. As things stand now,

I agree.  This is much nicer than having to have a bunch of targets and
wrapper scripts.

> though, I need to do all of that sort of thing over in the ant
> wrapper-script. My ant wrapper-script is already far larger and more
> complicated than I originally thought it would ever need to
> be. And if I
> needed this all to work under something other than a
> Unix-type shell, I'd
> have to have duplicate scripts that talked that shell's
> language -- which
> could turn into a maintenance nightmare, and which severely
> detracts from
> the "platform independence" that Ant is supposed to provide.
> That quote
> you cited from the Ant document goes on to talk about how
> "make", et.al.
> depend on the OS's shell commands to do their work, and Ant
> doesn't -- but
> if a huge amount of the build system's work is being done in
> wrapper-scripts, then in the end, it's not really that different from
> having shell commands in the actions the build tool itself
> takes. I also
> know I'm going to run up against situations (I'm starting in
> on several of
> them now) where even the wrapper-script won't be usable, so I can see
> myself having to have bunches of extra "targets" that aren't
> really doing
> anything except trying to get around this limitation -- or,
> have targets
> that use <script> and try and do it all that way, which just ends up
> making the build-file have these big complicated targets in
> it, and which
> will require whoever ends up maintaining it know whatever
> language(s) I
> used in the <script> task(s) (and try and figure out what in
> the heck I
> was doing, and how I was doing it).
>
> Diane
>
> =====
> (holtdl@yahoo.com)
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
>