Return-Path: Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 8751 invoked from network); 13 Feb 2001 23:05:46 -0000 Received: from berlin.netdelivery.com (HELO berlin.netdelivery) (216.87.91.70) by h31.sny.collab.net with SMTP; 13 Feb 2001 23:05:46 -0000 Received: by berlin.netdelivery with Internet Mail Service (5.5.2650.21) id <1PZK7KGS>; Tue, 13 Feb 2001 16:05:26 -0700 Message-ID: <7114B83CE30FD31183CD00805FBE772DFA18DC@berlin.netdelivery> From: Steve Wilkinson To: "'ant-user@jakarta.apache.org'" Subject: RE: rebuild when compiler changes ? (was:How to specify the locat ion of the compiler ?) Date: Tue, 13 Feb 2001 16:05:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N I agree with this since I have exprienced the need for it first hand. We use ant to generate Java classes. The java classes are dependent on txt files. We would like to be able to determine when a text file has changed and re-generate the Java classes associated with the text file. We are currently using the uptodate and the jar command. The problem that exists with this approach is that when one of the text files is deleted the uptodate command still reports the jar as being uptodate. However, we don't delete files often so we can live with it for now. After the Java classes have been generated and compiled we also set a property in a properties file that says that this portion of the build is complete. The uptodate on the jar will reset the property in the properties file when the jar is outofdate. (Note, we have to copy property files around because in 1.2 I couldn't figure out how to delete a property from a properties file.) This process does not impact the CM process. The jar file is created and the properties set, but it doesn't matter since we always to a clean before a get from the repository. The jar is created and all the files are generated and compiled. I would welcome an improved depends or uptodate. Or even a new task that supported this. We have struggled in implementing ant because there is alot of scripting in the old build processs. We compromised and wrote shell shell scripts that run on bash and on bourne shell so we can be cross platform. My 2 cents... ;-) -----Original Message----- From: Bill Burton [mailto:billb@progress.com] Sent: Tuesday, February 13, 2001 2:06 PM To: ant-user@jakarta.apache.org 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 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" 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)