Is it possible that the sanity messages are printing out the 'short path'
version of your output directory? e.g. cygpath -m -s "C:/Prg/OpenJDK/build"
Assuming you are using the cygwin 'make' do you know what version it is?
Is it 3.81?
I do recall some logic in the Makefiles that trys to deal with the situation
where the OUTPUTDIR is not a read-write directory, and ignored it, using
a different default that was read-write.
-kto
Ted Neward wrote:
Maybe I'm not getting it, but "make ALT_OUTPUTDIR=C:/Prg/OpenJDK/build ..."
doesn't seem to take. When I do the build, the sanity portion of the build
reports ALT_OUTPUTDIR being set to something other than what I specify on
the build command-line. What am I not getting?
Along those same lines, how can I see the recursive make calls more
explicitly?
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
-----Original Message-----
From: Ted Neward [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 26, 2007 3:56 PM
To: 'Ted Neward'; [EMAIL PROTECTED]
Cc: 'build-dev'; [EMAIL PROTECTED]
Subject: RE: Build problem (Windows, b24)
Something strange is going on. When I build from the top-level
directory, it
fails to build java/hpi. When I build just one level down, using
Kelly's
"make all ..." syntax below, it builds fine. Hate to say it, but I
think
this may be a bug in the Makefiles, though I'm not sure where or
why...?
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: Wednesday, December 26, 2007 1:03 PM
To: [EMAIL PROTECTED]
Cc: 'build-dev'; [EMAIL PROTECTED]
Subject: RE: Build problem (Windows, b24)
OK, trying to get back into this.
(*) FWICT, ALT_OUTPUTDIR doesn't seem to "take" when set from the
command
shell as an environment variable. Is this supposed to work?
(*) When I do cd jdk/make/java/hpi && make VARIANT=DBG
FASTDEBUG=true,
I get
nothing. No build, no error, just... enters windows, leaves windows,
done.
I'm doing a full build (from the top) into a log file for attachment
to
this
thread now, will email it when it's done. Problem is, I can't tell if
it's
an environment issue, or a genuine bug in the makefiles, or a PEBKAC
problem. Suggestions welcome....
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 18, 2007 11:58 AM
To: Ted Neward
Cc: [EMAIL PROTECTED]; 'build-dev'
Subject: Re: Build problem (Windows, b24)
Do to history, a build directly from the jdk/make directories uses
a
default
OUTPUTDIR of jdk/build/* but if FASTDEBUG=true, it's jdk/build/*-
fastdebug,
or if a plain debug build with just VARIANT=DBG it would be
jdk/build/*-debug
The variant builds leave results in a completely separate
outputdir.
If you used the very top level makefile (which came from the now
defunct control/make area)
the default OUTPUTDIR is ./build/* (at the very top of the
repositories).
When this top level Makefile runs the jdk/make Makefiles, it passes
in
a ALT_OUTPUTDIR
to refer to this top level build result area because it's default
outputdir
is not the same place.
I don't know the complete history as to why this was done this way,
but
my
tendency is to try and get us back to a single default OUTPUTDIR
for
all the
repositories. Someday...
This is what I do when I work on just the jdk repository:
cd jdk/make && gnumake
That primes the outputdir area, then I can drop down in:
cd jdk/make/java && gnumake
Or even drop in and clean an area and re-build it:
cd jdk/make/jpda && gnumake clean && gnumake
Or just repeat the entire build (incremental build)
cd jdk/make && gnumake
If I wanted the jdk image (j2sdk-image), I would need to:
cd jdk/make && gnumake image
But the output by default will go to jdk/build/*
and a different directory if VARIANT=DBG or FASTDEBUG=true.
I think you need to:
cd jdk/make && gnumake VARIANT=DBG FASTDEBUG=true
Then see if you can:
cd jdk/make/java/hpi && gnumake VARIANT=DBG FASTDEBUG=true
-kto
Ted Neward wrote:
Tim--
Maybe you came in too low and clipped the treetops.
I thought part of the idea would be that if I've just made a
change
to one
part of the tree, I don't have to rebuild the whole tree, so I
would
think
coming in lower to the ground would be supported...?
Let's turn it around this way: what is Sun doing among the
various
teams? If
a developer makes a change, say, to the java.lang.instrument
package,
what's
the quickest way to get his build, presuming that he hasn't
changed
anything
outside of that directory? I don't want to be swimming upstream,
but
in this
case, I really don't know which way the water flows. :-)
Try your 'make all' from
[...]/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make
Will do; by the way, what targets are supported in these lower-
level
makes?
"fastdebug" and "fastdebug_build" didn't take, AFAICT (no
target).
The first thing the jdk7/jdk build does (after the sanity check)
is
create a number of tools
that will be used later. If you start building lower down in
jdk/make/java there may be an
assumption about work that has already been done.
I can see that, and they are there--they built successfully. What
I
don't
understand is why the "treetop build" I tried was looking for
them
in
windows-i586 and not windows-i586-fastdebug.
This is not automatic because we don't want to fill up someone's
disk
space with log files.
Not so much of a problem these days, but back in the early days
it
was.
Maybe an option flag/env var in the make set, a la
ALT_LOGFILES=false
to
turn them off or something? It's just a common thing to have the
build tool
logging this stuff these days, it seems.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 18, 2007 12:12 AM
To: Ted Neward
Cc: 'build-dev'
Subject: Re: Build problem (Windows, b24)
Hi -
OpenJDK:[EMAIL PROTECTED]:/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java
$ make all
Maybe you came in too low and clipped the treetops.
Try your 'make all' from
[...]/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make
The first thing the jdk7/jdk build does (after the sanity check)
is
create a number of tools
that will be used later. If you start building lower down in
jdk/make/java there may be an
assumption about work that has already been done.
So try it again from [...]/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make
BTW - I always save the build log, as Kelly wrote:
make |& tee build.log or make >& build.log
This is not automatic because we don't want to fill up someone's
disk
space with log files.
Not so much of a problem these days, but back in the early days
it
was.
HTH - Tim
Begin Processing SUBDIRS: hpi version jvm redist verify fdlibm
java
sun_nio
jli
main zip security npt java_crw_demo java_hprof_demo math awt
util
text
applet ne
t nio sql rmi jar beans logging management instrument
Recursively making hpi all @ Mon Dec 17 23:40:21 PST 2007
...
make[1]: Entering directory
`/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java/hpi'
Begin Processing SUBDIRS: windows
Recursively making windows all @ Mon Dec 17 23:40:25 PST
2007
...
make[2]: Entering directory
`/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java/hpi/wind
ows'
make[2]: *** No rule to make target
`../../../../build/windows-i586/btjars/strip
properties.jar', needed by `strip_all_props'. Stop.
make[2]: Leaving directory
`/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java/hpi/windo
ws'
make[1]: *** [all] Error 1
make[1]: Leaving directory
`/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java/hpi'
make: *** [all] Error 1
OpenJDK:[EMAIL PROTECTED]:/cygdrive/c/Prg/OpenJDK/jdk7/jdk/make/java
$
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.2/1185 - Release Date:
12/15/2007 12:00 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.2/1185 - Release Date:
12/15/2007
12:00 PM
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.2/1185 - Release Date:
12/15/2007 12:00 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date:
12/25/2007
8:04 PM
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date:
12/25/2007 8:04 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date:
12/25/2007
8:04 PM
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date:
12/25/2007 8:04 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.9/1197 - Release Date: 12/25/2007
8:04 PM
