harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib] debug compilation as default
Date Thu, 06 Jul 2006 21:06:29 GMT

On 7 July 2006 at 0:43, "Ivan Volosyuk" <ivan.volosyuk@gmail.com> wrote:
> On 7/7/06, Gregory Shimansky <gshimansky@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message