harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] ant platform property definitions
Date Mon, 03 Apr 2006 14:34:19 GMT

Tim Ellison wrote:
> 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.

I'm not suggesting you change it, just not perpetuate the mistake ;) 
into our ant builds.


> 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.
>>>   <target name="do-windows-stuff" if="is.windows">
>>>     ...
>>>   </target>
>>> 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 <mark.hindess@googlemail.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

View raw message