Re: portability of xargs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux