[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: 21.2.90: configure problems -- using gcc 3.1 and --x
Re: address@hidden: 21.2.90: configure problems -- using gcc 3.1 and --x-includes option]
07 Jun 2002 01:00:54 -0300
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
On Jun 6, 2002, Richard Stallman <address@hidden> wrote:
> I think I see a miscommunication here. Failure to find a certain
> header file normally results in an *error*. Autoconf needs to notice
> these *errors*, but it could ignore mere *warnings*.
As I wrote in a separate message, there are compilers that do not
terminate with an error exit status when they can't find a header
file. This is the very reason why autoconf tests for non-empty error
preprocessor output, instead of relying on the exit status, when
testing for preprocessor problems. AFAIK, GCC has never had such a
problem, but I don't think duplicating the code generated for every
header file test is the right way to fix the problem.
> If things break because of that, it's the user's problem.
> With all due respect, that is the wrong attitude for the job of
> maintaining GCC or Autoconf.
What I mean is that we shouldn't get out of our way to let users do
things that are wrong. Doubling the size and run time of configure
tests to cover up user's faults is not reasonable. Adding one more
simple test to check whether the user is doing something iffy is.
That's why I prefer the second solution.
However, changing neither autoconf nor GCC will fix the problem at
hand, since the configure script is already deployed, and so is the
GCC that prints the warning. So education is the best solution for
this particular problem. If autoconf can get smarter to relay the
warning printed by GCC to the user, it'll be doing a good thing, but
this still doesn't mean what the user is doing is right.
> This doesn't make we should gratuitously make them bigger and slower.
> Fixing a bug is not a gratuitous change.
> This is a serious bug and it needs to be fixed.
I disagree it is a bug. We're just seeing a symptom of the user doing
something odd. It's not too different from say the user setting
CPP=g++, instead of CPP='gcc -E' and CXX=g++. g++ won't work properly
as a preprocessor, and if configure results go wrong because of it,
it's the user's fault. How much out of our way should we go to
protect the software from user errors?
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer address@hidden, redhat.com}
CS PhD student at IC-Unicamp address@hidden, gnu.org}
Free Software Evangelist Professional serial bug killer