Meson is a candidate for such a next-gen config system. It is in python, which does not quite qualify as usable during early uplift/bootstrap, but there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/ In the meantime, I agree that find is more portable than cards ;-) - Dan Daniel Herring <dherring@xxxxxxxxxxxx> schrieb am Mo., 14. Feb. 2022, 22:17: > Hi Mike, > > It often makes sense to change a project that uses Autotools rather than > modifying the Autotools. Can this argument-splitting behavior be > documented as expected? Are no workarounds available? > > Replacing "overly fancy but proven shell script" with "dependency on a new > tool" may replace an obscure problem for one project with an intractable > problem that breaks portability (to obscure platforms) for all projects. > I have distant memories of working through similar problems by tracing > configure scripts and makefiles, redirecting the problematic command lines > to files, and monkey-patching them before execution. Tedious but doable > due to the simplicity of the tooling, even in a cross compile. Getting a > "functional" xargs would have been MUCH harder in that environment. > > IMO, you are touching on the fundamental issue of Autotools. Portable > shell scripting is one of the worst programming environments available > today, and it hinders progress and adoption, but it is the mostly widely > available bootstrapping environment available. Autotools embodies decades > of hard-won experience, and people rightly want to use it on new projects, > but they are weighed down by all the baggage of history, even when it is > not even remotely relevant. > > As the years go by, this tradeoff is getting less justifiable. I hope a > better bootstrapping environment will come along. Something that ports > the spirit of Autotools to a much better language. Maybe a subset of > Python that can bootstrap from shell? Many would argue for cmake or one > of the newer build systems, but they all seem to miss one or more > fundamentals of the Autotools. At a minimum, they should address the > concerns about imake in the Autoconf FAQ. ;) > > > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Why-Not-Imake.html > > Maybe a next-generation configuration tool should start by defining > interfaces for user interactions and build tools. This would allow CLI > and easy GUI and IDE users, integration with multiple build systems, > static and dynamic probing, ... > > -- Daniel > > > On Mon, 14 Feb 2022, Mike Frysinger wrote: > > > context: https://bugs.gnu.org/53340 > > > > how portable is xargs ? like, beyond POSIX, as autoconf & automake both > > support non-POSIX compliant systems. i want to use it in its simplest > > form: `echo $var | xargs rm -f`. > > > > automake jumps through some hoops to try and limit the length of > generated > > command lines, like deleting output objects in a non-recursive build. > it's > > not perfect -- it breaks arguments up into 40 at a time (akin to xargs > -n40) > > and assumes that it won't have 40 paths with long enough names to exceed > the > > command line length. it also has some logic where it's deleting paths by > > globs, but the process to partition the file list into groups of 40 > happens > > before the glob is expanded, so there are cases where it's 40 globs that > can > > expand into many many more files and then exceed the command line length. > > > > if i can assume `xargs` is available, then i think i can replace all of > this > > custom logic with a simple call to that. > > -mike > > > >
