harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess" <mark.hind...@googlemail.com>
Subject Re: [classlib] ant platform property definitions
Date Thu, 30 Mar 2006 05:54:47 GMT
Dan,

Thanks for the helpful comments.

On 3/30/06, bootjvm <bootjvm@earthlink.net> 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 <mark.hindess@googlemail.com>
> > 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 <mark.hindess@googlemail.com>
IBM Java Technology Centre, UK.

Mime
View raw message