Dan,
Thanks for the helpful comments.
On 3/30/06, bootjvm <[EMAIL PROTECTED]> wrote:
>
> Concerning the ideas for platform names, I think lower case names
> like 'linux' and 'windows' and 'solaris' and 'aix' is by far the simplest
> method. It avoids UPPER case errors with the shift key for these
> _very_ common key sequences, reducing "Inaccurate kEy SEquences"
> quite a bit. I have seen this work well for both platform names
> and for project names (such as "newproj1" instead of "NewProj1")
> with favorable long-term response from those who type the key
> sequences most.
Very good point. You are absolutely correct. Sticking with Ant case
may reduce complexity in the ant files but it makes things more
confusing/complex for users. This would be a bad idea. The case
mapping can be managed in a single ant file, for classlib anyway,
which should make it manageable.
> Bottom line: Mixed case just adds one more level of complexity
> to the whole situation. Other comments below....
>
> Dan Lydick
>
>
> > [Original Message]
> > From: Mark Hindess <[EMAIL PROTECTED]>
> > To: Harmony Dev <harmony-dev@incubator.apache.org>
> > Date: 3/29/06 10:28:41 AM
> > Subject: [classlib] ant platform property definitions
> >
> > 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".
> >
>
> PLEASE, no abbreviations! Nobody abbreviates the same way, and
> even one individual may use more than one abbreviation for a word!
Agreed.
> > 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.
> >
> > 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?
> 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.
> These are put together in different combinations in the
> configuration-- ALL LOWER CASE ;-) -- and show
> up in the file names for deliverables, etc., in this way.
> For code defines, they are all in upper case per C coding
> conventions.
>
> When using mixed case in other situations (namely, version
> control tags and branches), I have seen consistent confusion
> with users, so I have always specified only one case for use
> in some tokens. (For example, upper in tags, lower in
> branches.)
>
> >
> > 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.
