> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] > > Stefan Bodewig wrote: > > On Thu, 18 Sep 2003, Jose Alberto Fernandez > > <[EMAIL PROTECTED]> 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 true. If I execute the same task twice I may get different definition of the target because each time the import may be returning something different. I may argue that probably the need presented by the usecase, can be fullfil in a different way, just as well. I have a bad feeling at adding this dynamic-programming feature without thinking on all the consequences. (You know how users are give them an inch and they will use the whole yard) :-) Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
