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]
