harmony-dev mailing list archives

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


Mime
View raw message