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]

Reply via email to