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
--
Bob Friesenhahn
bfriesen@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
