Problems with ALT_OUTPUTDIR in debug build

[Kelly O'Hair]

What you recommend should work now, with the empty directory clutter there, which
I think we can figure out and fix.

-kto

Ted Neward wrote:
> 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: build-dev-bounces at openjdk.java.net [mailto:build-dev-
>> bounces at openjdk.java.net] On Behalf Of Kelly O'Hair
>> Sent: Thursday, January 10, 2008 1:24 PM
>> To: Volker Simonis
>> Cc: build-dev at 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 <Kelly.Ohair at sun.com> 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
>  
>