Re: portability of xargs

[NightStrike]

On Tue, Feb 15, 2022 at 6:01 PM Bob Friesenhahn
<bfriesen@simple.dallas.tx.us> wrote:
> The people who tell me it is more portable are very interested in
> targeting Microsoft Windows.

Introduce them to mingw-w64.sf.net + msys2 :)  I heard good things
about those :P

> The "Makefiles" that Cmake generates are self-referential in that
> almost all rules invoke Cmake to do the work.

> I find that the function of Autoconf is quite useful.  When compared
> with Cmake, it is much more user-friendly since the configure script
> responds to --help and the help output is very helpful.  The configure
> script nicely tells me what it is doing and what it found.  Autotools
> is very structured and projects work in a common way whereas I find
> that Cmake projects are heavily customized with options added by the
> project developer.  Just doing a build entirely outside of the source
> tree is extremely clumsy with Cmake.
>
> Regardless, I don't think that Autotools developers should waste time
> on assuring compatability with systems which are no longer in active
> use.  It is much better so spend time improving areas where Autotools
> is weak.

"Portability" is impossible to quantify.  It expands to far more than
support of ancient, esoteric tools.

I would argue that Cmake is less portable, since it requires that
Cmake be available for a user to build the software.  That can be
onerous, especially if the user doesn't have permission to install
Cmake.  Autoconf requires 'sh', and automake requires 'make'.

I would further argue that Cmake is less portable because it's less
user friendly.  The poor man's distinction is that autotools makes
life for the project owner hard so that the life of the user is easy.
Cmake does the exact opposite, and makes the user's life a difficult
experience so that the developer's life is simpler.  I would
extrapolate that to the realm of "less portable", since it requires
that I have more system requirements in my own brain (skills,
knowledge, experience).  Whereas I can handle any autotools package
trivially with "./configure CFLAGS=-myflag CXX=myC++Compiler
--enable-option --with-package=/custom/path", and know very little
about the upstream project, I can't do so with a Cmake based build
system.

For me, this isn't about 32-year old artifacts.  This is about the
infinitely diverse nature of any modern, still maintained system.  In
a world of corporate policies, shifting environments, environment
modules, embedded devices, cyber security, firewalls, user
permissions, and all sorts of other mitigating factors, all of which I
personally must deal with when trying to deploy any given package to
an environment, I will pick autotools every single time.  The workload
required for me to deploy an autotools package is exponentially
smaller than that required of a Cmake package.