Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119598 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 82157 invoked from network); 23 Feb 2023 05:20:44 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Feb 2023 05:20:44 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B28D5180504 for ; Wed, 22 Feb 2023 21:20:43 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 138.201.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from swift.blarg.de (swift.blarg.de [138.201.185.127]) by php-smtp4.php.net (Postfix) with ESMTP for ; Wed, 22 Feb 2023 21:20:43 -0800 (PST) Received: from swift.blarg.de (swift.blarg.de [IPv6:2a01:4f8:c17:52a8::2]) (Authenticated sender: max) by swift.blarg.de (Postfix) with ESMTPSA id 11DD0410F8; Thu, 23 Feb 2023 06:20:42 +0100 (CET) Date: Thu, 23 Feb 2023 06:20:40 +0100 To: Stanislav Malyshev Cc: internals@lists.php.net Message-ID: References: <607b7a66-bf47-de99-f51a-6cd367e2a839@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <607b7a66-bf47-de99-f51a-6cd367e2a839@gmail.com> Subject: Re: [PHP-DEV] LDFLAGS broken? From: max+php@blarg.de (Max Kellermann) On 2023/02/23 05:53, Stanislav Malyshev 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