Problems with ALT_OUTPUTDIR in debug build

[Kelly O'Hair]

I didn't address the building both with one step...

For OPENJDK, we don't build both at the same time. But for the Sun JDK product itself
our Release Engineering (RE) team does it all the time, and we have tried to make sure that
teams integrate using the same steps as RE as much as possible (hard to match them exactly).

Granted, our individual developers don't necessarily build the entire jdk but push/putback
their changes to a team area and the team integrator is supposed to do the same or
similar build that RE would do before they integrate all their team changes to the master
area, which is the first time RE will see the changes.
(Hotspot teams often only build/test the VM, non-Hotspot teams often skip building the VM,
it depends on what changes the team is doing).

---

Initially the default for OpenJDK builds was to build both product and fastdebug,
but I changed it to just build the product build (see file make/Defs-internal.gmk).
The default for a Sun JDK build is a product and fastdebug version.

We have some issues with what it means to build the JDK, as you can see from the
SKIP_OPENJDK_BUILD feature, an experiment that would force an OpenJDK build everytime
a Sun JDK was built, making it 3 builds that a Sun JDK 'make' would do (by default).
This is a work in progress (doesn't apply to the OpenJDK building you are doing).

-kto

P.S. Also, in theory, if your machine can handle it, you could:
   make product_build   ALT_OUTPUTDIR=/opt/jdk7-product   > product.log   2&>1 &
   make debug_build     ALT_OUTPUTDIR=/opt/jdk7-debug     > debug.log     2>&1 &
   make fastdebug_build ALT_OUTPUTDIR=/opt/jdk7-fastdebug > fastdebug.log 2>&1 &
   wait

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