Diane Holt wrote:
>
> ...
> 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).
Why wouldn't compiling the tests depend on building the system? Wouldn't
the test call something in the system, so the tests won't compile if the
system isn't compiled at all? Isn't it true that a test run isn't a valid
test (of the system's source code) unless you've compiled the system's
source code?
(I guess this depends on whether one considers "run-tests" to be simply a
verb ("do this action") or a regular target (some _thing_ to be rebuilt,
which, as a thing, can depend on other things).)
(But see below.)
> 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.
I think the question is whether you want your build files to
- automatically update things a target depends on before performing that
target
- be able to run a target ignoring things it depends on, or
- *BOTH*
I've been addressing this issue myself recently, trying to figure out how
to structure things to have one target that updates my system's module2 after
updating depended-on module1, and _also_ have a target that updates module2
without trying to make sure module1 is up to date.
Currently, my build files do depend on the order in which things are listed
in depends attributes (as you seem to advocate). For example:
<target name="module2" depends="module1, module2.raw" ...
<target name="module2.raw" depends="" >
... builds modules 2 ....
</target>
However, depending on that order just doesn't seem right.
Other solutions that don't depend on the order don't seem quite right
either. (See my message in the "depends list order? (was: [RESULT]
multithrading)" subthread.)
Is Ant missing some primitive dependency feature that would make all
this easier?
Should the listing order really be significant, or is there something
else that would let us specify an order without establishing a dependency
we don't want?
Daniel
--
Daniel Barclay
Digital Focus
[EMAIL PROTECTED]
