harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bootjvm" <boot...@earthlink.net>
Subject RE: [classlib] ant platform property definitions
Date Thu, 30 Mar 2006 02:15:27 GMT

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.

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!


> 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

Word widths:
    64
    32

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