Problems with ALT_OUTPUTDIR in debug build

[Ted Neward]

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