Problems with ALT_OUTPUTDIR in debug build
Volker Simonis
volker.simonis at gmail.com
Fri Jan 11 18:42:43 UTC 2008
Thank you - looks reasonable to me.
Volker
On 1/11/08, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> Ah, shortpath == 8.3. Thanks for the history, and I agree, they are a royal pain.
> The Makefiles use 'cygpath -m -s -a PATH' or with MKS 'dosname -s PATH' to get these
> paths because dealing with paths that have spaces in Makefiles or shell commands is
> pretty impossible to keep correct.
>
> ---
>
> FYI... I filed a bug for this issue: 6649672
> (eventually can be viewed with: http://bugs.sun.com/view_bug.do?bug_id=6649672)
>
> --------
> Bug Description:
>
> The top level Makefile needs a few adjustments (might need changes to jdk/make/common/Defs*gmk files too)
>
> Two basic issues, left over empty directories for debug builds, and left over short paths on windows.
>
> 1. Change use of _OUTPUTDIR to OUTPUTDIR in Makefile for debug builds:
> COMMON_DEBUG_FLAGS= \
> DEBUG_NAME=$(DEBUG_NAME) \
> ALT_OUTPUTDIR=$(_OUTPUTDIR)-$(DEBUG_NAME) \
> NO_DOCS=true
> should be:
> COMMON_DEBUG_FLAGS= \
> DEBUG_NAME=$(DEBUG_NAME) \
> ALT_OUTPUTDIR=$(OUTPUTDIR)-$(DEBUG_NAME) \
> NO_DOCS=true
>
> 2. Delete some mkdir lines in Makefile:
> 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
> should be just
> setup:
> $(MKDIR) -p $(OUTPUTDIR)/j2sdk-image
> $(MKDIR) -p $(ABS_OUTPUTDIR)/j2sdk-image
>
> 3. When defining _OUTPUTDIR (the default) on windows in the jdk/make/common/Defs* file, get the short path for TOPDIR
> but not the short path for outputdir which is unreliable.
>
> 4. When ALT_OUTPUTDIR is passed in, do NOT get the short path for it, check it for spaces giving an error if a path with
> spaces is provided as the destination output directory. This directory might not exist so might not have a short path.
> ---------
>
> Let me know if I managed to cover all the issues on this email thread.
>
>
> -kto
>
> Ted Neward wrote:
> > The "8.3" name is the shortened translation of a long filename, for DOS backwards compatibility. It was introduced in Windows95 (!), and has never gone away since. You take the first six characters as-is, add a tilde (not a ? as I used below, sorry) and then an increasing number to guarantee uniqueness, all upper-case (since DOS is case-insensitive). So "C:\Documents and Settings" turns into "C:\DOCUME~1". (On a Windows box, use "dir /x" to see both the 8.3 names and the original long filenames.)
> >
> > Theoretically, either name is usable at any point in the OS, but in practice, that turns out not to be the case. They're a royal f*ing pain, and yet another testament to Windows' slavish adherence to backwards compatibility. :-/
> >
> > Ted Neward
> > Java, .NET, XML Services
> > Consulting, Teaching, Speaking, Writing
> > http://www.tedneward.com
> >
> >
> >> -----Original Message-----
> >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM]
> >> Sent: Friday, January 11, 2008 8:42 AM
> >> To: Ted Neward
> >> Cc: 'Volker Simonis'; build-dev at openjdk.java.net
> >> Subject: Re: Problems with ALT_OUTPUTDIR in debug build
> >>
> >>
> >> Sigh... These short names (what did you call them 8.3? what is that?)
> >> on windows only
> >> make sense on directories that exist and never get deleted, like the
> >> install location
> >> of the C++ compiler etc. They just don't work well with directories
> >> that are being created
> >> or deleted and re-created.
> >>
> >> I think what needs to happen for the default OUTPUTDIR is to just get
> >> the short path of the
> >> source tree, then add the "/build/..." to construct _OUTPUTDIR (the
> >> default).
> >> That way if the OUTPUTDIR gets removed and recreated, this short path
> >> is still valid.
> >> And if an ALT_OUTPUTDIR is provided, assume it's a path with no
> >> whitespace and just use
> >> it literally as is, maybe verify the path has no spaces in it as a
> >> sanity check?
> >>
> >> Is it acceptable to assume that any ALT_OUTPUTDIR setting is a path
> >> without spaces?
> >>
> >> -kto
> >>
> >> Ted Neward wrote:
> >>>> 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
> >>>
> >> 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.1/1219 - Release Date: 1/11/2008 10:19 AM
> >
> >
>
More information about the build-dev
mailing list