Need reviewer - minor top level make changes

[Andrew John Hughes]

2010/1/7 Kelly O'Hair <Kelly.Ohair at sun.com>:
>
> Andrew John Hughes wrote:
>>
>> 2009/12/23 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>
>>> 2009/12/23 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>>>
>>>> Andrew John Hughes wrote:
>>>>>
>>>>> 2009/11/19 Kelly O'Hair <Kelly.Ohair at 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  <doko at 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