Re: ia64 libjava java-signal.h build failure

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> Nope.  There are two predicates.  One that enables or
    Alexandre> disables the Java compiler by default, the other
    Alexandre> enables or disables the Java libraries, but it won't
    Alexandre> enable them if the Java compiler is disabled.  

${libgcj} is added to ${noconfigdirs} on a number of platforms.  That
is the mechanism used to turn off the libgcj on platforms where it is
known not to work.

The other predicate is in java/config-lang.in, namely the
build_by_default predicate.

I have already indicated that I do not object to building gcj; it is
testing of the libjava configury that I feel needs to be done.  To
clarify, I have no object to an immediate patch that turns on
build_by_default for Java -- but simultaneously disables libgcj
unconditionally.  That is precisely the situation we had in GCC
2.95.x.

You would also like to have libgcj built whenever gcj is built and
whenever libgcj is not in noconfigdirs.  To validate that change, I
have asked you to test that, on the major platforms, and a few
secondary platforms, that either:

  - libgcj builds, and everything is OK

  - the configury logic turns off libgcj so that users don't see
    the problems.

You seem to want to turn on libgcj everywhere, and then disable it
where it doesn't work.  That asks other people to do testing that I
feel you should do.  Instead, I've asked that you turn it off
everywhere, and turn it on where you have tested that it works.  Both
methods are a gradual approximation to the same result.  We acheive
the same end, except that the testing load is shifted, and the
probability of broken bootstraps is changed.

    Alexandre> GCC for the release.  If we don't take this step, we'll
    Alexandre> end up with a GCC without a Java compiler enabled by
    Alexandre> default, which is a regression.  The libraries may
    Alexandre> still be disabled, as they were in GCC 2.95.2, but it's
    Alexandre> the compiler I'm talking about.

I addressed this in earlier mail, and I addressed it again above.

    Alexandre> Some of the involved platforms take the whole week for
    Alexandre> a full build&test

Which of the platforms I suggested take a week to test?  Surely none
of the primary release platforms takes a week?

In any case, most of a week has already gone by since the point when I
first asked for the testing.

    Alexandre> done for a third time, we won't be able to do anything
    Alexandre> before the end of April, and, eventually, someone will
    Alexandre> decide it's too late to make this change.

Who?  

I have already told you what I wished to do, and told you that you
could check in the patch if the tests passed.  Do you think the SC is
likely to overrule that decision?

    Alexandre> Let's please do it before the next snapshot, and then
    Alexandre> disable libjava whenever we get a report that it
    Alexandre> doesn't work on a certain platform. 

I've already said I don't wish to do this, and I've already offerred
two alternatives:

  - Ask the SC to overrule me.

  - Perform the testing I requested.

It is my job to organize the release, and I am doing the best I can.
If you feel someone else would do better, that is your privilege, and
you are welcome to make that suggestion to the SC.

On the occasions that the SC has made decisions I haven't agreed with,
I have always honored them.  The SC works for the FSF.  The SC *is*
the maintainer; I work for it, and I will do as I am asked.

Unless overruled, however, I expect that the decisions I make as RM
about the release branch will be honored, after I have indicated that
my mind is made up.

If you would like to debate this issue some more, I suggest contacting
the SC directly.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com