On 2023/02/23 05:53, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> It could be these changes do not make sense. It also could be they are
> necessary for the build to work on one of dozens of systems, distros and
> tools combinations PHP is being built on. Unless you have tested on all of
> them, I'd advise caution there.
I'm well aware that this is an area where lots of trouble can be
caused, and obviously I can't test all of them (I don't have anything
other than Linux).
This email thread is part me being cautious: I wanted an explanation
for these strange changes (and the "edit war"), but so far, nobody was
able to explain. I now know which bug reports provoked these changes,
but that doesn't explain the "fix", which rather looks like a random
kludge to me.
Workarounds that nobody can explain are a bad thing. One thing about
such workarounds is that they keep piling up, and after a few years,
nobody is brave enough to ever touch this knot, fearing it could break
something, and from here, everything detoriates. That fear is fair, I
don't mean to play down your cautious warning. But I think the pile
needs to be cut down eventually.
It's looong ago, but back in the day, I admit I was one of the few who
actually liked autoconf (not anymore), in spite of its weirdnesses.
One day, when I finally "got" how autoconf works, I figured that all
the layers of weird workarounds in my own scripts were just bad
kludges written by somebody who didn't know what he's doing (= me). I
learned that many bugs can be fixed by removing code.
An autoconf script must be simple and elegant (yes, I'm talking about
autoconf), and if it starts messing around with variables too much
(like PHP's LDFLAGS "fix"), it's a sign it's just a fragile mess.
Sure, PHP's configure script is battle-proven, because all the
workarounds are there, and the LDFLAGS mess appears to be part of
that. But that doesn't mean the script is really well-designed or
robust.
Max
