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
