> [Original Message]
> From: Mark Hindess <[EMAIL PROTECTED]>
> To: <harmony-dev@incubator.apache.org>; <[EMAIL PROTECTED]>
> Date: 3/29/06 11:55:13 PM
> Subject: Re: [classlib] ant platform property definitions
>
> Dan,
>
> Thanks for the helpful comments.
>
> On 3/30/06, bootjvm <[EMAIL PROTECTED]> wrote:
> >
... snip ...
> > >
> > > 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?
> > >
> >
> > I would like to have us all start thinking in this early stage about
> > abbreviations across the _whole_ of the Harmony component
> > roster. In particular, I would like to get my BootJVM code
> > using the same tokens as elsewhere. Right now, I am using,
> >
> > OS names:
> > linux
> > cygwin
> > windows
> > solaris
> >
> > CPU names:
> > intel
> > sparc
> > ppc
>
> Do you distinguish between ia64 and x86_64?
>
Well, uhh, no. Even as I was writing this, I thought I should
clarify what I mean by "intel", that is, the x86 architecture
used by MS Windows versus anything else. By 'ia64' do
you mean the Intel Itanium with a native word size of 64
bits, I presume?
I have never had occasion to use that archtecture. What
distinguishing features does it have for application software
that needs CPU- and OS-dependent code? I would be
interested in supporting it for BootJVM. (If I did so,
I would probably start out with a build token of something
like 'itanium' to be consistent with the rest of the code.)
Thanks,
Dan Lydick
> > Word widths:
> > 64
> > 32
>
> Yes. We might as well create ${hy.bits} and ${is.64bit} and
> ${is.32bit} definitions in the same file while doing this
> consolidation.
>
> Thanks again for the constructive comments. Much appreciated.
>
> Regards,
> -Mark.
>
... snip ...
