Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Andrew John Hughes
gnu_andrew at member.fsf.org
Fri May 15 15:30:04 UTC 2009
2009/5/15 Mark Reinhold <mr at sun.com>:
>> Date: Thu, 14 May 2009 23:31:58 +0100
>> From: Andrew John Hughes <gnu_andrew at member.fsf.org>
>> 2009/5/14 phil.race at sun.com:
>>> I do think I know what you want. But I consider its a slippery slope as
>>> you have no way of knowing or keeping track of the consequences of
>>> not building a particular component.
>> Sure, but if someone chooses to set DISABLE_NIMBUS then they take that
>> risk. It's much the same as if they turn on insane mode or don't
>> build the docs. It's a tradeoff of having an incomplete build at the
>> end against simplifying the process, and one it is down to the user to
>> make. For example, if someone wants to build OpenJDK as a precursor
>> to hacking on HotSpot, then they are probably more concerned about
>> just completing the build than finding an additional set of
>> dependencies for a look and feel they probably won't use. I don't see
>> how arbitrarily restricting choice helps anyone.
>>> I suggest its better to fix the local build problem than push workarounds
>> My fear is we will run over this problem again and again. If people
>> working on OpenJDK day in and day out are having issues with this,
>> then newbies are going to fare even worse.
> I have to agree with Andrew on this one.
> Engineers working on the JDK routinely skip building various components,
> yet somehow we've survived. When was the last time, e.g., you built
> HotSpot, or javac, or the Windows installer, or generated rpm packages on
> There are already lots of ways to disable various components of the
> build. The better ones take care to issue a warning during the sanity
> check so that people who carelessly set build variables in their shell
> environment don't get tripped up too badly, as long as they make sure to
> read the sanity log.
> That these happen to be "platform" classes doesn't mean much. The chance
> that a Nimbus-disabled build would be mistaken for a product build is
> pretty well near zero, given all the testing that we do.
> If this tiny change makes it easier for people to work with our code,
> then I'm all for it.
> My only comment on Andrew's actual patch is that Sanity.gmk should be
> extended to print a warning when Nimbus is disabled. It otherwise looks
> fine to me.
I was thinking this as I read your mail. It should be easy enough to
add this as an #else clause to the existing patch in Sanity.gmk.
What's the best way to handle updating the patch, given that the
existing patch is a committed changeset? Do I need to somehow revert
the changeset or is a pair of changesets feasible?
> Oh, and if we have somehow become dependent upon a third-party tool
> (JIBX) that's so difficult to locate and has such a low commitment to
> interface stability, then perhaps we should reconsider that and use a
> different tool.
> - Mark
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the build-dev