But wait a minute, how often do people really do both builds in the same make step? How hard would it be for those who do to do something like
make product_build ALT_OUTPUTDIR=/opt/jdk7-product; make debug_build ALT_OUTPUTDIR=/opt/jdk7-debug; make fastdebug_build ALT_OUTPUTDIR=/opt/jdk7-fastdebug ? This seems totally reasonable to me, personally. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:build-dev- > [EMAIL PROTECTED] On Behalf Of Kelly O'Hair > Sent: Thursday, January 10, 2008 1:24 PM > To: Volker Simonis > Cc: build-dev@openjdk.java.net > Subject: Re: Problems with ALT_OUTPUTDIR in debug build > > ALT_OUTPUTDIR=$(OUTPUTDIR) > doesn't make sense to me. > > The makefiles will define OUTPUTDIR to be equal to $(ALT_OUTPUTDIR) if > ALT_OUTPUTDIR is set. > The _OUTPUTDIR is the default build location, when ALT_OUTPUTDIR is not > set. > > The original idea here in setting ALT_OUTPUTDIR=$(_OUTPUTDIR)- > $(DEBUG_NAME) > was to put all the results of a debug build in a completely different > directory, which I still think is right. > I suspect this needs to be: > ALT_OUTPUTDIR=$(OUTPUTDIR)-$(DEBUG_NAME) > > A long time ago, the debug files were built along side the normal > files, and > all debug files had that "_g" suffix (e.g. jvm_g.dll, etc.) but we > completely > got rid of that because it was a nightmare. > The debug builds then just became a second pass over the source with > the same > makefiles but just a different output directory so they didn't mix. > I'm afraid using ALT_OUTPUTDIR=$(OUTPUTDIR) will mix up the optimized > files > with the debug files, which won't be good. > > -kto > > Volker Simonis wrote: > > I would suggest to fix the top-level Makefile such that > > COMMON_DEBUG_FLAGS uses $(OUTPUTDIR) instead of $(_OUTPUTDIR) > > and doesn't append "-$(DEBUG_NAME)" to ALT_OUTPUTDIR like so: > > > > COMMON_DEBUG_FLAGS= \ > > DEBUG_NAME=$(DEBUG_NAME) \ > > ALT_OUTPUTDIR=$(OUTPUTDIR) \ > > NO_DOCS=true > > > > We will than always end up with two directories like so: > > > > xxx > > xxx-fastdebug > > > > if we used "ALT_OUTPUTDIR=xxx". > > > > "xxx-fastdebug" will always be empty (but needed if I follow your > > previous post) so we can remove it after the build. But the user will > > get the output in the directory he specified with ALT_OUTPUTDIR and > > that seems crucial to me. > > > > What do you think? > > > > Volker > > > > On 1/10/08, Kelly O'Hair <[EMAIL PROTECTED]> wrote: > >> Your final paragraph I think is the answer: > >> > >> "In my eyes, the cleanest solution would be if ALT_OUTPUTDIR > would be honoured > >> "as is", as the output directory for everything we built, > without anything > >> appended to it. So the developer should be free to choose > whatever he wants as > >> the output directory. And there should be no additional > directories created." > >> > >> The ongoing problem has been how to make this work in all cases. > >> But I'm all for it. > >> > >> The generally accepted default for an output directory has been a > ./build or > >> ./dist directory at the top of the source tree you are building. > >> With corba, jaxp, jaxws, langtools, hotspot all being independently > buildable, > >> what exactly are you recommending to fix this? > >> > >> -kto > >> > >> Volker Simonis wrote: > >>>>> Any comments if this is the right way to do a debug build? > >>>> If it works it's fine. I usually just run 'make debug_build', does > that not work? > >>>> > >>> It works, but it has the problems that I detailed in my first mail. > >>> Did you also read that one? > >>> I may seem that my second mail contained the solution for the first > >>> one, but that's not true, its justa partial workaround for the > problem > >>> described in the first one: > >>> > >>> http://mail.openjdk.java.net/pipermail/build-dev/2008- > January/000669.html > >>> > >>> Thanks and regards, > >>> Volker > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.0/1218 - Release Date: > 1/10/2008 1:32 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.0/1218 - Release Date: 1/10/2008 1:32 PM