Re: dfa.c order of include problem

[Eli Zaretskii]

> Date: Fri, 01 Feb 2013 00:17:42 -0800
> From: Paul Eggert <address@hidden>
> Cc: address@hidden
> 
> I think Eric Blake was talking about glibc regex.h in the
> context of glibc, whereas you're talking about it in a different
> context, where glibc regex.h is combined with some non
> glibc standard headers.  Yes, in that case one can have problems.

Eric Blake could have tried understanding the issues in detail before
responding, when the request comes from someone who goes by the handle
of Aharon Robbins.  Supposedly, Aharon doesn't say stupid things too
frequently.

> But surely it's better to fix regex.h so that it conforms
> to POSIX in this respect, than to fix all of regex.h's users
> to work around the bug.  Gnulib regex.h does that: it is designed
> to be portable to non-glibc environments, and it fixes the problem.

I would expect to see more respect to requests of a veteran GNU
maintainer than this thread exhibits.  There's no rule anywhere that
the Only True Way is the gnulib way.  Please consider the slight
possibility that other opinions could be at least as valid as those of
gnulib maintainers, and please give those opinions _some_ non-zero
weight.

You are maintaining a library.  Libraries should be attentive to the
needs and desires of their users.  Libraries should not dictate
solutions to their users.  "My way, or the highway."   Sheesh!

To quote Aharon: "Free Software used to be fun.  It isn't anymore."
Any idea how that observation is related to this thread?

(If I were a gnulib maintainer -- which I'm not, and never will be --
I'd solve this by a compromise: accept Aharon's changes, and _also_
fix regex.h so that in the future these problems could be avoided.
That's all; very simple, and everyone's happy, or should be.)

P.S.  This is not meant for Paul personally, but rather to gnulib as a
whole.