2009/5/15 Mark Reinhold <m...@sun.com>: >> Date: Thu, 14 May 2009 23:31:58 +0100 >> From: Andrew John Hughes <gnu_and...@member.fsf.org> > >> 2009/5/14 phil.r...@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 >>> upstream. >> >> 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 > Linux? > > 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 > -- 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
