Problems with ALT_OUTPUTDIR in debug build

[Ted Neward]

> You wrote that the "MKDIRs" in the setup rules are only needed to
> workaround a windows problem. I didn't built an Windows, but perhaps
> somebody can try if they are still needed (Ted?). And if they will be
> really needed, perhaps we can conditionally enable them on Windows
> only, so we don't clutter the Unix build with usless directories?
>
Right now I'm still stuck trying to get the Windows build to work from the top-level makefile; I'm waiting for bNext to try again and verify if it's an environment issue or a source/make issue, so I can't say for certain. But, IIRC, the last time I looked, the situation on Windows is worse, because we get not only the four directories you mention, but 8.3-named versions of them, as well, so (from memory) you'd end up with:

build
build-debug
build-fastdebug
build-d?1
build-f?1

where the last two are the 8.3 versions of the longer filenames, and they're all empty.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: Friday, January 11, 2008 1:05 AM
> To: Kelly O'Hair
> Cc: build-dev at openjdk.java.net; Ted Neward
> Subject: Re: Problems with ALT_OUTPUTDIR in debug build
> 
> Ok, I think I can live with ALT_OUTPUTDIR=$(OUTPUTDIR)-$(DEBUG_NAME)
> as well. This at least honours the original user setting of
> ALT_OUTPUTDIR (though with a "-debug" suffix).
> 
> But it will create FOUR outputdirectories, if we say "make debug_build
>  ALT_OUTPUTDIR=xxx" of which only "xxx-debug" will be used:
> 
> xxx
> xxx-debug
> xxx-debug-fastdebug
> xxx-fastdebug
> 
> If we say "make fastdebug_build  ALT_OUTPUTDIR=xxx" if will create
> THREE directories, of which only "xxx-fastdebug", will be used:
> 
> xxx
> xxx-fastdebug
> xxx-fastdebug-fastdebug
> 
> I still think this is quite confusing (especially
> "xxx-debug-fastdebug" and "xxx-fastdebug-fastdebug" - what should they
> be good for).
> 
> The main cause for this hassle is the setup rule in the top-level
> Makefile (and the recursive invocation of this makefile for the
> "debug" and "fasdebug" targets) :
> 
> setup:
>        $(MKDIR) -p $(OUTPUTDIR)/j2sdk-image
>        $(MKDIR) -p $(ABS_OUTPUTDIR)/j2sdk-image
>        $(MKDIR) -p $(OUTPUTDIR)-fastdebug/j2sdk-image
>        $(MKDIR) -p $(ABS_OUTPUTDIR)-fastdebug/j2sdk-image
> 
> I still don't understand why it is necessary, because if I remove all
> the MKDIRs, (and with ALT_OUTPUTDIR=$(OUTPUTDIR)-$(DEBUG_NAME) as
> suggested above), at least on my Linux box everything works fine:
> 
> "make debug_build  ALT_OUTPUTDIR=xxx" creates two directories and puts
> the output to "xxx-debug":
> 
> xxx
> xxx-debug
> 
> "make fastdebug_build  ALT_OUTPUTDIR=xxx" creates two directories and
> puts the output to "xxx-fastdebug":
> 
> xxx
> xxx-fastdebug
> 
> and "make all  ALT_OUTPUTDIR=xxx" creates just "xxx" and puts the
> output into.
> 
> This seams reasonable to me!
> 
> You wrote that the "MKDIRs" in the setup rules are only needed to
> workaround a windows problem. I didn't built an Windows, but perhaps
> somebody can try if they are still needed (Ted?). And if they will be
> really needed, perhaps we can conditionally enable them on Windows
> only, so we don't clutter the Unix build with usless directories?
> 
> Regards,
> Volker
> 
> On 1/10/08, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> > 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