ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Should <import> cause an error when used inside a <target>?
Date Thu, 18 Sep 2003 12:41:41 GMT
> From: Nicola Ken Barozzi [] 
> Stefan Bodewig wrote:
> > On Thu, 18 Sep 2003, Jose Alberto Fernandez 
> > <> wrote:
> > 
> > 
> >>First, <import/> makes absolute no sense to me inside a 
> <target>. The 
> >>whole point of import was allowing for target-overriding. I could 
> >>understand having an <include/> in there, because is textually 
> >>expanding the file in place, which may make sense.
> > 
> > There is no <include>, only <import> which does both.  I've already

> > voiced my preference for a "pure" <include> task.
> Stefan, IIRC there was consensus that we should add an extra include 
> task to only substitute entity includes. This to make it possible for 
> use cases like yours to work without worrying about the import 
> overriding capabilities.

I wonder if we really want to go into this world of dynamic-programming,
where the buildfile constructs itself conditionally in the middle of its

execution. Until now, by the time one "starts" executing dependencies
on the buildfile (notice I am leaving out top-level tasks) the target
code is final and fixed.

With this <import> (or <include>) inside targets, that is no longer
If I execute the same task twice I may get different definition of the
because each time the import may be returning something different.

I may argue that probably the need presented by the usecase, can be
in a different way, just as well. I have a bad feeling at adding this
feature without thinking on all the consequences. (You know how users
give them an inch and they will use the whole yard) :-)

Jose Alberto

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message