--- "Siberski, Wolf" <[EMAIL PROTECTED]> 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. Diane ===== ([EMAIL PROTECTED]) __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
