ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: Clean build vs partial rebuild
Date Tue, 16 Sep 2003 14:57:51 GMT
> -----Original Message-----
> From: Rutger Hofman [mailto:rutger@cs.vu.nl]
> An incremental build should come with sophisticated dependency
> analysis. For this, there is <depend>. However, in my experience
> doing "ant depend build" is not at all necessarily faster than
> "ant clean build".
> 
> So, an incremental build is only faster without "ant depend", but
> then the programmer should be very aware of overlooked dependencies.
> 
> > From: Jan.Materne@rzf.fin-nrw.de:
> > But my opinion is
> > - do a incremental build during development (includes unit tests)
> > - (sometimes a clean build during development :-)
> > - do a clean build before system test and release
> >
> > > From: Travis Kline [mailto:traviskline1977@hotmail.com]
> > > I wanted to get the board's consensus on the clean build
> > > vs partial build debate.  I have read in more than one source
> > > that it is a "goodpractice" to always perform a clean build. 
> > > Why?  If you are caching your destination directory when compiling,
> > > besides speed, is thereany other benefit?
> > > What are you doing in your build?

I've seen too major pitfalls developers around me have fallen into with
incremental builds:

1) Removed/renamed resources (.properties, .gif) in the source tree,
   not removed from the classes tree by an incremental build.
2) Removed/renamed Java sources,
   not removed from the classes tree by an incremental build.

I now have a solution for both I think, to be rolled out to all my problem
soon:

For (1), instead of doing a <copy> of the resources into build/classes/,
I'll now <lsync> them into build/resources/, with <lsync> in a strict mode
where files in both src and dest trees must be absolutely equals (CVS can
play tricks with dates, so checking file sizes and even sums might be
necessary.

For (2), I've developed a selector that parses a class file to identify
which Java source it came from, to remove "orphan" class files. Since the
class parser is very specialized to just get that info, it's rather quick,
but I'm also looking at caching options.

/**
 * An Ant file selector that matches class files
 * which have no corresponding Java source file.
 * <p>
 * Note that class files compiled without debug information (specifically
 * the SourceFile attribute of the class file) will be ignored by this
 * selector.
 * .../...
 */
public class OrphanClassFileSelector
             extends BaseExtendSelector { .../... }

With these two solutions, it should avoid most mistakes I've seen from
inexperienced developers (people with other expertise, also doing
development), while not putting too much a delay on incremental builds. I
might not use these on large projects for example.

I'll add two things:
1) Setup CruiseControl (or equivalent) build of all your projects,
   so you can catch early these kind of errors. The CC build does
   a clean build of course!
2) Most experienced developers usually feel when a fully rebuild
   is necessary, and when things start behaving strangely, do a full
   rebuild before wasting time in a wild goose chase.

Cheers, --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message