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?
--
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
