From harmony-dev-return-9850-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu Jul 06 21:29:08 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 55839 invoked from network); 6 Jul 2006 21:29:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jul 2006 21:29:07 -0000 Received: (qmail 6714 invoked by uid 500); 6 Jul 2006 21:29:04 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 6669 invoked by uid 500); 6 Jul 2006 21:29:04 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 6652 invoked by uid 99); 6 Jul 2006 21:29:04 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 14:29:04 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of ivan.volosyuk@gmail.com designates 64.233.166.181 as permitted sender) Received: from [64.233.166.181] (HELO py-out-1112.google.com) (64.233.166.181) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 14:29:03 -0700 Received: by py-out-1112.google.com with SMTP id c30so2674640pyc for ; Thu, 06 Jul 2006 14:28:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=j+p23JLnXy/e75rcvY2DxJZbzudsASBBkOr8y42Hdaa8P7ihsVyx8DV5HRhIzEZhxcsNge8PO9XjZXB9ro8AGAH7eVYuu06Paz0llhzvRPJJR6nIOKUUUjUEoRffOTSR3lhnmQlauz8OcxHJjoryoGtjJFR9gO342HW2khXoE3g= Received: by 10.35.60.16 with SMTP id n16mr1436383pyk; Thu, 06 Jul 2006 14:28:42 -0700 (PDT) Received: by 10.35.115.13 with HTTP; Thu, 6 Jul 2006 14:28:42 -0700 (PDT) Message-ID: <12385bbd0607061428k53f1d4e8w3ffc350b2794a404@mail.gmail.com> Date: Fri, 7 Jul 2006 01:28:42 +0400 From: "Ivan Volosyuk" To: harmony-dev@incubator.apache.org Subject: Re: [classlib] debug compilation as default In-Reply-To: <200607062106.k66L6UnT012144@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <12385bbd0607061343l4cb071fem11e03679913a6383@mail.gmail.com> <200607062106.k66L6UnT012144@d06av02.portsmouth.uk.ibm.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 7/7/06, Mark Hindess wrote: > > On 7 July 2006 at 0:43, "Ivan Volosyuk" wrote: > > On 7/7/06, Gregory Shimansky 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