As far as I'm concerned clean==clobber. It used to be that one of these
would also trigger a 'sccs clean', which is pretty insane in my opinion
when you are talking about 30,000 files.
So usually a 'make clean' does the same thing as 'make clobber'.
On windows the 'rm -f -r' failing usually means that there is a permission
problem, or some process or window is still using something in this directory,
OR somehow one of the files in this directory exceeds some small length
limit of windows (254?). With windows there are lots of reasons.
The trick of 'mv build build.NNN' may not work on windows. The only
reliable way to deal with this on windows is to always create a unique
directory from the beginning, with a time stamp in the name or something.
Which is a pain.
There is a bug here, but it's tricky. There are some Makefile lines like:
dummy := $(shell $(MKDIR) $(OUTPUTDIR))
that are used to force the creation of the output directory, I suspect this
is the cause of the problem, and I suspect this is mostly a windows problem.
But they were put there for a good reason, so removing them may mean figuring
out why they were needed and finding another solution.
Part of this may be buried in the windows short pathnames logic, e.g.
CYGWIN's 'cygpath -s' or MKS's 'dosname -s'. In order for you to find the
short non-space path on windows, it needs to exist first, if it exists
and you remove it and then re-create it, the short pathname changes.
On control builds, I normally just 'rm -f -r build' to clean it.
-kto
Ted Neward wrote:
Quick note: doing a "make clean" from the top yielded this:
$ make clean
rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/outputdir
rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import
( cd ../../j2se/make; make clobber EXTERNALSANITYCONTROL=true
MILESTONE=private
BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-private-b00
ALT_OUTPUT
DIR=c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1
ALT_HOTSPOT_IMPORT_PATH=c:/Prg
/OpenJDK/openjdk/control/build/WINDOW~1/hotspot/import BUILD_HOTSPOT=true
BUILD_
MOTIF=false ARCH_DATA_MODEL=32 ; )
make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make'
../make/common/shared/Defs-windows.gmk:611: "WARNING: Value of
HOTSPOT_IMPORT_PA
TH cannot be empty, check or set ALT_HOTSPOT_IMPORT_PATH"
rm -f -r c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1
rm: cannot remove directory `c:/Prg/OpenJDK/openjdk/control/build/WINDOW~1':
Dir
ectory not empty
make[1]: *** [clobber] Error 1
make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make'
make: *** [j2se-clobber] Error 2
CYGWIN:[EMAIL PROTECTED]:/cygdrive/c/Prg/OpenJDK/openjdk/control/make
$
Not sure if there was something in particular I needed to do to make the
clean target work, but I "fixed" it by just nuking the build/* directories
by hand. However, this doesn't exactly work, as apparently "make clean"
*creates* directories underneath build (build/windows-i586, in particular)
as part of cleaning the build. :-)
I suspect this to be a bug, yes?
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 28, 2007 2:15 PM
To: Ted Neward
Cc: [EMAIL PROTECTED]; build-dev@openjdk.java.net
Subject: Re: T2K needed in Linux, also?
The new sparse binary plugs will have the same exact layout as a jdk
install
tree, e.g. bin, lib, jre, jre/lib, jre/bin, etc.
With one additional directory called "libfiles". This is where t2k.lib
will be found,
however, look quickly, because it may be deleted from the binary plugs
soon
and won't even be needed anymore. So anything you do around t2k.lib may be
a bit
of a waste of time. The new sparse binary plugs are awaiting some legal
issues
and should be showing up any day now.
The j2se/make/common/BinaryPlugs.gmk file has the rules for dealing with
the
binary plugs and has a rule that will copy the t2k.lib file into the right
place when the make/sun/font/Makefile is run. There is an export and
import
process for the BinaryPlugs. As the different engineering groups remove
the need for plugs, this file should get smaller and smaller, as will the
size of the binary plugs which will be created automatically soon.
Unfortunately we suspect there is a missing 'mkdir' in BinaryPlugs.gmk
right
now:
------- BinaryPlugs.gmk -------
*** /tmp/sccs.SHa4YR Sat Jul 28 13:57:44 2007
--- BinaryPlugs.gmk Sat Jul 28 13:57:37 2007
***************
*** 448,453 ****
--- 448,454 ----
import-binary-plug-t2k-library: \
$(LIBFILES_DIR)/t2k.lib $(LIB_LOCATION)/$(PLUG_T2K_LIBRARY)
$(RM) $(OBJDIR)/t2k.lib
+ $(MKDIR) -p $(OBJDIR)
$(CP) $(LIBFILES_DIR)/t2k.lib $(OBJDIR)
else # !windows
import-binary-plug-t2k-library: \
At least that's what we think prevents the new sparse binary plug bundles
from allowing an OpenJDK build on windows to work right now.
We were testing windows builds last week just before I took off on a
short vacation.
You could simulate things by creating this "libfiles" directory and
placing
your t2k.lib file in it.
As far as debugging the build process, it's not easy, but it has been
getting better over the last few releases.
Expect more build changes in the future with a goal of simplification.
Try 'gnumake -p', or there was a recent article in Dr. Dobbs about
debugging
makefiles that was very helpful. Last month maybe or 2 months ago?
-kto
Ted Neward wrote:
Next issue: after an svn update (which caught me up to rev 244, the
latest
in SVN), I do a Windows build, and it fails in the j2se/make/sun/font
build,
trying (of course) to build t2k.lib. The problem is, I can't figure out
what
it's looking for in order to slip t2k.lib into the right place and move
on.
Here's the results:
CYGWIN:[EMAIL PROTECTED]:/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font
$ make
/usr/bin/echo -e "lib=" ../../../build/windows-i586/bin/fontmanager.dll
lib= ../../../build/windows-i586/bin/fontmanager.dll
make -C t2k
make[1]: Entering directory
`/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k'
make[1]: *** No rule to make target
`C:/Prg/OpenJDK/BinaryPlugs/jdk1.7.0/libfiles/t2k.lib', needed by
`../../../../build/windows-i586/libfiles/t2k.lib'. Stop.
make[1]: Leaving directory
`/cygdrive/c/Prg/OpenJDK/openjdk/j2se/make/sun/font/t2k'
make: *** [t2k] Error 2
Where did this directory "libfiles" come from in the build step? My
guess is
it's coming from a variable/setting somewhere, but I can't figure out
what
to set in order to help the build system find my cribbed t2k.lib so it
can
move on. And even if I create said directories (both in the BinaryPlugs
dir
and the build dir), and put t2k.lib in there, the build still fails.
Help?
BTW, in general, how does one debug the build process? 'make -d' just
seems
horrendous....
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:build-dev-
[EMAIL PROTECTED] On Behalf Of Ted Neward
Sent: Thursday, July 19, 2007 10:10 AM
To: [EMAIL PROTECTED]
Cc: build-dev@openjdk.java.net
Subject: RE: T2K needed in Linux, also?
Yep, had it pointing to the Import JDK (1.6) instead of the binary plug
JDK
(1.7). Thanks. There's a lot of JDKs needed to build the JDK. :-)
By the way, in case those on this list haven't seen it, the build on
Intel
machines won't work, as there's a compilation error in a source file,
as
reported on the hotspot-dev list on 7/9 by Sunil Soman. Patch:
####
--- src/cpu/i486/vm/assembler_i486.hpp.old 2007-07-09
10:29:14.412986944 -0700
+++ src/cpu/i486/vm/assembler_i486.hpp 2007-07-09
10:29:31.499389416 -0700
@@ -158,7 +158,7 @@
// Easily misused constructor make them private #ifndef _LP64
- Address::Address(address loc, RelocationHolder spec);
+ Address(address loc, RelocationHolder spec);
#endif // _LP64
public:
####
Peter Kessler reported it as already reported, a la
http://mail.openjdk.java.net/pipermail/build-dev/2007-July/000098.html
but no official bug had been filed, and there was some concern about
Sunil's
contributor status or whatnot. Not sure what happened to it from there.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 5:52 AM
To: Ted Neward
Cc: build-dev@openjdk.java.net
Subject: Re: T2K needed in Linux, also?
Ted Neward wrote:
When trying to build the JDK on a fresh KUbuntu 7.04 system, I get a
build error saying libt2k.so cannot be found. Am I missing something?
Yes, sounds like you are missing the entire binary plug download, or
haven't properly pointed to it's location.
-phil.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date:
7/17/2007 6:30 PM
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.8/906 - Release Date:
7/17/2007
6:30 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date:
7/18/2007
3:30 PM
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date:
7/18/2007
3:30 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date:
7/24/2007
1:50 PM
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.19/918 - Release Date: 7/25/2007
2:55 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.23/924 - Release Date: 7/28/2007
3:50 PM
