Re: [classlib] debug compilation as default
Salikh Zakirov skrev den 17-07-2006 17:14: But then, I am unix type, and having correctly defined environment is essential to me. I just keep my .profile file up-to-date, and don't care about setting it in a new window. It gets configured automatically. And I hate property files, because they cannot be configured in one central place, and I have to keep copying them over and over, and quickly get lost in a multitude of unsynchronized copies. This applies for you, but you cannot check environment variables into a versioning control system, and therefore ensure that the basic environment is the same for all users. I have now tried for quite some time to get in the water with the builds and find environment variables extremely annoying since i have to keep copying them around from machine to machine and get lost in a multitude of unsynchronized copies. property files are configured in one central place :) -- Thorbjørn - 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] debug compilation as default
Ivan Volosyuk wrote:
I have already implemented it using ant variables, look at the latest
patch. You can use following notation with it:
ant -Dhy.cfg=release
Geir Magnusson Jr wrote:
Now we're getting somewhere.
I assume then I can put this into the build.properties that we'll be
adding Real Soon Now (as I can never remember command line args anyway...)
Please, please, do *not* introduce any more build.properties files.
The files that may need to be customized to get specific build configuration
should never be version-controlled. Besides, keeping configuration files
in the workspace means you cannot make your configuration permanent.
I see the properties files as anti-usable.
The main point of using environment variables instead of ant properties
is an ability to do a *workstation-specific* configuration in a permanent way,
so that I do not need to do any configuration steps before the build for
the fresh workspace, once I have configured my environment.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
-
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] debug compilation as default
Salikh Zakirov wrote:
Ivan Volosyuk wrote:
I have already implemented it using ant variables, look at the latest
patch. You can use following notation with it:
ant -Dhy.cfg=release
Geir Magnusson Jr wrote:
Now we're getting somewhere.
I assume then I can put this into the build.properties that we'll be
adding Real Soon Now (as I can never remember command line args anyway...)
Please, please, do *not* introduce any more build.properties files.
We need *one*. right now, things are in environment variables, embedded
in build.xml files, or randomly passed on the command line. It's ad-hoc
and not easily reproducible or portable.
The files that may need to be customized to get specific build configuration
should never be version-controlled. Besides, keeping configuration files
in the workspace means you cannot make your configuration permanent.
I see the properties files as anti-usable.
The default set is version controlled. It's not called
build.properties. The properties in build.properties override the defaults.
The main point of using environment variables instead of ant properties
is an ability to do a *workstation-specific* configuration in a permanent way,
so that I do not need to do any configuration steps before the build for
the fresh workspace, once I have configured my environment.
I disagree. you can use the properties to do things in a workstation
specific way, and in a very clean, localized way. One file, rather than
in semi-visible and distributed bits.
You can also come up with configuration sets, that can be checked in and
re-used in a predictable manner.
test_local_debug.properties
test_remote_debug.properties
test_local_release.properties
test_remote_release.propertes
etc
You can also cleanly, portably automate things too.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
It can be used. I'm just proposing something portable and reusable.
geir
-
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] debug compilation as default
Mark Hindess wrote:
On 17 July 2006 at 15:34, Salikh Zakirov [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
I have already implemented it using ant variables, look at the latest
patch. You can use following notation with it:
ant -Dhy.cfg=release
Geir Magnusson Jr wrote:
Now we're getting somewhere.
I assume then I can put this into the build.properties that we'll be
adding Real Soon Now (as I can never remember command line args anyway...)
Please, please, do *not* introduce any more build.properties files.
The files that may need to be customized to get specific build
configuration should never be version-controlled. Besides, keeping
configuration files in the workspace means you cannot make your
configuration permanent. I see the properties files as anti-usable.
I'll let Geir speak for himself, but I think he was alluding to the use
of a user properties file:
property file=${user.home}/.harmony.properties /
that would *not* be checked in and would be read (if it existed or
ignored otherwise).
yes, but more than that - having configuration sets that could be
re-used is also a goal.
geir
-
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] debug compilation as default
Mark Hindess wrote:
I'll let Geir speak for himself, but I think he was alluding to the use
of a user properties file:
property file=${user.home}/.harmony.properties /
that would *not* be checked in and would be read (if it existed or
ignored otherwise).
Which is exactly what you can achieve in a platform-independent way with
a property file as described above.
This solution is okay with me.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
Read the list archive. Environment variables are platform-specific and
differ - if they exist - from platform to platform. Windows for example
treats environment variable names as case-insensitive but when ant reads
them from env.VaR you must get the case exactly right. Ant properties
are platform-independent and so will work the same everywhere.
I have read the discussion, and still consider this as non-issue,
because anyone can be careful enough to define the name in correct case.
(So one must define the variable in proper case as HY_CFG even on Windows)
In my practice, environment variables worked fine on Windows.
And I have not heard a single report on how environment variables failed in
real life.
I have only seen discussion how this *may* fail if the user is not careful
enough
to do precisely what is written in instruction.
Still unconvinced why we can't allow careful users to use environment
variables for configuration.
-
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] debug compilation as default
Salikh Zakirov wrote:
Mark Hindess wrote:
I'll let Geir speak for himself, but I think he was alluding to the use
of a user properties file:
property file=${user.home}/.harmony.properties /
that would *not* be checked in and would be read (if it existed or
ignored otherwise).
Which is exactly what you can achieve in a platform-independent way with
a property file as described above.
This solution is okay with me.
That's not a solution. It's what people do to personalize. I'm
targeted at normalizing how we handle configuration properties.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
Read the list archive. Environment variables are platform-specific and
differ - if they exist - from platform to platform. Windows for example
treats environment variable names as case-insensitive but when ant reads
them from env.VaR you must get the case exactly right. Ant properties
are platform-independent and so will work the same everywhere.
I have read the discussion, and still consider this as non-issue,
because anyone can be careful enough to define the name in correct case.
(So one must define the variable in proper case as HY_CFG even on Windows)
The point is that we want to reduce the number of places that things can
get broken...
In my practice, environment variables worked fine on Windows.
And I have not heard a single report on how environment variables failed in
real life.
I have only seen discussion how this *may* fail if the user is not careful
enough
to do precisely what is written in instruction.
Still unconvinced why we can't allow careful users to use environment
variables for configuration.
because as a matter of engineering practice, you want to reduce the
number of places that errors can happen, and increase the amount of
easily reusable configuration.
Notice how you keep saying can be careful enough or allow careful
users
We can make it easier to work with Harmony, I believe, by removing the
'extra care' requirement when possible.
geir
-
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] debug compilation as default
+1 for property files.
The one of the main benefits for me is the possibility to define all
the needed properties just once. But not execute a huge number of set
SMTH and set ANOTHERTHING each time I open a new window or reboot
my machine.
That's why it is better to get proxy info from property file instead
of setting ANT_OPTS variable :)
http://issues.apache.org/jira/browse/HARMONY-523
SY, Alexey
2006/7/17, Geir Magnusson Jr [EMAIL PROTECTED]:
Salikh Zakirov wrote:
Mark Hindess wrote:
I'll let Geir speak for himself, but I think he was alluding to the use
of a user properties file:
property file=${user.home}/.harmony.properties /
that would *not* be checked in and would be read (if it existed or
ignored otherwise).
Which is exactly what you can achieve in a platform-independent way with
a property file as described above.
This solution is okay with me.
That's not a solution. It's what people do to personalize. I'm
targeted at normalizing how we handle configuration properties.
And by the way, the solution to run 'HY_CFG=xyz ant' with
corresponding
property environment=env/
condition property='hy.cfg' value='${env.HY_CFG}'
isset property=env.HY_CFG/
/condition
worked perfectly for the DRLVM builds on Windows. What's more,
it is *compatible* with 'ant -Dhy.cfg=...' syntax.
I have not heard any specific concerns why this can't be used.
Read the list archive. Environment variables are platform-specific and
differ - if they exist - from platform to platform. Windows for example
treats environment variable names as case-insensitive but when ant reads
them from env.VaR you must get the case exactly right. Ant properties
are platform-independent and so will work the same everywhere.
I have read the discussion, and still consider this as non-issue,
because anyone can be careful enough to define the name in correct case.
(So one must define the variable in proper case as HY_CFG even on Windows)
The point is that we want to reduce the number of places that things can
get broken...
In my practice, environment variables worked fine on Windows.
And I have not heard a single report on how environment variables failed in
real life.
I have only seen discussion how this *may* fail if the user is not careful
enough
to do precisely what is written in instruction.
Still unconvinced why we can't allow careful users to use environment
variables for configuration.
because as a matter of engineering practice, you want to reduce the
number of places that errors can happen, and increase the amount of
easily reusable configuration.
Notice how you keep saying can be careful enough or allow careful
users
We can make it easier to work with Harmony, I believe, by removing the
'extra care' requirement when possible.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
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] debug compilation as default
On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Still unconvinced why we can't allow careful users to use environment variables for configuration. +1 We used that environment variables through out all the drlvm development - no single problem. Btw, FYI: Salikh is the author of previous build system which was used by drlvm before massive movement to the ant based unified build system of drlvm which is used now. -- Ivan - 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] debug compilation as default
Alexey Petrenko wrote: +1 for property files. The one of the main benefits for me is the possibility to define all the needed properties just once. But not execute a huge number of set SMTH and set ANOTHERTHING each time I open a new window or reboot my machine. That's why it is better to get proxy info from property file instead of setting ANT_OPTS variable :) http://issues.apache.org/jira/browse/HARMONY-523 It looks like the issue boils down to difference in habits. The java types prefer property files, because it saves them from working with incomprehensible environment variables and so on. But then, I am unix type, and having correctly defined environment is essential to me. I just keep my .profile file up-to-date, and don't care about setting it in a new window. It gets configured automatically. And I hate property files, because they cannot be configured in one central place, and I have to keep copying them over and over, and quickly get lost in a multitude of unsynchronized copies. Just another case of computing cultural differences. Anyway, I will lowly follow what the majority will decide as appropriate. - 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] debug compilation as default
Ivan Volosyuk wrote: On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Still unconvinced why we can't allow careful users to use environment variables for configuration. +1 We used that environment variables through out all the drlvm development - no single problem. Btw, FYI: Salikh is the author of previous build system which was used by drlvm before massive movement to the ant based unified build system of drlvm which is used now. is that old one still around? Does it use make? :) geir - 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] debug compilation as default
Salikh Zakirov wrote: Alexey Petrenko wrote: +1 for property files. The one of the main benefits for me is the possibility to define all the needed properties just once. But not execute a huge number of set SMTH and set ANOTHERTHING each time I open a new window or reboot my machine. That's why it is better to get proxy info from property file instead of setting ANT_OPTS variable :) http://issues.apache.org/jira/browse/HARMONY-523 It looks like the issue boils down to difference in habits. The java types prefer property files, because it saves them from working with incomprehensible environment variables and so on. Please. They are not incomprehensible. They are not portable, nor generally repeatable or visible as a reusable artifact. I've been a C type for about twice as long as I've been a Java type, and I'll point out that we C type people also prefer things in files, ex makefiles and scripts. But then, I am unix type, and having correctly defined environment is essential to me. I just keep my .profile file up-to-date, and don't care about setting it in a new window. It gets configured automatically. How do you do A/B test for different configurations? Different logins? Maybe reboot to another OS partition? And I hate property files, because they cannot be configured in one central place, and I have to keep copying them over and over, and quickly get lost in a multitude of unsynchronized copies. I'm sorry - I don't get it. Property files can *certainly* be configured in one central place, and there is no reason to copy over and over. As for unsynchronized copies, I think that comes down to work habit... Just another case of computing cultural differences. I don't think so. I've been a unix user and C programmer since the mid 1980's, and this has nothing to do w/ unix. geir - 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] debug compilation as default
On 7/17/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: On 7/17/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Still unconvinced why we can't allow careful users to use environment variables for configuration. +1 We used that environment variables through out all the drlvm development - no single problem. Btw, FYI: Salikh is the author of previous build system which was used by drlvm before massive movement to the ant based unified build system of drlvm which is used now. is that old one still around? Does it use make? :) Yes, it does use make both on windows (cygwin is required) and linux. It was removed completly from work tree, but can be possibly restored from archives. It can be out dated for now and also require some paperwork to be done. -- Ivan - 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] debug compilation as default
I have already implemented it using ant variables, look at the latest patch. You can use following notation with it: ant -Dhy.cfg=release I'm not sure the patch will apply cleanly, there was some changes in the makefiles since then. -- Ivan On 7/16/06, Thorbjørn Ravn Andersen [EMAIL PROTECTED] wrote: Ivan Volosyuk skrev den 10-07-2006 14:18: What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant This only works well under Unix. To my knowledge this is not immediately possible under Windows. The and properties should work everywhere. -- Thorbjørn -- Ivan Intel Middleware Products Division - 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] debug compilation as default
Ivan Volosyuk wrote: I have already implemented it using ant variables, look at the latest patch. You can use following notation with it: ant -Dhy.cfg=release I'm not sure the patch will apply cleanly, there was some changes in the makefiles since then. Now we're getting somewhere. I assume then I can put this into the build.properties that we'll be adding Real Soon Now (as I can never remember command line args anyway...) geir -- Ivan On 7/16/06, Thorbjørn Ravn Andersen [EMAIL PROTECTED] wrote: Ivan Volosyuk skrev den 10-07-2006 14:18: What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant This only works well under Unix. To my knowledge this is not immediately possible under Windows. The and properties should work everywhere. -- Thorbjørn - 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] debug compilation as default
Ivan Volosyuk skrev den 10-07-2006 14:18: What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant This only works well under Unix. To my knowledge this is not immediately possible under Windows. The and properties should work everywhere. -- Thorbjørn - 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] debug compilation as default
Mark Hindess wrote:
On 11 July 2006 at 16:42, Ivan Volosyuk [EMAIL PROTECTED] wrote:
[snip]
Working on it. Not sure I like the way make is called from ant build.
Here is an example:
(from modules/luni/build.xml)
target name=clean.native if=is.windows
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/vmi/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/luni/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/launcher/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/vmls/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
/target
This means that I should copy paste the environment variable from ant
variable conversion code in dozen of places. BTW, why the clean up is
just windows specific? What about Linux?
Good question. I look forward to Oliver's answer. ;-)
Thanks Mark ;) This is just a mistake Ive made in the Ant script - the
if=is.windows bit definitely shouldn't be there.
Shall I open a JIRA for it's removal, or are you happy to just take the if
test out Mark?
I'm going to create some kind of macro command which will include all
common settings for make execution. (/me is reading manuals)
Excellent idea. Something like (untested):
make dir=${hy.luni.src.main.native}/vmls/${hy.os} target=clean /
and:
macrodef name=make
attribute name=dir /
attribute name=target default= /
sequential
exec failonerror=true
executable=${make.command}
dir=@{dir}
env key=HY_HDK value=${hy.hdk} /
arg line=@{target} /
/exec
sequential
/macrodef
(You might have to make the default for target all.)
At the moment the only common file you could put this in is
properties.xml which isn't elegant but it might be okay for now. We
really need to have a common file that gets moved to the deploy tree -
like the make fragments.
That is definitely a good idea. I did it the long way because I don't really
know a great deal about Ant macros - I was more interested in getting it
working first, and was hoping that someone would come along and simplify
it later.
Regards,
Oliver
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
-
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] debug compilation as default
On 11 July 2006 at 13:56, Mark Hindess [EMAIL PROTECTED] wrote:
On 11 July 2006 at 16:42, Ivan Volosyuk [EMAIL PROTECTED] wrote:
[snip]
Working on it. Not sure I like the way make is called from ant build.
Here is an example:
(from modules/luni/build.xml)
target name=clean.native if=is.windows
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/vmi/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/luni/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/launcher/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/vmls/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
/target
This means that I should copy paste the environment variable from ant
variable conversion code in dozen of places. BTW, why the clean up is
just windows specific? What about Linux?
Good question. I look forward to Oliver's answer. ;-)
I'm going to create some kind of macro command which will include all
common settings for make execution. (/me is reading manuals)
Excellent idea. Something like (untested):
make dir=${hy.luni.src.main.native}/vmls/${hy.os} target=clean /
and:
macrodef name=make
attribute name=dir /
attribute name=target default= /
sequential
exec failonerror=true
executable=${make.command}
dir=@{dir}
env key=HY_HDK value=${hy.hdk} /
arg line=@{target} /
/exec
sequential
/macrodef
(You might have to make the default for target all.)
At the moment the only common file you could put this in is
properties.xml which isn't elegant but it might be okay for now. We
really need to have a common file that gets moved to the deploy tree -
like the make fragments.
Ivan,
I'm going to add something like this to svn shortly. I decided I should
fix the windows only clean in luni. And a couple of other issues.
-Mark.
-
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] debug compilation as default
On 11 July 2006 at 14:46, Mark Hindess [EMAIL PROTECTED] wrote:
On 11 July 2006 at 13:56, Mark Hindess [EMAIL PROTECTED] wrote:
On 11 July 2006 at 16:42, Ivan Volosyuk [EMAIL PROTECTED] wrote:
[snip]
Working on it. Not sure I like the way make is called from ant build.
Here is an example:
(from modules/luni/build.xml)
target name=clean.native if=is.windows
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/vmi/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/luni/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/launcher/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/vmls/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
/target
This means that I should copy paste the environment variable from ant
variable conversion code in dozen of places. BTW, why the clean up is
just windows specific? What about Linux?
Good question. I look forward to Oliver's answer. ;-)
I'm going to create some kind of macro command which will include all
common settings for make execution. (/me is reading manuals)
Excellent idea. Something like (untested):
make dir=${hy.luni.src.main.native}/vmls/${hy.os} target=clean /
and:
macrodef name=make
attribute name=dir /
attribute name=target default= /
sequential
exec failonerror=true
executable=${make.command}
dir=@{dir}
env key=HY_HDK value=${hy.hdk} /
arg line=@{target} /
/exec
sequential
/macrodef
(You might have to make the default for target all.)
At the moment the only common file you could put this in is
properties.xml which isn't elegant but it might be okay for now. We
really need to have a common file that gets moved to the deploy tree -
like the make fragments.
Ivan,
I'm going to add something like this to svn shortly. I decided I should
fix the windows only clean in luni. And a couple of other issues.
The make macro is in r420855.
Regards,
Mark.
-
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] debug compilation as default
On 7/11/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 11 July 2006 at 14:46, Mark Hindess [EMAIL PROTECTED] wrote:
On 11 July 2006 at 13:56, Mark Hindess [EMAIL PROTECTED] wrote:
On 11 July 2006 at 16:42, Ivan Volosyuk [EMAIL PROTECTED] wrote:
[snip]
Working on it. Not sure I like the way make is called from ant build.
Here is an example:
(from modules/luni/build.xml)
target name=clean.native if=is.windows
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/vmi/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/luni/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/launcher/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
exec failonerror=true
executable=${make.command}
dir=${hy.luni.src.main.native}/vmls/${hy.os}
env key=HY_HDK value=${hy.hdk} /
arg line=clean /
/exec
/target
This means that I should copy paste the environment variable from ant
variable conversion code in dozen of places. BTW, why the clean up is
just windows specific? What about Linux?
Good question. I look forward to Oliver's answer. ;-)
I'm going to create some kind of macro command which will include all
common settings for make execution. (/me is reading manuals)
Excellent idea. Something like (untested):
make dir=${hy.luni.src.main.native}/vmls/${hy.os} target=clean /
and:
macrodef name=make
attribute name=dir /
attribute name=target default= /
sequential
exec failonerror=true
executable=${make.command}
dir=@{dir}
env key=HY_HDK value=${hy.hdk} /
arg line=@{target} /
/exec
sequential
/macrodef
(You might have to make the default for target all.)
At the moment the only common file you could put this in is
properties.xml which isn't elegant but it might be okay for now. We
really need to have a common file that gets moved to the deploy tree -
like the make fragments.
Ivan,
I'm going to add something like this to svn shortly. I decided I should
fix the windows only clean in luni. And a couple of other issues.
The make macro is in r420855.
Regards,
Mark.
You have bit me. Here is my macro I was working on:
macrodef name=make
attribute name=dir/
attribute name=args default=/
sequential
echo message=hy.cfg=${hy.cfg}/
exec failonerror=true
executable=${make.command}
dir=${make.basedir}/@{dir}/${hy.os}
env key=HY_HDK value=${hy.hdk} /
env key=HY_CFG value=${hy.cfg} /
arg line=@{args} /
/exec
/sequential
/macrodef
This macro I decided to use has one difference in usage I wanted to push:
property name=make.basedir location=${hy.luni.src.main.native}/
make dir=vmi args=clean/
make dir=luni args=clean/
make dir=launcher args=clean/
make dir=vmls args=clean/
In this notation it looks a bit more readable.
--
Ivan
Intel Middleware Products Division
-
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] debug compilation as default
--- Ivan Volosyuk [EMAIL PROTECTED] wrote:
[SNIP]
This macro I decided to use has one difference in
usage I wanted to push:
property name=make.basedir
location=${hy.luni.src.main.native}/
make dir=vmi args=clean/
make dir=luni args=clean/
make dir=launcher args=clean/
make dir=vmls args=clean/
I like the macro. Or make-ro. Anyway, as make is
imported from a common build (fragment) file I would
discourage its relying on a property. You _could_,
however, use a local nested macrodef:
macrodef name=nativemake
attribute name=dir /
attribute name=target default= /
sequential
make dir=${hy.luni.src.main.native}/@{dir}
target=@{target} /
/sequential
/macrodef
It kind of seems an equal trade in terms of noise,
though. :)
-Matt
In this notation it looks a bit more readable.
--
Ivan
Intel Middleware Products Division
-
Terms of use :
http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
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] debug compilation as default
On 11 July 2006 at 8:37, Matt Benson [EMAIL PROTECTED] wrote:
--- Ivan Volosyuk [EMAIL PROTECTED] wrote:
[SNIP]
This macro I decided to use has one difference in
usage I wanted to push:
property name=make.basedir
location=${hy.luni.src.main.native}/
make dir=vmi args=clean/
make dir=luni args=clean/
make dir=launcher args=clean/
make dir=vmls args=clean/
I like the macro. Or make-ro. Anyway, as make is
imported from a common build (fragment) file I would
discourage its relying on a property.
That was my feeling too though I couldn't think of any ways it could
go horribly wrong at present.
You _could_, however, use a local nested macrodef:
macrodef name=nativemake
attribute name=dir /
attribute name=target default= /
sequential
make dir=${hy.luni.src.main.native}/@{dir}
target=@{target} /
/sequential
/macrodef
It kind of seems an equal trade in terms of noise,
though. :)
Agreed. I think I'll leave it as is.
-Mark.
-
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] debug compilation as default
On 7/11/06, Matt Benson [EMAIL PROTECTED] wrote:
--- Ivan Volosyuk [EMAIL PROTECTED] wrote:
[SNIP]
This macro I decided to use has one difference in
usage I wanted to push:
property name=make.basedir
location=${hy.luni.src.main.native}/
make dir=vmi args=clean/
make dir=luni args=clean/
make dir=launcher args=clean/
make dir=vmls args=clean/
I like the macro. Or make-ro. Anyway, as make is
imported from a common build (fragment) file I would
discourage its relying on a property. You _could_,
however, use a local nested macrodef:
macrodef name=nativemake
attribute name=dir /
attribute name=target default= /
sequential
make dir=${hy.luni.src.main.native}/@{dir}
target=@{target} /
/sequential
/macrodef
It kind of seems an equal trade in terms of noise,
though. :)
Nevermind. It is now much better then before.
I have updated patch for debug / release switching in natives build.
Please look at http://issues.apache.org/jira/browse/HARMONY-803
--
Ivan
Intel Middleware Products Division
-
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] debug compilation as default
On 7/9/06, Mark Hindess [EMAIL PROTECTED] wrote: On 8 July 2006 at 19:13, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= [EMAIL PROTECTED] wrote: Ivan Volosyuk skrev den 08-07-2006 00:35: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. Personally I think that it will be easier to use other C IDE's if the project uses Makefiles since that is what historically has been used for that purpose. Make and ant are to me very different in how you think when using it - make is in terms of creating rules for deriving file(s) from other file(s), where ant describes tasks. I think it is fine to use ant to invoke the global build, but that make should be used for the C build. Perhaps ant can build the configuration files used by make? Something similar to what configure does? No. I think we should just invoke configure not re-invent it in ant. The point is that if/when we change from using raw make to using configure the developer running ant at the top-level (or module level) shouldn't care how, for example: ant -Dbuild.cfg=release and: ant -Dbuild.cfg=debug is implemented underneath. Regards, Mark. Mark, What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant When we will (possibly) move to 'configure and make' we can do the changes in ant build files to keep _this_ interface. For now, this interface require 'zero' intrusion into ant build system, as the environment variable simply go into makefile. I do not especially insist in current form, we can do it this way either: ant -Dbuild.cfg=release I think it is trivial to do, but I just want to understand the benifits of this solution. If the influence from ant-build-system minimal, people who deals with makefiles can just keep in mind the things they want to do in makefiles and ignore all of the build layers above. It is much easier. As I know humans mind can handle about 7 different types of entities at once. Let's keep it simple. -- Ivan - 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] debug compilation as default
On 10 July 2006 at 16:18, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/9/06, Mark Hindess [EMAIL PROTECTED] wrote: On 8 July 2006 at 19:13, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= thunde [EMAIL PROTECTED] wrote: Ivan Volosyuk skrev den 08-07-2006 00:35: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. Personally I think that it will be easier to use other C IDE's if the project uses Makefiles since that is what historically has been used for that purpose. Make and ant are to me very different in how you think when using it - make is in terms of creating rules for deriving file(s) from other file(s), where ant describes tasks. I think it is fine to use ant to invoke the global build, but that make should be used for the C build. Perhaps ant can build the configuration files used by make? Something similar to what configure does? No. I think we should just invoke configure not re-invent it in ant. The point is that if/when we change from using raw make to using configure the developer running ant at the top-level (or module level) shouldn't care how, for example: ant -Dbuild.cfg=release and: ant -Dbuild.cfg=debug is implemented underneath. Regards, Mark. Mark, What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant Consistency? All the other variables that affect the classlib build are ant properties. Since you went with the name build_cfg (although I suggested something specific to the natives) this seemed generic enough that the value of this property would likely affect the java parts of the build at a later date. Classlib doesn't use environment variables for any of the top-level interface. (It does use them when it invokes the native build however it only *sets* environment variables it never reads them.) Ant property behaviour is much more well-defined. Environment variables are horribly platform dependent. (If you read back in the archives you'll find a number of discussions about the problems with the interface between case-insensitive environment variables on windows and the case-sensitive properties in ant.) There is also much more flexibility in ant regarding how properties are passed down the tree from ant. This flexibility will be useful when we have a top-level federation build - that I think should be written using ant. (I don't like the use of build.sh and build.bat in drlvm and would rather use on platform-independent script. Ant seems like a reasonable choice.) When we will (possibly) move to 'configure and make' we can do the changes in ant build files to keep _this_ interface. For now, this interface require 'zero' intrusion into ant build system, as the environment variable simply go into makefile. Great. The interface I'm suggesting has this useful property as well. I do not especially insist in current form, we can do it this way either: ant -Dbuild.cfg=release I think it is trivial to do, but I just want to understand the benifits of this solution. If the influence from ant-build-system minimal, people who deals with makefiles can just keep in mind the things they want to do in makefiles and ignore all of the build layers above. It is much easier. As I know humans mind can handle about 7 different types of entities at once. Let's keep it simple. I don't see the relevance of this. The ant variable will be passed to the native make/configure as an environment variable so the concepts that need to be handled at that level are exactly the same. And as I outlined originally this is exactly the same as the hy.hdk/HY_HDK variable that developers already handle. I've not heard anyone reporting confusion about this. Regards, Mark. - 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] debug compilation as default
On 7/10/06, Mark Hindess [EMAIL PROTECTED] wrote: On 10 July 2006 at 16:18, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/9/06, Mark Hindess [EMAIL PROTECTED] wrote: On 8 July 2006 at 19:13, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= thunde [EMAIL PROTECTED] wrote: Ivan Volosyuk skrev den 08-07-2006 00:35: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. Personally I think that it will be easier to use other C IDE's if the project uses Makefiles since that is what historically has been used for that purpose. Make and ant are to me very different in how you think when using it - make is in terms of creating rules for deriving file(s) from other file(s), where ant describes tasks. I think it is fine to use ant to invoke the global build, but that make should be used for the C build. Perhaps ant can build the configuration files used by make? Something similar to what configure does? No. I think we should just invoke configure not re-invent it in ant. The point is that if/when we change from using raw make to using configure the developer running ant at the top-level (or module level) shouldn't care how, for example: ant -Dbuild.cfg=release and: ant -Dbuild.cfg=debug is implemented underneath. Regards, Mark. Mark, What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant Consistency? All the other variables that affect the classlib build are ant properties. Since you went with the name build_cfg (although I suggested something specific to the natives) this seemed generic enough that the value of this property would likely affect the java parts of the build at a later date. Classlib doesn't use environment variables for any of the top-level interface. (It does use them when it invokes the native build however it only *sets* environment variables it never reads them.) Ant property behaviour is much more well-defined. Environment variables are horribly platform dependent. (If you read back in the archives you'll find a number of discussions about the problems with the interface between case-insensitive environment variables on windows and the case-sensitive properties in ant.) There is also much more flexibility in ant regarding how properties are passed down the tree from ant. This flexibility will be useful when we have a top-level federation build - that I think should be written using ant. (I don't like the use of build.sh and build.bat in drlvm and would rather use on platform-independent script. Ant seems like a reasonable choice.) When we will (possibly) move to 'configure and make' we can do the changes in ant build files to keep _this_ interface. For now, this interface require 'zero' intrusion into ant build system, as the environment variable simply go into makefile. Great. The interface I'm suggesting has this useful property as well. Yes, but there is an intrusion to ant build system. The property goes through some transformations inside ant build system. People should look through ant files to know exact flow of variable name. I do not especially insist in current form, we can do it this way either: ant -Dbuild.cfg=release I think it is trivial to do, but I just want to understand the benifits of this solution. If the influence from ant-build-system minimal, people who deals with makefiles can just keep in mind the things they want to do in makefiles and ignore all of the build layers above. It is much easier. As I know humans mind can handle about 7 different types of entities at once. Let's keep it simple. I don't see the relevance of this. The ant variable will be passed to the native make/configure as an environment variable so the concepts that need to be handled at that level are exactly the same. And as I outlined originally this is exactly the same as the hy.hdk/HY_HDK variable that developers already handle. I've not heard anyone reporting confusion about this. Well. There is not a big deal. I can do this in following way: If the BUILD_CFG environment variable exists it will be converted to ant variable build.cfg. Ant variable can be also set via -Dbuild.cfg=release directive. The ant variable will be converted to BUILD_CFG environment variable when calling makefile. Does it looks ok for you? -- Ivan - 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] debug compilation as default
On 10 July 2006 at 19:11, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/10/06, Mark Hindess [EMAIL PROTECTED] wrote: On 10 July 2006 at 16:18, Ivan Volosyuk [EMAIL PROTECTED] wrote: Mark, What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant Consistency? All the other variables that affect the classlib build are ant properties. Since you went with the name build_cfg (although I suggested something specific to the natives) this seemed generic enough that the value of this property would likely affect the java parts of the build at a later date. Classlib doesn't use environment variables for any of the top-level interface. (It does use them when it invokes the native build however it only *sets* environment variables it never reads them.) Ant property behaviour is much more well-defined. Environment variables are horribly platform dependent. (If you read back in the archives you'll find a number of discussions about the problems with the interface between case-insensitive environment variables on windows and the case-sensitive properties in ant.) There is also much more flexibility in ant regarding how properties are passed down the tree from ant. This flexibility will be useful when we have a top-level federation build - that I think should be written using ant. (I don't like the use of build.sh and build.bat in drlvm and would rather use on platform-independent script. Ant seems like a reasonable choice.) When we will (possibly) move to 'configure and make' we can do the changes in ant build files to keep _this_ interface. For now, this interface require 'zero' intrusion into ant build system, as the environment variable simply go into makefile. Great. The interface I'm suggesting has this useful property as well. Yes, but there is an intrusion to ant build system. The property goes through some transformations inside ant build system. People should look through ant files to know exact flow of variable name. You gave it a generic name - not just a native specific one - so it is fair to assume that it might (one day) affect other things. So, yes, it would be wise to look at what happens in the ant files since it might affect something else - like the java code. Only if it had a native specific name would it be reasonable to assume it didn't affect anything else. This is equally true whether it is an environment variable or an ant property. I do not especially insist in current form, we can do it this way either: ant -Dbuild.cfg=release I think it is trivial to do, but I just want to understand the benifits of this solution. If the influence from ant-build-system minimal, people who deals with makefiles can just keep in mind the things they want to do in makefiles and ignore all of the build layers above. It is much easier. As I know humans mind can handle about 7 different types of entities at once. Let's keep it simple. I don't see the relevance of this. The ant variable will be passed to the native make/configure as an environment variable so the concepts that need to be handled at that level are exactly the same. And as I outlined originally this is exactly the same as the hy.hdk/HY_HDK variable that developers already handle. I've not heard anyone reporting confusion about this. Well. There is not a big deal. I can do this in following way: If the BUILD_CFG environment variable exists it will be converted to ant variable build.cfg. We don't need the environment variable. Nothing else in the Harmony classlib uses them - reads them - for reasons I stated previously. I'm not going to start adding them with no justification. (Incidentally because it is used by drlvm isn't a justification. I don't think it is a good idea there either but now is not the time for that discussion.) Ant variable can be also set via -Dbuild.cfg=release directive. The ant variable will be converted to BUILD_CFG environment variable when calling makefile. This part is ok. Does it looks ok for you? Almost. Regards, Mark. - 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] debug compilation as default
On the 0x1A1 day of Apache Harmony Mark Hindess wrote: On 8 July 2006 at 1:35, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 21:29, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 The DEFINES and INCLUDES is exactly the kind of thing I was thinking about. However: 1) I think we've somehow lost the default '-O1' option Yes. I'll fix it. 2) I think the $(shell uname -m) is overkill, we'll handle this a better way when the time comes in the meantime forking/execing sh and uname for each call to make is just overhead. I know that fork/exec operation is quite efficient on linux, more over the compilation of sources uses much more time. But it always returns the same result, for any valid architecture that we can build on, so why not just leave it out for now? As a general rule, we add complexity when we need it not before we need it without any discussion/justification. I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. Sorry, but I don't like this for reasons I discussed yesterday. It was late and I guess I wasn't clear enough. It should be done via ant because ant is the interface that developers should be using to execute the build - either using the top-level ant file or the module ant file (or via some federation calling ant). Even if they are only building native code in a module developers should still use the ant file. Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) (I don't think it helps clarify the issue, but for the record, I'm a C programmer and Perl hacker. I don't particularly like make or ant. I like using the right tool for the job.) For the more record, I am a C programmer too :) And not scared of 'ant' :) Except one thing: let's do the *parallel build feature*. It is a real pleasure to use it with 'make'! Harmony Classlib is primarily a Java project that includes a little C code[1]. The build is kicked off with ant so ant is the primary *interface* for developers, are you suggesting we change the top-level interface to make? It still uses make for the C underneath so as not to scare off C developers when they work at that level but they are always encouraged to kick off the build via ant for consistency. If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. No. As you say C programmers prefer tools like make (and configure) so we decided a while ago to stick to tools that matched expectations (for the implementation but not the interface). I'm not arguing that we should use *ant* for the *implementation* of the C code building just that ant is the *interface*. We may change[0] the way native code is built if handle things like this configuration issue via ant then the interface for developers can remain the same even when we change what happens under the covers. Regards, Mark. [0] Probably sooner rather than later if we start ports to other platforms. Regards, Mark [1] Arguably as little as we can get away with because we believe that in the long term the JIT will do better than a compiler when it comes to optimisation. Mark, do you mean that the JIT should be better than what it is? :) -- Egor Pasko, Intel Managed Runtime Division - 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] debug compilation as default
Ivan Volosyuk skrev den 08-07-2006 00:35: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. Personally I think that it will be easier to use other C IDE's if the project uses Makefiles since that is what historically has been used for that purpose. Make and ant are to me very different in how you think when using it - make is in terms of creating rules for deriving file(s) from other file(s), where ant describes tasks. I think it is fine to use ant to invoke the global build, but that make should be used for the C build. Perhaps ant can build the configuration files used by make? Something similar to what configure does? -- Thorbjørn - 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] debug compilation as default
Ivan Volosyuk wrote: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) I am both, and I like using both for different things. If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. I personally am against using cpptask, and hope we soon get around to fixing drlvm's build system to use make. Actually, I'd prefer that we use a conventional configure script to get some help w/ platform specifics for the build. geir - 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] debug compilation as default
Thorbjørn Ravn Andersen wrote: Ivan Volosyuk skrev den 08-07-2006 00:35: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. Personally I think that it will be easier to use other C IDE's if the project uses Makefiles since that is what historically has been used for that purpose. Make and ant are to me very different in how you think when using it - make is in terms of creating rules for deriving file(s) from other file(s), where ant describes tasks. I think it is fine to use ant to invoke the global build, but that make should be used for the C build. Perhaps ant can build the configuration files used by make? Something similar to what configure does? Or just use configure :) geir - 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] debug compilation as default
Geir Magnusson Jr wrote: Ivan Volosyuk wrote: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) I am both, and I like using both for different things. If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. I personally am against using cpptask, and hope we soon get around to fixing drlvm's build system to use make. Actually, I'd prefer that we use a conventional configure script to get some help w/ platform specifics for the build. Me too. Having the top-level ant script invoke configure and make with default options is fine too, to tie it all together; but as we have written before there are a number of benefits to using the tools most commonly associated with each language. Regards, Tim -- 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] debug compilation as default
On 8 July 2006 at 1:35, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 21:29, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 The DEFINES and INCLUDES is exactly the kind of thing I was thinking about. However: 1) I think we've somehow lost the default '-O1' option Yes. I'll fix it. 2) I think the $(shell uname -m) is overkill, we'll handle this a better way when the time comes in the meantime forking/execing sh and uname for each call to make is just overhead. I know that fork/exec operation is quite efficient on linux, more over the compilation of sources uses much more time. But it always returns the same result, for any valid architecture that we can build on, so why not just leave it out for now? As a general rule, we add complexity when we need it not before we need it without any discussion/justification. I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. Sorry, but I don't like this for reasons I discussed yesterday. It was late and I guess I wasn't clear enough. It should be done via ant because ant is the interface that developers should be using to execute the build - either using the top-level ant file or the module ant file (or via some federation calling ant). Even if they are only building native code in a module developers should still use the ant file. Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) (I don't think it helps clarify the issue, but for the record, I'm a C programmer and Perl hacker. I don't particularly like make or ant. I like using the right tool for the job.) Harmony Classlib is primarily a Java project that includes a little C code[1]. The build is kicked off with ant so ant is the primary *interface* for developers, are you suggesting we change the top-level interface to make? It still uses make for the C underneath so as not to scare off C developers when they work at that level but they are always encouraged to kick off the build via ant for consistency. If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. No. As you say C programmers prefer tools like make (and configure) so we decided a while ago to stick to tools that matched expectations (for the implementation but not the interface). I'm not arguing that we should use *ant* for the *implementation* of the C code building just that ant is the *interface*. We may change[0] the way native code is built if handle things like this configuration issue via ant then the interface for developers can remain the same even when we change what happens under the covers. Regards, Mark. [0] Probably sooner rather than later if we start ports to other platforms. Regards, Mark [1] Arguably as little as we can get away with because we believe that in the long term the JIT will do better than a compiler when it comes to optimisation. - 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] debug compilation as default
On 8 July 2006 at 19:13, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= [EMAIL PROTECTED] wrote: Ivan Volosyuk skrev den 08-07-2006 00:35: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. Personally I think that it will be easier to use other C IDE's if the project uses Makefiles since that is what historically has been used for that purpose. Make and ant are to me very different in how you think when using it - make is in terms of creating rules for deriving file(s) from other file(s), where ant describes tasks. I think it is fine to use ant to invoke the global build, but that make should be used for the C build. Perhaps ant can build the configuration files used by make? Something similar to what configure does? No. I think we should just invoke configure not re-invent it in ant. The point is that if/when we change from using raw make to using configure the developer running ant at the top-level (or module level) shouldn't care how, for example: ant -Dbuild.cfg=release and: ant -Dbuild.cfg=debug is implemented underneath. Regards, Mark. - 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] debug compilation as default
On 7 July 2006 at 2:25, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Friday 07 July 2006 01:28 Ivan Volosyuk wrote: I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. The names are not important, they could be changed in drlvm build as well if we find those that most of us like. I think word native is ok or there may be a confusion that the same rule applies to java sources (this of course depends on what hy.native.cfg, be it compilation flags, then it should not apply to java, or just debug/release, then it is ok for java). Well, I will stick to corresponding names from drlvm then. Somebody who will commit the changes can rename both of them if needed. Not sure how this follows from what Gregory wrote. I still think (as Gregory suggested above) if it only affects native code it should include the word native. Or are you going to modify how the corresponding hy.javac.debug flags is derived? Personally, I think the hy.native.cfg variable is more in keeping with the existing variables - e.g. hy.javac.*. If we decide to modify the way hy.javac.debug is setup then perhaps we could use something without native in the name but I think that is out of scope of the current change. 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. I would also like to have CFLAGS and LDFLAGS to be used in the defines.mak. People can set corresponding environment variables for extra compiler switches they want. This seems like a separate issue. I think that #4 covers this. 4) breaking up the existing flags variables and defining them in terms of separate defines for different types of flags CFG flags, warning flags, etc. Could you reformulate this, I think I not quite catch the idea. This is something that I was thinking about, separate groups of flags for debug info control, optimization flags, warning level and just user additional flags (which should probably go the last to take the precedence). (hopefully I clarified this paragraph correctly for Ivan from how I understood it myself) Yes. Gregory's interpretation was accurate. I will do that as I understood :) Great, but please use variable names in keeping with what is in classlib already unless you want to have the discussion about renaming all of the classlib variables. Personally I'd leave that issue to another day. ;-) Regards, Mark. - 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] debug compilation as default
On 6 July 2006 at 23:42, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: I can make this patch. One question, is it ok to have same property as DRLVM for release mode? Like this: BUILD_CFG=release I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I'm perfectly happy w/ this at high level. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml 2) converting this in to an environment variable so what like hy.hdk gets converted to HY_HDK. Can we please stop with this HY stuff? The project is Harmony. I'm only going along with what is already there. IMHO, it would be even worse to have some hy varaibles and some harmony variables. Changing them all is definitely out-of-scope for this specific problem. Personally, I really don't care either way. (I'll just put an entry in the global-abbrev-table in emacs to expand hy to harmony. ;-) 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. 4) breaking up the existing flags variables and defining them in terms of separate defines for different types of flags CFG flags, warning flags, etc. That's just my first thoughts I'd might not end up doing it quite like that if I actually tried to do it. ;-) Is that overspecifying it for a first run? Just having debug/release would be cool to start. Perhaps a little. You need to do 3) and at least enough of 4) to extract the debug/optimization options but you could leave the remainder in a single variable. Regards, Mark. - 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] debug compilation as default
On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. -- Regards, Ivan - 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] debug compilation as default
On 7 July 2006 at 21:29, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 The DEFINES and INCLUDES is exactly the kind of thing I was thinking about. However: 1) I think we've somehow lost the default '-O1' option 2) I think the $(shell uname -m) is overkill, we'll handle this a better way when the time comes in the meantime forking/execing sh and uname for each call to make is just overhead. I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. Sorry, but I don't like this for reasons I discussed yesterday. It was late and I guess I wasn't clear enough. It should be done via ant because ant is the interface that developers should be using to execute the build - either using the top-level ant file or the module ant file (or via some federation calling ant). Even if they are only building native code in a module developers should still use the ant file. We may change[0] the way native code is built if handle things like this configuration issue via ant then the interface for developers can remain the same even when we change what happens under the covers. Regards, Mark. [0] Probably sooner rather than later if we start ports to other platforms. - 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] debug compilation as default
On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 21:29, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 The DEFINES and INCLUDES is exactly the kind of thing I was thinking about. However: 1) I think we've somehow lost the default '-O1' option Yes. I'll fix it. 2) I think the $(shell uname -m) is overkill, we'll handle this a better way when the time comes in the meantime forking/execing sh and uname for each call to make is just overhead. I know that fork/exec operation is quite efficient on linux, more over the compilation of sources uses much more time. I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. Sorry, but I don't like this for reasons I discussed yesterday. It was late and I guess I wasn't clear enough. It should be done via ant because ant is the interface that developers should be using to execute the build - either using the top-level ant file or the module ant file (or via some federation calling ant). Even if they are only building native code in a module developers should still use the ant file. Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. We may change[0] the way native code is built if handle things like this configuration issue via ant then the interface for developers can remain the same even when we change what happens under the covers. Regards, Mark. [0] Probably sooner rather than later if we start ports to other platforms. -- Ivan Intel Middleware Products Division - 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] debug compilation as default
On 5 July 2006 at 19:46, Geir Magnusson Jr [EMAIL PROTECTED] wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? I looked at this patch and thought the same thing. It should be quite easy to add an ant property that gets converted to an environment variable[0] - as hy.hdk does - that gets added to the *FLAGS. And the patch was right, it should default to debug on. Regards, -Mark. [0] Maybe two - one for compilation and one for linking. - 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] debug compilation as default
Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive Don't mistake being simple with being primitive g. It will need to grow as we expand the amount of platform-dependent code, but I suggest we try to keep things as simple as possible. which is easy to alter by developers locally but isn't really meant to be a product build system. What do you mean? But the default I am sure should be debug everywhere, VM, classlib, tools until Harmony leaves the incubation state. I don't think it is tied to project incubation, but I agree that we need a switch that allows debug/release compilation. And if it is debug by default that is fine too. This is what my patch did (if I didn't miss some places in classlib makefiles). Add release switch later when it is needed. Now... is it important to have it? Is it necessary to build classlib even with -mpentium3? I don't think so. That's a different topic -- we should decide which architectures are 'officially' supported. Regards, Tim -- 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] debug compilation as default
On Thursday 06 July 2006 20:20 Tim Ellison wrote: Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive Btw no offense intended I meant only native part of the build system. Java part is fine to me. I think I didn't understand the original question well enough. Sure I think it would be good to have more than one mode to build native sources. Don't mistake being simple with being primitive g. It will need to grow as we expand the amount of platform-dependent code, but I suggest we try to keep things as simple as possible. which is easy to alter by developers locally but isn't really meant to be a product build system. What do you mean? (I'll try to answer both your and Geir's question here) The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. -- Gregory Shimansky, Intel Middleware Products Division - 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] debug compilation as default
Gregory Shimansky wrote: (I'll try to answer both your and Geir's question here) The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Ah, I understand -- yes I agree. Thanks for the clarification. Regards, Tim -- 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] debug compilation as default
Gregory Shimansky wrote: On Thursday 06 July 2006 20:20 Tim Ellison wrote: Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive Btw no offense intended I meant only native part of the build system. Java part is fine to me. I think I didn't understand the original question well enough. Sure I think it would be good to have more than one mode to build native sources. Don't mistake being simple with being primitive g. It will need to grow as we expand the amount of platform-dependent code, but I suggest we try to keep things as simple as possible. which is easy to alter by developers locally but isn't really meant to be a product build system. What do you mean? (I'll try to answer both your and Geir's question here) The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. Right - the argument we're making is that we don't want to have the same problem in reverse via the debug settings. We want to just do this right and have a settable property somewhere, and yes, debug as default is fine. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. But we don't. we agree it's a good default, but a little extra work will just do it via a user-specified property. Patch welcome :) geir - 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] debug compilation as default
On 6 July 2006 at 21:37, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 20:20 Tim Ellison wrote: Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive Btw no offense intended I meant only native part of the build system. Java part is fine to me. None taken. Personally, I think primitive in the sense of not yet evolved is precisely what it is. At the moment, it does the job. However, I've hacked the CFLAGS more than once so it's definitely time it evolved a little. I think I didn't understand the original question well enough. Sure I think it would be good to have more than one mode to build native sources. Don't mistake being simple with being primitive g. It will need to grow as we expand the amount of platform-dependent code, but I suggest we try to keep things as simple as possible. which is easy to alter by developers locally but isn't really meant to be a product build system. What do you mean? (I'll try to answer both your and Geir's question here) The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. Regards, Mark. - 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] debug compilation as default
On Thursday 06 July 2006 23:06 Mark Hindess wrote: The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? For my personal needs so far I've just added debug everywhere. And while we're talking about debugging, optimizing compilers can add debugging information while doing optimizations, when debugging this code many statements may be shifted. So for good debugging there should be no optimization -O0 for gcc and -Od for mscv. If debugging is the default mode it would be good to have it unoptimized as well. To make Tim happy and make it simple I think there should be just two modes, development debug which is the default and high performance release without debug information and optimized. For fine optimization tuning the optimization flags could be moved into separate set which could be altered from ant property or environment, but I am not sure this is needed yet. There is one more thing which has to be mentioned, on win32 linker creates .pdb files for .dll and .exe which actually contain the debug information. They have to be copied to the same directory as the .dll/.exe file to make it available. So on windows they'll have to be copied to the deploy dir. Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. Yes, but this will replace -I and -L flags as well so matching them in environment may be less convenient than just to edit the file to change just a few of them. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. Sure, that is what I meant when writing when needed. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. While I'd really like to help I'll be away from Harmony participation because I go on 2 weeks vacations. If by the time I return I won't be satisfied I'll surely make a patch :) -- Gregory Shimansky, Intel Middleware Products Division - 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] debug compilation as default
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 23:06 Mark Hindess wrote: The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? For my personal needs so far I've just added debug everywhere. And while we're talking about debugging, optimizing compilers can add debugging information while doing optimizations, when debugging this code many statements may be shifted. So for good debugging there should be no optimization -O0 for gcc and -Od for mscv. If debugging is the default mode it would be good to have it unoptimized as well. To make Tim happy and make it simple I think there should be just two modes, development debug which is the default and high performance release without debug information and optimized. For fine optimization tuning the optimization flags could be moved into separate set which could be altered from ant property or environment, but I am not sure this is needed yet. There is one more thing which has to be mentioned, on win32 linker creates .pdb files for .dll and .exe which actually contain the debug information. They have to be copied to the same directory as the .dll/.exe file to make it available. So on windows they'll have to be copied to the deploy dir. Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. Yes, but this will replace -I and -L flags as well so matching them in environment may be less convenient than just to edit the file to change just a few of them. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. Sure, that is what I meant when writing when needed. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. While I'd really like to help I'll be away from Harmony participation because I go on 2 weeks vacations. If by the time I return I won't be satisfied I'll surely make a patch :) I can make this patch. One question, is it ok to have same property as DRLVM for release mode? Like this: BUILD_CFG=release -- Ivan Intel Middleware Products Division - 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] debug compilation as default
On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 23:06 Mark Hindess wrote: The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? For my personal needs so far I've just added debug everywhere. And while we're talking about debugging, optimizing compilers can add debugging information while doing optimizations, when debugging this code many statements may be shifted. So for good debugging there should be no optimization -O0 for gcc and -Od for mscv. If debugging is the default mode it would be good to have it unoptimized as well. To make Tim happy and make it simple I think there should be just two modes, development debug which is the default and high performance release without debug information and optimized. For fine optimization tuning the optimization flags could be moved into separate set which could be altered from ant property or environment, but I am not sure this is needed yet. There is one more thing which has to be mentioned, on win32 linker creates .pdb files for .dll and .exe which actually contain the debug information. They have to be copied to the same directory as the .dll/.exe file to make it available. So on windows they'll have to be copied to the deploy dir. Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. Yes, but this will replace -I and -L flags as well so matching them in environment may be less convenient than just to edit the file to change just a few of them. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. Sure, that is what I meant when writing when needed. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. While I'd really like to help I'll be away from Harmony participation because I go on 2 weeks vacations. If by the time I return I won't be satisfied I'll surely make a patch :) ;-) Have a good vacation. I can make this patch. One question, is it ok to have same property as DRLVM for release mode? Like this: BUILD_CFG=release I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml 2) converting this in to an environment variable so what like hy.hdk gets converted to HY_HDK. 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. 4) breaking up the existing flags variables and defining them in terms of separate defines for different types of flags CFG flags, warning flags, etc. That's just my first thoughts I'd might not end up doing it quite like that if I actually tried to do it. ;-) Regards, Mark. - 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] debug compilation as default
On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 23:06 Mark Hindess wrote: The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? For my personal needs so far I've just added debug everywhere. And while we're talking about debugging, optimizing compilers can add debugging information while doing optimizations, when debugging this code many statements may be shifted. So for good debugging there should be no optimization -O0 for gcc and -Od for mscv. If debugging is the default mode it would be good to have it unoptimized as well. To make Tim happy and make it simple I think there should be just two modes, development debug which is the default and high performance release without debug information and optimized. For fine optimization tuning the optimization flags could be moved into separate set which could be altered from ant property or environment, but I am not sure this is needed yet. There is one more thing which has to be mentioned, on win32 linker creates .pdb files for .dll and .exe which actually contain the debug information. They have to be copied to the same directory as the .dll/.exe file to make it available. So on windows they'll have to be copied to the deploy dir. Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. Yes, but this will replace -I and -L flags as well so matching them in environment may be less convenient than just to edit the file to change just a few of them. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. Sure, that is what I meant when writing when needed. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. While I'd really like to help I'll be away from Harmony participation because I go on 2 weeks vacations. If by the time I return I won't be satisfied I'll surely make a patch :) ;-) Have a good vacation. I can make this patch. One question, is it ok to have same property as DRLVM for release mode? Like this: BUILD_CFG=release I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. 2) converting this in to an environment variable so what like hy.hdk gets converted to HY_HDK. Sure. 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. I would also like to have CFLAGS and LDFLAGS to be used in the defines.mak.
Re: [classlib] debug compilation as default
On Friday 07 July 2006 01:28 Ivan Volosyuk wrote: I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. The names are not important, they could be changed in drlvm build as well if we find those that most of us like. I think word native is ok or there may be a confusion that the same rule applies to java sources (this of course depends on what hy.native.cfg, be it compilation flags, then it should not apply to java, or just debug/release, then it is ok for java). 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. I would also like to have CFLAGS and LDFLAGS to be used in the defines.mak. People can set corresponding environment variables for extra compiler switches they want. I think that #4 covers this. 4) breaking up the existing flags variables and defining them in terms of separate defines for different types of flags CFG flags, warning flags, etc. Could you reformulate this, I think I not quite catch the idea. This is something that I was thinking about, separate groups of flags for debug info control, optimization flags, warning level and just user additional flags (which should probably go the last to take the precedence). (hopefully I clarified this paragraph correctly for Ivan from how I understood it myself) +1 for #1, #2, #3 and #4 in my interpretation. -- Gregory Shimansky, Intel Middleware Products Division - 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] debug compilation as default
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Friday 07 July 2006 01:28 Ivan Volosyuk wrote: I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. The names are not important, they could be changed in drlvm build as well if we find those that most of us like. I think word native is ok or there may be a confusion that the same rule applies to java sources (this of course depends on what hy.native.cfg, be it compilation flags, then it should not apply to java, or just debug/release, then it is ok for java). Well, I will stick to corresponding names from drlvm then. Somebody who will commit the changes can rename both of them if needed. 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. I would also like to have CFLAGS and LDFLAGS to be used in the defines.mak. People can set corresponding environment variables for extra compiler switches they want. I think that #4 covers this. 4) breaking up the existing flags variables and defining them in terms of separate defines for different types of flags CFG flags, warning flags, etc. Could you reformulate this, I think I not quite catch the idea. This is something that I was thinking about, separate groups of flags for debug info control, optimization flags, warning level and just user additional flags (which should probably go the last to take the precedence). (hopefully I clarified this paragraph correctly for Ivan from how I understood it myself) I will do that as I understood :) +1 for #1, #2, #3 and #4 in my interpretation. -- Ivan Intel Middleware Products Division - 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] debug compilation as default
Mark Hindess wrote: On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: I can make this patch. One question, is it ok to have same property as DRLVM for release mode? Like this: BUILD_CFG=release I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I'm perfectly happy w/ this at high level. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml 2) converting this in to an environment variable so what like hy.hdk gets converted to HY_HDK. Can we please stop with this HY stuff? The project is Harmony. 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. 4) breaking up the existing flags variables and defining them in terms of separate defines for different types of flags CFG flags, warning flags, etc. That's just my first thoughts I'd might not end up doing it quite like that if I actually tried to do it. ;-) Is that overspecifying it for a first run? Just having debug/release would be cool to start. geir - 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] debug compilation as default
Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] debug compilation as default
In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? geir - 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] debug compilation as default
On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive which is easy to alter by developers locally but isn't really meant to be a product build system. But the default I am sure should be debug everywhere, VM, classlib, tools until Harmony leaves the incubation state. This is what my patch did (if I didn't miss some places in classlib makefiles). Add release switch later when it is needed. Now... is it important to have it? Is it necessary to build classlib even with -mpentium3? I don't think so. -- Gregory Shimansky, Intel Middleware Products Division - 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] debug compilation as default
Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive which is easy to alter by developers locally but isn't really meant to be a product build system. Why not? But the default I am sure should be debug everywhere, VM, classlib, tools until Harmony leaves the incubation state. This is what my patch did (if I didn't miss some places in classlib makefiles). But w/o a flag so it's easy to switch back and forth, which is what I'm asking about. Add release switch later when it is needed. Now... is it important to have it? Is it necessary to build classlib even with -mpentium3? I don't think so. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
