harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] ant platform property definitions
Date Thu, 30 Mar 2006 23:08:17 GMT
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.

geir

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 <mark.hindess@googlemail.com>
> IBM Java Technology Centre, UK.
> 
> 


Mime
View raw message