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 21:28:42 GMT
On 7/7/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
>
> 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

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. People can set corresponding environment variables for
extra compiler switches they want.

>
> 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.

>
> 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.

-- 
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