2010/1/7 Kelly O'Hair <kelly.oh...@sun.com>: > > Andrew John Hughes wrote: >> >> 2009/12/23 Andrew John Hughes <gnu_and...@member.fsf.org>: >>> >>> 2009/12/23 Kelly O'Hair <kelly.oh...@sun.com>: >>>> >>>> Andrew John Hughes wrote: >>>>> >>>>> 2009/11/19 Kelly O'Hair <kelly.oh...@sun.com>: >>>>>> >>>>>> Need reviewer. Some very minor top level make file changes. >>>>>> >>>>>> 6727046: Add message when docs are skipped in control build >>>>>> 6864011: typo? in top level Makefile: DAYE_STAMP >>>>>> >>>>>> http://cr.openjdk.java.net/~ohair/openjdk7/top-make-fixes/webrev/ >>>>>> >>>>>> -kto >>>>>> >>>>>> >>>>> This is a bit more than just adding a message. It also adds: >>>>> >>>>> + # No DOCS build when JDK_UPDATE_VERSION set >>>>> + ifdef JDK_UPDATE_VERSION >>>>> + GENERATE_DOCS=false >>>>> + endif >>>>> >>>> Sorry about that, I assumed I was making a correction to a long standing >>>> problem. When we build jdk update releases, the docs are not >>>> regenerated. >>>> The variable JDK_UPDATE_VERSION indicates a jdk update build, I >>>> just assumed that's what it was being used for. >>>> >>> I would expect setting JDK_UPDATE_VERSION to do what it says on the >>> tin; i.e. set the version number that appears after the _. It doesn't >>> follow logically (at least to me) that it also turns off parts of the >>> build. You can already specify NO_DOCS to do just that. >>> >>> If Sun engineers want this free side-effect for their builds, it >>> should be restricted to those builds i.e. when OPENJDK is not defined >>> e.g. >>> >>> http://cr.openjdk.java.net/~andrew/build/webrev.02/tl.patch >>> >>>>> JDK_UPDATE_VERSION has to be set for IcedTea to deal with broken >>>>> plugins which expect this (such as >>>>> http://www.java.com/en/download/help/testvm.xml). I don't think it >>>>> follows that turning on a version setting forces documentation off. >>>>> Can we make this an #ifndef OPENJDK block? >>>> >>>> Strange use of JDK_UPDATE_VERSION if you ask me. >>>> >>> The issue was discussed again recently on the IcedTea list: >>> >>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-December/007712.html >>> It now appears a JDK_UPDATE_VERSION is not enough as the Sun code is >>> looking for update 16 or above. >>> >>> I agree it's not ideal but then I'm not responsible for any broken >>> code that relies on the version number format. Sun, however, are >>> responsible for the example cited in that mail. >>> >>> I would expect JDK_UPDATE_VERSION to set the version number. I >>> wouldn't expect it to start altering other parts of the build, >>> especially when the same can be achieved by other options. >>> >>>> Why not just 'make GENERATE_DOCS=true' with the IcedTea builds? >>>> Or am I missing the point? >>> >>> I guess we could, but it seems the wrong way to approach this to me. >>> It would make more sense to restrict this side-effecting behaviour to >>> just those builds that expect it i.e. Sun's proprietary non-OPENJDK >>> builds. We already have a large number of variables for IcedTea >>> builds; having to maintain yet another just so Sun builds can run with >>> one less seems the wrong approach to me. >>> >>> Equally, if an arbitrary user builds OpenJDK, and sets >>> JDK_UPDATE_VERSION for whatever reason, ar they really going to expect >>> it to stop generating documentation? >>> >>>> What exactly is it that JDK_UPDATE_VERSION provides for IcedTea builds? >>>> >>> It sets the update part of the version number so we get 1.6.0_0 or >>> 1.7.0_0 rather than just 1.6.0 or 1.7.0. As the email link above >>> explains in more detail, some applications/applets expect the version >>> number to have this update part (and even for it to be >0 in some >>> cases). >>> >>>> -kto >>>> >>> >>> >>> -- >>> 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 >>> >> >> You're right in that you didn't add this, just moved it to a different >> file. I found, when attempting to get IcedTea7 to build b78, that >> we've been patching it out since 2008: >> >> 2008-06-29 Matthias Klose <d...@ubuntu.com> >> >> * patches/icedtea-jdk-docs-target.patch: New. >> >> I think http://cr.openjdk.java.net/~andrew/build/webrev.02/tl.patch >> gives an acceptable compromise and shouldn't break Sun's proprietary >> builds. Can I have a bug ID to push this? > > 6914986: Make sure openjdk doc generation not turned off with > JDK_UPDATE_VERSION > > consider it reviewed. > > -kto >
Thanks :) Is it tl or build for this one? Cheers, -- 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
