Thank you - looks reasonable to me. Volker
On 1/11/08, Kelly O'Hair <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> Sent: Friday, January 11, 2008 8:42 AM > >> To: Ted Neward > >> Cc: 'Volker Simonis'; build-dev@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:[EMAIL PROTECTED] > >>>> Sent: Friday, January 11, 2008 1:05 AM > >>>> To: Kelly O'Hair > >>>> Cc: build-dev@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 <[EMAIL PROTECTED]> 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 <[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 > >>> > >> 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 > > > > >
