Re: is --enable-threads supported on HP-UX 11.00?

[Mark Mitchell <mark at codesourcery dot com>]

--On Saturday, June 23, 2001 04:29:46 AM -0300 Alexandre Oliva 
<aoliva@redhat.com> wrote:

> On Jun 21, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com>
> wrote:
>
>> I personally think that anyone that configures with just
>> --enable-threads should get a fatal ``early configuration''-time
>> warning when single is the best that can be done for a platform.
>
> I would go with a warning, but I'd rather not have a fatal error.  It
> would be quite annoying to have to remember which platforms support
> threading and which don't, so that I could omit --enable-threads when
> testing GCC on them.

I think this is a classic case of different perspectives implying
different things.  We are not typical users, and so we have different
wants than them.

Our goal is not to make our lives easy -- it is to make our users
lives easy.  If I download software, and it says "use --enable-threads
to enable threads", and I do that, and it doesn't actually set itself
up to use threads, and the only way I knew that is that a warning
was emitted somewhere in the midst of several hundred lines of output,
I'm going to not even notice.  Then, I'll wonder why either a) threads
don't work, or b) things that should be thread-safe aren't.  Or, worse
yet, I'll ship software that's broken, and finally someone will notice,
and that will reflect poorly on GCC.

We should make configuration-time options that don't work issue hard
errors.  (A warning would probably be OK if we made it interactive; if a 
dialog box came up and said "this won't work, do you want to keep going?", 
that would be OK.  But, that's not how GNU configure scripts are supposed 
to work.)

We should also make the defaults right for the platforms in use.  (Same 
idea: if GNU/Linux supports threads, why would I want an un-threadsafe
compiler?  Why should I as the user have to figure this out?)  Then,
it would be easy for everyone: easy for the user *and* easy for us.

(Parenthetically, having choices is not a win.  Choices are a cost, for 
users and for us.  We should only allow the user to make choices where 
necessary -- not where possible.)

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