ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject RE: [RESULT] multithrading
Date Thu, 17 May 2001 20:45:23 GMT
--- "Siberski, Wolf" <> wrote:
> > Diane Holt wrote:
> > 1. I don't have a problem with requiring a build-file writer to know
> > what order things should get built in -- if they don't know that,
> > then they shouldn't be writing the build-file :)
> I disagree here. The build file writer must know 
> the preconditions of each build step, but what's
> the reason for letting her find out the order of
> all build steps?

Maybe it's just me, but the first thing I do when I'm reworking some
cruddy broken build system is walk through it by hand so I can find out
what the order really should be. It might not be the approach other people
would take, but since I usually manage a reduction in build-time by a
factor of about 10 (eg., 18 hours down to less than 2, 40 minutes down to
4) and get the thing to build clean in one run, I'll probably stick to it
> If X is a precondition for Y, then add it to the dependencies
> of Y instead of hiding it in the order of other target dependency lists.

I wasn't suggesting that anything be hidden. Yes, of course, you should
put your build together so that the dependencies are clear. That's why I'm
puzzled by why it would even be suggested that the order in which you list
them should be ignored, since it seems to me that would make things far
less clear. If a target depends on more than one other target, and it
doesn't matter what order they're run in, and the order in which they're
listed is followed, then so what, no harm done. But for those cases where
a target depends on more than one other target, and the order in which
those are run does matter, having a tool that ignored that would just seem
so broken to me.

As an example case: The build-file for Ant has a target "run-single-test".
Now, I wanted to run that target so I could test a change I'd made. But I
certainly didn't want all of Ant built before I could do that (I just
wanted to run a flippin test!) -- but that's the way it's set up, because
the way it is, "run-single-test" depends on "compile-tests" (which was
fine) and "compile-tests" depends on "build" (which wasn't fine -- because
a) I didn't want to compile all those files, and b) it's not really true).
I'd much rather see a target (eg., "all", "full", whatever) that you could
run when you -wanted- to build both Ant and the test-cases. And for that
target, I'd list both "build" and "compile-tests" for the dependencies,
and I'd list them in that order, and I'd expect that order to be followed.
And I don't see that as "hiding" anything at all. Is the compiling of the
test-cases *dependent* on the compiling of the Ant source? Nope. Is the
full build of Ant, including both the source and the test-cases, dependent
on building first the Ant source then the test-cases? Yep. So it's much
more correct to -not- have "compile-tests" depend on "build" (since it
doesn't really), and instead have a target that specifies the dependency
that exists only when you really are building both, by listing both those
targets, in the order in which they need to be run.



Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices

View raw message