ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@wamnet.com>
Subject RE: top level tags in ant vs. "init" task as an attribute of proj ect
Date Wed, 10 Oct 2001 19:02:22 GMT
> >>comiitters don't like notion of "magic" names for tasks.
> >>
> > 
> > ... and I would have been one of them!  Keeping things clear and
> > straightforward should be the defualt, and "magic" names 
> certainly wouldn't
> > provide that.  This is also why I don't like the ability to 
> put things other
> > than targets directly under project -- its not clear at all 
> which tasks are
> > allowed at the top level, and which aren't... until you try.
> > 
> > But I don't think allowing an init target has anything to 
> do with "magic"
> > names...  If the project element allowed an "init" 
> attribute, then the
> > target name wouldn't be magic; at least no more than the 
> default target is.
> > 
> > e.g.
> > 
> > <project name="foo" init="startup" default="all">
> > 
> >   <target name="startup">
> >     <!-- no new magic here... -->
> >   </target>
> > 
> >   <target name="all">
> >     <!-- no current magic here... -->
> >   </target>
> > 
> > </project>
> > 
> > Tim
> > 
> 
> This is better than the original approach that a target named 
> "init" was 
> special. However, it still leaves some open questions
> 
> What if I write
> 
> <target name="startup" depends="all">
> 
> Will "all" be run first or will "startup" or will it fail as 
> a circular 
> dependency? An alternative would be to create an <init> element which 
> functions like a target but which has no depends list.

I see your point. I guess my thought was restricted to just calling <init>
(and all dependencies) prior to calling the first specified (or default)
target.  You wouldn't hit a circular dependency, because the init target
would be a one time launch -- 'all' would just happen to run twice.

> What I originally 
> objected to was behaviour tied to special names. If the 
> behaviour comes 
> from the structure, it isn't really a problem for me, 
> although it could 
> be argued that it makes dependency definition less explicit.

I'm open to that as well, though I'd still prefer my original idea because I
think its more in line with the "default" attribute we have today, as we
don't have a <default> element today for the default target...

My big point is that I'd like to remove the stray top-level tasks, because I
think they're quite unclear.

Tim

Mime
View raw message