From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30760 invoked from network); 22 Sep 2020 21:11:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 Sep 2020 21:11:12 -0000 Received: (qmail 17866 invoked by uid 550); 22 Sep 2020 21:11:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17845 invoked from network); 22 Sep 2020 21:11:08 -0000 From: "Laurent Bercot" To: "musl@lists.openwall.com" Date: Tue, 22 Sep 2020 21:04:17 +0000 Message-Id: In-Reply-To: References: <4768019.hHWyC0TzgU@omega> <20200920135629.GI2947641@port70.net> <20200920171446.GB3265@brightrain.aerifal.cx> <2533200.g9kxISXj3W@omega> <20200922184610.GI3265@brightrain.aerifal.cx> User-Agent: eM_Client/8.0.3385.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrudeggdduheejucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdguihgvthhlihgstgesshhkrghrnhgvthdrohhrgheqnecuggftrfgrthhtvghrnhepueeihffhueevgedujefggeduueefvedufedtleevieefffeitdeiheethedtvedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuth Subject: Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 >> I'm not trying to tell you you're not a grown-up programmer. I'm >> trying to tell you that the answer to the question you're asking ("is >> this musl?") is not meaningful for achieving what you presumably want >> to achieve -- assisting the program using autoconf tests in >> automatically producing a build that works on the intended host. > >That assumes a project is Autotools based. No, it does not. It assumes that the project's authors are attempting to produce a working project, including detection of implementation- defined behaviour wherever the project relies on them. "autoconf tests" is a shortcut that means "tests performed at build time that do such detection", because autoconf is the most widely known program that produces such tests and everyone understands the expression. But it doesn't mean that a project has to use autotools. My projects don't, and never will; however, they do perform feature detection at build time, because it's necessary for what they do. If a project relies on implementation-defined behaviour and does not perform detection, then it is broken and needs to be fixed. If its build system does not allow it to perform detection, then it needs to switch to a better build system. As you say, autotools is a mess, but it at least gets this part right (more or less - it does cross-building wrong because by default it assumes target behaviours it cannot detect, instead of asking the user). I very much hope other build systems are capable of doing the same. If not, that's, for once, functionality they should grow, because it's useful. -- Laurent