[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: portability of xargs
Re: portability of xargs
Mon, 14 Feb 2022 22:57:10 -0800
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 ;-)
Daniel Herring <email@example.com> 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. ;)
> 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
> > command lines, like deleting output objects in a non-recursive build.
> > not perfect -- it breaks arguments up into 40 at a time (akin to xargs
> > and assumes that it won't have 40 paths with long enough names to exceed
> > 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
> > before the glob is expanded, so there are cases where it's 40 globs that
> > 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
> > custom logic with a simple call to that.
> > -mike
Re: portability of xargs, Daniel Herring, 2022/02/15
Re: portability of xargs, Jan Engelhardt, 2022/02/15
Re: portability of xargs, Nick Bowler, 2022/02/15
- Re: portability of xargs,
Dan Kegel <=