harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [classlib] debug compilation as default
Date Thu, 06 Jul 2006 22:12:49 GMT
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message