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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> >>> IBM Java Technology Centre, UK.
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
