On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley <a...@redhat.com> wrote: > On 07/29/2013 02:55 PM, Bruce Korb wrote: >> On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley <a...@redhat.com> wrote: >> >>> There should be a better diagnostic. >> >> If you remember, the start of this thread was: >> >>> Why is it that configure worked but stubs-32.h was not found? >> >> That is the correct thing to do. The reply, basically, was: >> >> It's too hard. > > It was "This is possible, but it's tricky, and it's really important > to get it right. We don't want a half-arsed patch." > >>>> But we know people are running into this issue and reporting it. >>> Yes. But that on its own is not sufficient to change the default >> >> That's a pretty obnoxious comment. > > Oh dear. > >> I translate it as, "I don't care if people are having trouble. > > That's a mistranslation. It means that there are other criteria > beyond some people having trouble. Such as, we really want multilibs > to be built. > >> It is a nuisance to me to do that and anyone building GCC should >> already know they need <whateveritwas>-devel for 32 bits." I guess >> I can be obnoxious, too. But slightly more politely put: >> >>> No, we aren't. We're disagreeing about whether it's acceptable to >>> enable a feature by default that breaks the compiler build half way >>> through with an obscure error message. Real systems need features that >>> aren't enabled by default sometimes. >> >> The fundamental issue, to me, is: What do you do when you cannot >> proceed? >> >> I think you should detect the issue as *soon as practical* and then >> *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. > > Yes! Yes! Yes! > > Andrew.
-- Kie ekzistas vivo, ekzistas espero.
