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
 66.249.92.174 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=Tl6sZQMfRiWW6WeFoD4sHvO6dUEszyqD0HcnWcqQc2ykVBwV0XWRvQCa0vRUoDeLiunZ8Fc01jbtVkzZs4zWe9S51ATsKZzYLGTj9+pTrCq+SHo9HtVV9G0KUWZFkZ8jedY0HQnXeJjmzF3ZEfw5FrN5ZvYOVGXhEKekeUlnbSY=
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: Thu, 6 Jul 2006 21:37:48 +0400
User-Agent: KMail/1.9.1
References: <44AC4F3D.5090509@pobox.com>
 <200607060448.39362.gshimansky@gmail.com> <44AD3844.4050308@gmail.com>
In-Reply-To: <44AD3844.4050308@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200607062137.48883.gshimansky@gmail.com>

On Thursday 06 July 2006 20:20 Tim Ellison wrote:
> Gregory Shimansky wrote:
> > On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote:
> >> In HARMONY-681, I applied the patch to build DRLVM as debug by default,
> >> but 'rejected' the classlib patch, as it's not overridable as the DRLVM
> >> one is.
> >>
> >> I think that we'd like to be able to set a flag for release build,
> >> rather than have to rummage about in each makefile and include.
> >>
> >> Yea? Nea?
> >
> > +1 for release flag when it is needed
> >
> > I support this as I also think that current classlib build system is
> > rather primitive

Btw no offense intended I meant only native part of the build system. Java 
part is fine to me.

I think I didn't understand the original question well enough. Sure I think it 
would be good to have more than one mode to build native sources.

> Don't mistake being simple with being primitive <g>.  It will need to
> grow as we expand the amount of platform-dependent code, but I suggest
> we try to keep things as simple as possible.
>
> > which is easy to alter by developers locally but isn't really meant
> > to be a product build system.
>
> What do you mean?

(I'll try to answer both your and Geir's question here)

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. I think we'll come to some sort of 
configure script but maybe not, it should be discussed separately.

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.

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