Need reviewer - minor top level make changes

[Andrew John Hughes]

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