Andrew John Hughes wrote:
2010/1/8 Andrew John Hughes <gnu_and...@member.fsf.org>:
2010/1/8 Jonathan Gibbons <jonathan.gibb...@sun.com>:
Andrew John Hughes wrote:
2010/1/8 Jonathan Gibbons <jonathan.gibb...@sun.com>:
Joe Darcy wrote:
Kelly O'Hair wrote:
Not many jdk developers build the docs on a regular basis that I know of.
The docs are certainly built nightly from the master area (jdk7/jdk7),
and should be built as part of the promoted build process.
I have not seen this problem before. I noticed that the sourcepath is a
little strange:
I do build docs regularly and I'm also seeing this problem in an
up-to-date child of JDK 7 TL I'm working with under Linux.
-Joe
I have a Hudson instance that routinely builds tl using "gnumake sanity
clean all SKIP_BOOT_CYCLE=false" but it is not seeing any problems.
Correction: Hudson is happy, but I see that there are problems in the log.
Perhaps we should work to make such issues hard failures.
-- Jon
This does cause the build to error out for me. What are you using as
the bootstrap JDK?
I do a full (closed) and openjdk builds with
ALT_BOOTDIR=/opt/jdk/1.6.0 (1.6.0_17-b02)
ALT_JDK_IMPORT_PATH=/opt/jdk/1.7.0 (1.7.0-ea-b75)
The openjdk build just does "gnumake sanity clean all" without the
SKIP_BOOT_CYCLE=false.
Both builds are Hudson happy.
If the OpenJDK7 javadoc from /opt/jdk/1.7.0 is being used, then yes it
won't fail. IcedTea also passes because it builds the docs in the
second build using the javadoc of the first build.
Maybe the solution is to set the bootclasspath to point to the newly
built libraries. You should be able to build the documentation
without having to have an existing 1.7 build around (there's an
obvious bootstrapping problem there for one).
-- Jon
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
I'm still getting the same error with b79. Any ideas for solving this?
Can you summarize your build environment and describe the failure, so
that we can try and recreate it here?
-- Jon
