ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject RE: ant/javac prepends destdir to classpath
Date Mon, 02 Aug 2004 14:05:55 GMT
> From: Dominique Devienne []
> Subject: RE: ant/javac prepends destdir to classpath
> > From: Klas Eriksson []
> > To rewrite the rule like
> >
> >      <javac srcdir="SRC"
> >             destdir="classes"
> >             includeAntRuntime="no"
> >             classpath="3rdpartyjars/castor-xml.jar">
> >        <include name="se/micronic/util1/**"/>
> >      </javac>
> >      <javac srcdir="SRC"
> >             destdir="classes"
> >             includeAntRuntime="no"
> >             classpath="3rdpartyjars/castor-xml.jar">
> >        <include name="/se/micronic/util2/**"/>
>                         ^ no slash
> >      </javac>
> >
> > is a bad idea. Javac is greedy and will automatically accept any
> strange
> > dependencies to other code.
> You can tell Javac not to be 'greedy' as you put it by adding
> sourcepath="" to <javac>. You will compile just the files included,
> if they have dependencies on classes not explicitly on the classpath
> in classes...), then the compile will fail (I use this trick
> extensively, as does the <compilewithwalls> Ant-Contrib task.
> But as you've discovered, classes already in Javac's destdir will be
> used by the compiler, so even with sourcepath="", a dependency on the
> first compiled set of sources could creep up in the second set of
> sources. If you really want to enforce the stand-alone'ness of both
> of sources, you need to use a different destdir, once for each set.
> Other sources compiled later on simply have to add these different
> destdirs on their classpath if they depend on the utility classes.
> I went even farther, breaking down a large code base into many such
> contained source groups, with clean dependency between each, automatic
> check of the dependency graph triggering compilation of the various
> groups in the right order, etc... and it all rests on sourcepath=""
> shoulders. The one big drawback is to now have 15 classes directories.
> (IDE users don't like that!)
> To avoid this, another project chose to still compile in several
> but outputting to a single classes/ dir instead, so it at least
> bad dependencies in a linear fashion. A source group fails to compile
> it depends on sources from a group compiled later on. In other words,
> you check that each layer depends on only stuff compiled in earlier
> passes, which is better than nothing.

I failed to mention here that the bad dependencies are caught on a full
rebuild only, and not during incremental builds. Even if developers
don't rebuild before check ins (and we'd be surprised how often this
happens :-(, at least the continuous integration build always does a
rebuild, so a bad dependency is quickly discovered.

The advantage of the different destdir solution is that dependencies are
enforced correctly even during incremental builds.

> Finally, note that compilation is several passes like this does not
> to be any slower than compiling everything in a single pass, at least
> for non-trivial compiles and informal testing. --DD

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message