From jltharp@att.com Thu May 1 13:27:57 2003 Return-Path: Mailing-List: contact user-help@ant.apache.org; run by ezmlm Delivered-To: mailing list user@ant.apache.org Received: (qmail 15878 invoked from network); 1 May 2003 13:27:57 -0000 Received: from kcmso2.att.com (HELO kcmso2.proxy.att.com) (192.128.134.71) by daedalus.apache.org with SMTP; 1 May 2003 13:27:57 -0000 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h41Cxq1v003205 for ; Thu, 1 May 2003 08:27:58 -0500 (CDT) Received: from acclust02evs1.ugd.att.com (135.37.16.9) by attrh0i.attrh.att.com (6.5.019) id 3EADA699001BE081 for user@ant.apache.org; Thu, 1 May 2003 09:27:58 -0400 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: Clearcase and ant Date: Thu, 1 May 2003 09:27:50 -0400 Message-ID: <126C77D3993DC640B8C9012D54A3C460047EB5C4@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clearcase and ant Thread-Index: AcMPw2S9WIk+I3QrTtqWrV9tlZGPpwAICrfQ From: "Tharp, Joshua L, SOLGV" To: "Ant Users List" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I use ClearCase and ANT in my build environment. While I haven't been interested in the CR lately, I've used it in the past. What we did to prevent the bad build scenario was to have two different types of build. The first, most regularly used type is the developer's build. It uses a normal ANT target and builds the source in the current view. The developer is responsible for knowing to use the clean target if they roll back a version. The other build is for distributions. In this second case, we have a script that creates a new view and performs the build in that view. That way you only get checked-in files and are current for the specified build config spec (in our environment that was usually main/LATEST, but it could be any standardized config spec). As for CRs with java builds, Rational / IBM basically admits that there is no real good way to build java in their "Building Software" manual, chapter 8. They claim that there are three approaches to overcome their shortcomings: 1. Write makefiles correctly (i.e. spell out each dependency and order them to eliminate rebuilds and javac automatic dependency compilations). 2. Keep rebuilding until the dependencies stabilize in the CR 3. Configure clearmake to behave as make (which eliminates the behavior of detecting a rolled-back version) As for a hack to do what you want in an automated way... You could copy the source to a different directory as part of the build. Then on your next build compare the copied source from the last build with the current source to compile and find those that are different. You may save a significant amount of time by not looking up the config spec rules for each file. Josh -----Original Message----- From: Harry J Walsh [mailto:hjw@com21.ie]=20 Sent: Thursday, May 01, 2003 2:23 AM To: user@ant.apache.org Subject: Clearcase and ant Hi, I'm working on a java project using clearcase for our source control. We=20 currently use clearmake with javac to build our project. I've recently=20 started using ant and after spending quite a bit of time searching for=20 information on how to integrate ant with clearcase I still haven't been=20 able to successfully do it. Clearmake doesn't use file modification dates to manage build dependencies=20 but ant does. So if I checkout a file and make some changes and then built it with ant,=20 it will detect the checkout as newer than the .class file and rebuild it. =20 That's fine, however if I then decide I nolonger want those changes and=20 uncheckout the file it reverts to the original version and that file=20 appears to have been modified before the .class file was generated so no rebuild is performed. I've been looking at the source for the 'depend' task and it should be=20 possible to modify that to include the clearcase file version information=20 in the depcache. Then I would be able to detect if a file version has=20 changed since the last time it was built and remove the appropriate .class=20 file or files. However the act of finding each .java file used in the current ant target=20 and reading the version selected by the config spec takes quite a while to=20 run on our source tree. So before I proceed with this mechanism I'm polling this list in the hope=20 that one of you has already solved this particular issue. I'm aware it=20 might also be possible to use clearcase triggers to remove .class files=20 when a .java checkout is cancelled, but I'm sure this will be problematic=20 for us as it would be difficult to determine all the scenarious in which 'older' versions of source files are failing to trigger rebuilds. Running ant within 'clearaudit' doesn't work as each file generated appears=20 to depend on every source file accessed by the ant process. Any ideas or suggestions would be helpful. Cheers, -- Harry J Walsh --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org