You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/04/03 13:34:26 UTC
Re: [classlib] ant platform property definitions
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.
>>
>> <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 <ma...@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
Re: [classlib] ant platform property definitions
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 <ge...@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 <ma...@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 <ma...@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
Re: [classlib] ant platform property definitions
Posted by Mark Hindess <ma...@googlemail.com>.
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 <ge...@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 <ma...@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 <ma...@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
Re: [classlib] ant platform property definitions
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 <ma...@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