[Top][All Lists]

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

Re: portability of xargs

From: Bob Friesenhahn
Subject: Re: portability of xargs
Date: Tue, 15 Feb 2022 16:59:51 -0600 (CST)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Tue, 15 Feb 2022, Paul Smith wrote:

On Tue, 2022-02-15 at 15:37 -0600, Bob Friesenhahn wrote:
I have been told by several people (who have much more self-esteem
than me) that a build tool called 'cmake' is far more portable than
Autotools so maybe we should make support for 32 year old systems
cmake's responsibility?

That is not accurate.  Or at least, cmake uses a much different
definition of "portable" than autoconf / automake.  Certainly cmake
cannot possibly support 32-year old systems (if that's needed).

Thanks for the nice response. I did not for a minute think that what I was told was accurate.

The people who tell me it is more portable are very interested in targeting Microsoft Windows.

cmake is a tool that, given an input definition of build dependencies,
can generate build control files for multiple different types of build
tools.  It can generate makefiles, Ninja files, Xcode project files,
and Visual Studio project files.  Maybe others, I'm not sure.

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

The main idea of autoconf is that it allows configuring the package for
systems that the author never even heard of, much less has access to
(as long as it has a POSIX interface).  cmake only tries to generate
output files for systems it has been developed for (for example, each
new version of Visual Studio often requires a new release of cmake to
support it).

The above is a perfect description of the situation.

Of course maybe autoconf is not necessary anymore: I don't know about
that.  I do know that even though GNU make itself is relatively simple,

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.

If 'xargs' has worked consistently for 20 years, it should be ok to use.

Bob Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]