ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garcia, Gilles" <Gilles.Gar...@fmr.com>
Subject RE: rebuild when compiler changes ? (was:How to specify the locat ion of the compiler ?)
Date Tue, 13 Feb 2001 21:41:21 GMT
Usually one does builds on top of a Version control system
e.g. CVS, RCS, CLearCase, etc ...
And writing files is not going to be the whole answer. One cannot separate
these requirements from the undelying Revision control system.
When you check out a file, ITS properties file has to be used for
depend/rebuild decisions, not some properties file which happens to be
lying around from a previous invocation of Ant. 
It ain't that straightforward.

-----Original Message-----
From: Bill Burton
To: ant-user@jakarta.apache.org
Sent: 2/13/01 4:05 PM
Subject: Re: rebuild when compiler changes ? (was:How to specify the locat
ion   of the compiler ?)

Hello,

I don't think it would be too difficult to write a task that compared a
list of build properties in a file to the current values.  If any of the
values had changed, it would write out a new properties file and set a
property indicating a full rebuild was required.  This property would
then
be used to trigger a clean on the target directory before the compile is
performed or, the task could delete classes in the target directory
itself.

Another option is would be to add this functionality to the 1.3
<depends>
task as the compiler, optimization and debugging options are also target
dependencies.  There should also be the ability to add user defined
properties to indicate if application based debugging or tracing, etc.
was
enabled or disabled.

-Bill Burton

Diane Holt wrote:
> 
> --- "Garcia, Gilles" <Gilles.Garcia@fmr.com> wrote:
> > The retainer" mechanism are the time stamps applied by the OS's
> > file system. The compiler path has a time stamp (e.g., when it was
> > dowloaded and installed), and any classs on the file system has
> > a creation date.
> 
> That would take care of the newer-than case -- although you'd still
need
> to implement something to even do that kind of checking. It wouldn't,
> however, take care of the different-from case (eg., if build.compiler
was,
> say, jikes for this run but was modern for the previous one).
> 
> Diane
> 
> =====
> (holtdl@yahoo.com)

Mime
View raw message