ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject RE: [PATCH] New <case> task
Date Thu, 12 Oct 2000 12:30:01 GMT
--- Scotte Zinn <> wrote:
> the fact that
> properties are executed at parse time, rather than at execute time.

This is no longer true.

> It seems to me that keeping the fact that properties, once set,
> cannot be changed

This is no longer completely true, either.

> having properties be defined at execute time would be a
> powerful addition.

This has already been done.

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"/>
It's clean, it's concise, it's human-readable. As things stand now,
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",
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).



Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!

View raw message