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
