Andrew Haley writes: > Mark Mitchell wrote: > > Andrew Haley wrote: > > > >>>> But, I am actually ok with having it be disabled by default, provided > >>>> that regressions affect gcj are treated seriously: fixed in a timely > >>>> way by the person causing the regression, or, if not, letting gcj > >>>> maintainers start the patch-reversion clock. > >>>> > >>>> If we make this change I'll set up an auto-tester on the compile farm > >>>> that builds gcj along with everything else. I think this would > >>>> provide a pretty reasonable compromise. > > > > I agree. I also agree that if someone breaks Java, they should be > > required to fix the problem. In fact, we could have the rule that the > > Java maintainers get to revert a patch summarily based merely on the > > fact that there exists a Java post-patch failure that does not occur > > pre-patch. > > OK. I'm hoping that the java mainatiners won't have _all_ the burden, though. > > We should have a trial phase where java build breakage on the autobuilders > is mailed to the maintainers who checked in patches and to the java > maintainers, and we'll see how it goes. > > I'm open-minded about this, but if it doesn't work we should be prepared to > revert the policy.
would it be a possibility to reduce the cost of having java built by default and keep java in the default bootstrap languages? - currently libjava is built as a static *and* as shared library, while the static library is not that useful. make it the default of not building the static library by default? Doesn't cut the build time of libjava by 50%, but should speed up the build considerably. - on platforms where multilib is the default, libjava is built as biarch as well; unfortunately the build will fail on machines which don't have all the build dependencies available for all build dependencies (e.g. gtk). Disable the multilib build by default to save 50% build time on those platforms. Sorry for getting that late into the discussion. gcj is still important for some os/architectures, where OpenJDK isn't yet an alternative. Could we delay this decision until after the 4.4 branch is created? Matthias
