Problems with ALT_OUTPUTDIR in debug build
Kelly O'Hair
Kelly.Ohair at Sun.COM
Fri Jan 11 18:37:37 UTC 2008
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