Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of gshimansky@gmail.com designates
 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:from:reply-to:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id;
        b=RDujSGAMB9VqE1GVmwB69OjwtQq8UvSYQre3wKxIhhN1BA54CJxrzeV2GUmgfAL95twJMv8G18aY2ldAIykSQ+qYZoUyN7NNSYox7nO5OdAeiVSeUiBRijqQqHNNJbG7+Yfo53HClNxXMW6dXc0JNuifFeOMt80IUSMKBVkoQfc=
From: Gregory Shimansky <gshimansky@gmail.com>
Reply-To: harmony-dev@incubator.apache.org
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] debug compilation as default
Date: Fri, 7 Jul 2006 00:09:24 +0400
User-Agent: KMail/1.9.1
References: <200607061906.k66J68B0020457@d06av02.portsmouth.uk.ibm.com>
In-Reply-To: <200607061906.k66J68B0020457@d06av02.portsmouth.uk.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200607070009.24839.gshimansky@gmail.com>

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

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