From harmony-dev-return-9530-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu Jun 29 15:56:38 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 75154 invoked from network); 29 Jun 2006 15:56:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 29 Jun 2006 15:56:37 -0000 Received: (qmail 97776 invoked by uid 500); 29 Jun 2006 15:56:34 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 97708 invoked by uid 500); 29 Jun 2006 15:56:34 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 97696 invoked by uid 99); 29 Jun 2006 15:56:34 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jun 2006 08:56:34 -0700 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [206.190.58.161] (HELO web55112.mail.re4.yahoo.com) (206.190.58.161) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 29 Jun 2006 08:56:33 -0700 Received: (qmail 72155 invoked by uid 60001); 29 Jun 2006 15:56:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Dq4HYAPA+PHu0Ewq7kHrESOdgJX5ic3NobCHQ9mWgOdQwOIomNkThSj5pK+5xlDjb8wDXBSr5YYabUHy7tCPa9gZ9AyxAXk5eqg+9gWopAfg7V6U2sXcC4GYtf+DNYZMjENcwUzT4snBhI49QDFY9RL6hNya0hR6m1kiPITwUNY= ; Message-ID: <20060629155612.72153.qmail@web55112.mail.re4.yahoo.com> Received: from [66.10.233.130] by web55112.mail.re4.yahoo.com via HTTP; Thu, 29 Jun 2006 08:56:12 PDT Date: Thu, 29 Jun 2006 08:56:12 -0700 (PDT) From: Matt Benson Subject: [classlib] build file stuff To: harmony-dev@incubator.apache.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Now that I've (finally, thanks Gregory!) got the classlib built I'd like to start playing with the Ant buildfiles to apply some of the practices encouraged with modern Ant versions, but possibly lesser-known to old-school (aka "learned Ant 1.5.x or earlier") users. The first thing I plan to do is remove s wherever possible (which should be everywhere). and run builds against other buildfiles; this is sensible and the utility of it is obvious. calls targets from a local (or imported) buildfile, creating a new Project instance in the process, a time- and memory-intensive process. In Ant < 1.6 s could often be avoided by arranging targets such that Ant's management of target depends would take care of target interdependencies (the "Ant way"); remained useful for when some parameterizable set of tasks was needed. Ant 1.6 saw the advent of which accomplished the purpose of in (damn it) a cooler fashion, without creating a new Project context. I joined Ant right after the release of 1.6, and was myself daunted by macros; I put off learning them until such time as I couldn't claim I had anything else to do... but the transition from antcalls to macros was painless. The "rightness" of this feature has never been challenged; macros have become a new and shiny facet of the "Ant way" IMHO. That may have turned a little religious, but I took the time to write it, so it stands. :) Anyway, my point is that antcalls are evil and that a combination of target restructuring and macros can remove all but the very stubbornest of them (I can't even remember offhand what kind of situation leaves no alternative). Here are the (IMO minimal) tradeoffs, for the sake of allowing folk to voice any concerns: -When you are calling a target with an , but you also want it to be available as an atomic target of its own, that suggests the antcall should be accomplished with target restructuring. To some this might make the build seem more complex. In this example: foo bar the "foo" target would become: foo Now, I consider this "complication" of the buildfile minimal, but I'm used to looking at such things. aside: the minus target naming, as some users may know, is an old Ant trick that prevents a target from being called from the command line due to the fact that it is interpreted as a switch by Ant main. This is of lesser value as Eclipse, as a handy IDE example, does allow a user to directly run what is--by convention only--considered an inner or private target. I could have named it "innerfoo" for example. Before we completely abandon the concept of inner targets, let me mention that it might be a good idea to always set descriptions on those targets intended for user consumption, as in native-src/build.xml . This causes Ant's -p/-projecthelp to display only these targets, hopefully making the task of using a new buildfile less onerous for a newcomer. In contrast, classlib's top-level build.xml does not make use of target descriptions. When you are simply using a target as a container for a group of tasks, and the target itself is not meant for public consumption, that suggests the target would be better defined as a macrodef. And to be quite honest, I'm having a hard time thinking of anything negative to say about macrodefs. They really don't make your buildfile any more complicated or anything else.... ! Oh, well! :) If anyone is still with me after this tome, my purpose has been to elicit comment of any qualms anyone has, particularly with regard to target/dependency restructuring, before I start submitting JIRA issues to remove s. -Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org