Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 79109 invoked from network); 3 Apr 2006 11:34:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Apr 2006 11:34:54 -0000 Received: (qmail 75750 invoked by uid 500); 3 Apr 2006 11:34:49 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 75689 invoked by uid 500); 3 Apr 2006 11:34:49 -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 75677 invoked by uid 99); 3 Apr 2006 11:34:49 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Apr 2006 04:34:49 -0700 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=RCVD_IN_SORBS_WEB,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor denied by domain of t.p.ellison@gmail.com) Received: from [217.158.94.220] (HELO cirrus.purplecloud.com) (217.158.94.220) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Apr 2006 04:34:48 -0700 Received: (qmail 27363 invoked from network); 3 Apr 2006 12:34:26 +0100 Received: from blueice1n1.uk.ibm.com (HELO ?9.20.183.160?) (195.212.29.67) by smtp.purplecloud.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Apr 2006 12:34:26 +0100 Message-ID: <44310842.7010600@gmail.com> Date: Mon, 03 Apr 2006 12:34:26 +0100 From: Tim Ellison User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [classlib] ant platform property definitions References: <442C64E1.3080407@pobox.com> In-Reply-To: <442C64E1.3080407@pobox.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Geir Magnusson Jr wrote: > Along with everything everyone else has said... > > Yes, please, lets standardize. Get rid of caps as suggested and please, > lets not use "hy" and use "harmony". It isn't used in such high volume > that skipping the extra 5 characters isn't that big of a benefit, and it > makes things easy to read. It is used in high volume in our native code. Regards, Tim > Mark Hindess wrote: >> Currently a number of the classlib ant files "normalize" operating >> system and architecture names. Unfortunately they don't >> really normalize them in the same way. ;-) >> >> For instance, native-src/build.xml sets target.platform to >> "linux.IA32" and modules/security/make/build.xml sets "platform.name" >> to "lnx". >> >> I think we should decide on a common normalized form and have a single >> common ant file to import that defines them. I'd already started to >> create one (as I was about to add platform defines in yet another ant >> file) but then I realised there wasn't any consensus about what the >> normalized form should be. >> >> I think having a mapping (from os.arch to hy.arch and os.name and >> hy.os) is useful because it reduces the coupling between Harmony and >> ant, and because it enables use to perform sensible normalizations. >> But, I don't think we should make the mapping unnecessarily >> complicated. I think we should keep the normal form as close as >> possible to the standard ant defines of os.name and os.arch. >> >> So, ${hy.os} would be ${os.name} - with values like 'Linux', >> 'Solaris', etc. - except for Windows where we would normalize to >> "Windows". Similarly, ${hy.arch} would be ${os.arch} - with values >> like 'x86', 'x86_64', 'ia64', etc. I see no clear reasons for >> exceptions to the ${hy.arch} at the moment, but we should create it >> and use it consistently. > > I hate "hy" with a real passion. Can we please use "harmony"? That's > the project name. IBM decided to use 'hy' as a prefix because it was > easier to type (reasonable, I guess...) but I think that it's not so bad > to use the full "harmony" > > >> >> This would lead to "hy.platform" being defined as: >> >> Linux.x86 >> Windows.x86 >> >> We could add exceptions - for instance, to make 'Linux' lower case - >> but then we'd only need to add exceptions later for 'Solaris', 'Aix', >> etc. I think we'd be better to avoid this and only have exceptions >> where: >> >> * the name contains characters that can't be used in file names, or >> * there is a clear reason to normalize - e.g. "Windows XP", etc. >> >> So, what do people think? Is there a compelling reason to maintain >> the differences we have today - e.g. Linux in lowercase, 'ipf' rather >> than 'ia64' - or can we just stick with the ant defines? >> >> >> We also have many definitions of properties like "is.win", >> "is.windows", and "if.win". I'd prefer to stick to forms starting >> with 'is.' since I think they read better when used, e.g. >> >> >> ... >> >> >> and the item following the 'is.' prefix should be the all lowercase >> (in line with typical conventions for ant properties) but otherwise >> match the ${hy.os} and ${hy.arch} defines above. >> >> Assuming we reach a consensus, I think directories should be renamed >> to match the agreed definitions. We might as well change 'win.IA32' >> to 'Windows/x86' - or whatever we decide on - while we are doing this. >> >> I'll be happy to do the work to create the common ant file and to >> submit a JIRA with any layout changes (I think there will be some >> regardless of what decision is reach because of current differences). >> >> Regards, >> Mark. >> >> -- >> Mark Hindess >> IBM Java Technology Centre, UK. >> >> > > -- Tim Ellison (t.p.ellison@gmail.com) IBM Java technology centre, UK. --------------------------------------------------------------------- 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