Return-Path: Delivered-To: apmail-ant-user-archive@ant.apache.org Received: (qmail 86041 invoked by uid 500); 24 Jul 2003 00:08:38 -0000 Mailing-List: contact user-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list user@ant.apache.org Received: (qmail 86016 invoked from network); 24 Jul 2003 00:08:38 -0000 Received: from mx2.sonypictures.com (66.77.63.115) by daedalus.apache.org with SMTP; 24 Jul 2003 00:08:38 -0000 Received: (qmail 24580 invoked by uid 0); 24 Jul 2003 00:04:54 -0000 Received: from unknown (HELO spde-mail1.spde.net) (160.33.16.160) by mx2.sonypictures.com with SMTP; 24 Jul 2003 00:04:54 -0000 Received: from sl-mail2.spde.net ([160.33.16.162]) by spde-mail1.spde.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Jul 2003 17:08:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Trying to get rid of makefiles Date: Wed, 23 Jul 2003 17:06:45 -0700 Message-ID: <961522C00478694CB10DAFE295B7ED81014C6781@sl-mail2.spde.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trying to get rid of makefiles Thread-Index: AcNRdjta8zcCSDuwTJOLOk9tBx+rHwAAEcjg From: "Harkness, David" To: "Ant Users List" X-OriginalArrivalTime: 24 Jul 2003 00:08:42.0963 (UTC) FILETIME=[BE261230:01C35177] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Wow, you've reproduced all the same functionality of makefiles using Ant, and they're going to get hung up on *one* feature because it doesn't work *exactly* like the makefile? Sheesh, that's pretty damn anal retentive. Nevertheless... :) Do you have multiple sets of .class files mixed into the same directory? In other words, do you compile two sets of .java files into the same "classes" directory? If not, then just delete the "classes" dir in your clean target (very typical behavior). This will be very fast compared to deleting all of the .class files individually. Most developers I know view incremental compilation not only as *standard* but as a positive feature. Change a class, recompile it. Getting odd build behavior, do a clean build. As another option, you might want to check out jdepends and the task (IIRC). It tracks which classes actually depend on each other and performs a more thorough incremental build based on timestamps and the dependency graph. I haven't looked into this as it hasn't been a big issue on even the bigger projects I've been on. Anyway, good luck! David Harkness Sony Pictures Digital Networks (310) 482-4756 -----Original Message----- From: Leonardo Abreu de Barros [mailto:leobarros@email.com]=20 Sent: Wednesday, July 23, 2003 4:02 PM To: ant-user@jakarta.apache.org Subject: Trying to get rid of makefiles Hi all, I work in a company that has a long history using makefiles. Since I=20 joined it, I proposed to migrate to Ant. Some people resist to=20 changes, some people agree, as long as all benefits provided by the=20 makefiles are covered by Ant. I've already reproduced all behaviors but one: currently, all java=20 classes names are declared explicitly in the makefile, and sent to=20 the java compiler. It rebuilds all the class files, at each build.=20 They want this behavior in order to detect broken code, due to=20 changes on a base class, for example. The problem is that Ant, specifically the task, only=20 recompiles ".class" if the timestamp differs from the related ".java"=20 file. I've read on documentation that to detect this kind of broken=20 dependencies, you should perform "clean builds" from time to time. I proposed this solution, but it wasn't accepted. They think it's a=20 loss of time (even if it's ridiculous) to delete all ".class" files=20 before calling the compiler. If I'm not able to reproduce this=20 behavior with Ant, they prefer to keep the makefiles. Does anyone have any idea of how I could reproduce this behavior=20 using Ant? Any other possible solution? Thanks in advance, Leonardo Barros --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org