On Fri, 2005-05-13 at 09:00 +0200, Stefan Bodewig wrote:
> > But say the importER explicitly depends on bar.foo . Isn't this
> > still going to pollute the log in the opposite way my implementation
> > would? :) i.e.
> >
> > [foo]:
> >
> > [bar.foo]:
>
> Yes. But this is less likely than having the importer depend on "foo"
> IMHO. So in the normal case everything would look the same as today
> and in border cases we'll get an additional empty target.
If I understand what you're saying correctly, you don't expect importer
build scripts to depend explicitly on the renamed imported targets. I'd
disagree: we commonly "augment" the standard targets like this:
standard.xml:
<project name="standard">
<target name="compile">...</target>
</project>
build.xml:
<project name="my-build" basedir="." default="compile">
<import file="${standard.dir}/standard.xml"/>
<target name="compile" depends="standard.compile">...</target>
</project>
I'm not sure if this is what you're discussing or not. What I can say is
that the output of targets and tasks used in our build scripts is very
unclear.
We generally find it difficult tell actually which target caused a given
dependency target to be executed because there are too many "empty"
target names being output (we have various targets that operate "if" and
"unless" variants, but the target name is output even if the condition
fails). In addition, the same "standard" targets are executed multiple
times during our build in different contexts since we have the concept
of "subsystems" within our build:
main-dir/build.xml "ant" executes:
main-dir/subsystem-one/build.xml
main-dir/subsystem-two/build.xml
main-dir/subsystem-.../build.xml
from within targets that have dependencies between each other that
describe subsystem dependencies. Each subsystem build.xml imports the
standard targets and executes them in its context.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
