ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerald Reno <gren...@yahoo.com>
Subject Re: Wildcarding targets and current target access
Date Sat, 20 Apr 2002 19:19:41 GMT
I recently open Bug 8084 to request an enhancement to
Ant that would allow for the following:

1. The ability for targets to take a comma separated
list of patterns.
2. The ability to access the current target name such
as ${ant.target.name}.

I would like to see this enhancement get into Ant 2.0
as it would add a great deal of power to Ant and be
particularly useful for enterprise level build systems
that often have layers of build files.  Some large
projects have as many as 40 makefiles to build the
system.  If Ant is ever needed to replace make it must
have the ability to function in these large
multi-level build environments.

I have been discussing this enhancement in bug 8084
with Steve Loughran and he suggested that I bring it
to the ant-dev list.  Steve mentioned that Ant needs
to build a static dependency graph.  Nothing about
wildcarding would prevent you from doing this.  Before
you build the graph, you just need to expand the
wildcards and then build your graph.  The wildcards
can only represent already existing defined target
names.  Gather these together and then compare the
wildcards against the list and create a new final
target/dependency list.  Of course this assumes that
every call to ant or antcall is producing its own
separate dependency graph.  The only problem I see is
that you have to allow for a target to have multiple
definitions.  In other words, <target name="test">...
and <target name="te*">... would both define task
areas for the incoming target named "test".  So each
target can actually have an array of task areas with
their own dependencies.  Yes, I'm sure this is more
complex than the current arrangement but it is
certainly doable and would add a great deal of power
to Ant.  I believe that Ant's current mechanism can be
expanded to accomplish this.  At the very least I
think this is worth some exploration.

  As far as the request for access to current target
name.  Of course this is mainly useful only if the
above is implemented.  It would require dynamic
construction of the property but again I feel it would
certainly be doable.

  Steve responded in the bug that some people felt
wildcarding was too difficult and permitted 'wild
scripting things'.  I disagree.  I can easily do the
type of things that I'm requesting for ant with make. 
I would at least expect as much flexibility with ant. 
Right now, if you add a target to a sub build then you
have to move up the heirarchy and place it in the
higher level build file also.  I also need to be able
to have all targets go through a catchall type target.
 We need to be able to do this list/pattern matching
thing.  In make I can use things like '$$@' to
reference the current target.  I should be able to do
a similar thing with ant.  I can also wildcard match
targets.  I can also have targets go through multiple
target stanzas. I really don't buy the 'wild scripting
things' argument.  We've been doing these types of
thing with make for eons without any problem.

  The net result of these enhancements would be to
provide for the following constructions in multi-level
builds:

  <target name="*">
   <dosomeglobalstuff then pass it along to sublevel
build>
   <ant dir="subdir" target="${ant.target.name}"/>
  </target>
or
  <target name="install*, deploy*">
   <dosomespecificstuff then pass it along to sublevel
build>
   <ant dir="subdir" target="${ant.target.name}"/>
  </target>

This way you can selectively pass targets down the
chain without the need to explicitly declare them in
the build files higher in the chain.

---





__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message