Re: [classlib] ant platform property definitions
not all - just the ones from IBM, or IBM employees?
Even if not...
Is there any harm in this case in expanding it out?
geir
Mark Hindess wrote:
It's has been in our ant builds for some time - in all the
modules/*/make/build.xml files for instance. Does that mean we should
continue to use it?
-Mark.
On 4/3/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
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]
--
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] ant platform property definitions
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.
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.
--
Tim Ellison ([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]
Re: [classlib] ant platform property definitions
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]
Re: [classlib] ant platform property definitions
It's has been in our ant builds for some time - in all the
modules/*/make/build.xml files for instance. Does that mean we should
continue to use it?
-Mark.
On 4/3/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
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]
--
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]
Re: [classlib] ant platform property definitions
Mark Hindess wrote: 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. Agreed. Using mixed case just adds potential for errors. All lower case is simple and doesnt require us to remember whether, for example, aix is AIX or Aix or whatever. 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. Seconded. Again, abbreviations are something that will add complexity and opportunity for errors. -- Oliver Deakin IBM United Kingdom Limited
Re: [classlib] ant platform property definitions
Isn't there some standard naming strategy, used by other Apache projects? I know that autoconf has a platform naming strategy. I recommend to study other platform naming strategies before making a decision. This will help reduce the number of mistakes. Etienne bootjvm wrote: Bottom line:Mixed case just adds one more level of complexity to the whole situation. Other comments below OS names: linux cygwin windows solaris CPU names: intel sparc ppc Word widths: 64 32 -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ signature.asc Description: OpenPGP digital signature
Re: [classlib] ant platform property definitions
[Original Message]
From: Mark Hindess [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Date: 3/29/06 11:55:13 PM
Subject: Re: [classlib] ant platform property definitions
Dan,
Thanks for the helpful comments.
On 3/30/06, bootjvm [EMAIL PROTECTED] wrote:
... snip ...
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?
Well, uhh, no. Even as I was writing this, I thought I should
clarify what I mean by intel, that is, the x86 architecture
used by MS Windows versus anything else. By 'ia64' do
you mean the Intel Itanium with a native word size of 64
bits, I presume?
I have never had occasion to use that archtecture. What
distinguishing features does it have for application software
that needs CPU- and OS-dependent code? I would be
interested in supporting it for BootJVM. (If I did so,
I would probably start out with a build token of something
like 'itanium' to be consistent with the rest of the code.)
Thanks,
Dan Lydick
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.
... snip ...
Re: [classlib] ant platform property definitions
[Original Message] From: Etienne Gagnon [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 3/30/06 6:39:47 AM Subject: Re: [classlib] ant platform property definitions Isn't there some standard naming strategy, used by other Apache projects? I know that autoconf has a platform naming strategy. I recommend to study other platform naming strategies before making a decision. This will help reduce the number of mistakes. Etienne Especially mistakes when working between different areas of the Harmony project where different conventions are used! The earlier we come up with a project-wide convention, the easier it will be in the long run. I'm open to ideas, but let us stick to single-case tokens that keep OS, CPU, and word width separate, but which can mix and match them into derived tokens as needed. Dan Lydick bootjvm wrote: Bottom line:Mixed case just adds one more level of complexity to the whole situation. Other comments below OS names: linux cygwin windows solaris CPU names: intel sparc ppc Word widths: 64 32 -- Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
RE: [classlib] ant platform property definitions
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 [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!
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 [EMAIL PROTECTED]
IBM Java Technology Centre, UK.
Re: [classlib] ant platform property definitions
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
