At Wed, 23 Mar 2022 22:25:11 +0100, Joerg Sonnenberger <joerg%bec.de@localhost> wrote: Subject: Re: autoswc and/vs. bmake/make and libtool -- how many developers use autoswc? > > Am Wed, Mar 23, 2022 at 11:25:27AM -0700 schrieb Greg A. Woods: > > So with a pkgsrc version up to about two years ago I was using autoswc > > quite successfully, with one caveat. > > That surprises me actually. IMO autoswc is fundamentally not sound and > quite likely to introduce subtile problems. It can only ever work for a > carefully curated set of configure.ac files. Just to name a simple > example: language selection flags like -std=gnu11 vs -std=c89 affect the > results of various header checks. I agree there are some big caveats to using autoswc. However I regularly build less than about 1000 packages, so I don't imagine I run into very many of the problem packages, thus my question of how many people might be more actively using it. Plus I abhor the fact that configure scripts waste so many cycles running the same tests over and over again, especially when everything exists that's needed to cache and re-use the results! I just ran across the another that seemed to have a real problem: bison But then again Bison has gone so far down the autoconf rabbit hole I'm amazed it builds on anything. Shouldn't any program like that be pure Standard C + a tiny bit of POSIX, with no need for any #ifdef whatsoever? It just reads and writes text files for goodness sake!!! So my list where I've added AUTOSWC_DISABLE=yes so far is just: devel/bison devel/chrpath devel/libtool[-base] graphics/adwaita-icon-theme lang/erlang # because is messes up the cache file! net/tcl-scotty # I think -- it has an ancient configure script net/trafshow There is also at least one package that doesn't get any useful effect from the cache file because its configure script is from the dark ages: lang/js -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpZjzqC55zzF.pgp
Description: OpenPGP Digital Signature