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 Tue, 11 Apr 2006 00:23:06 GMT
not all - just the ones from IBM, or IBM employees?

Even if not...

Is there any harm in this case in expanding it out?

geir


Mark Hindess wrote:
> It's has been in our ant builds for some time - in all the
> modules/*/make/build.xml files for instance.  Does that mean we should
> continue to use it?
> 
> -Mark.
> 
> On 4/3/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>
>> 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.
>>
>> geir
>>
>>> 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
>>
>>
> 
> 
> --
> 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
> 
> 

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


Mime
View raw message