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

Reply via email to