harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] ant platform property definitions
Date Mon, 03 Apr 2006 11:34:26 GMT
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.


> 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.


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

View raw message