[ deliberately contradicting the Followup-To ]
In comp.os.linux.misc Nux Vomica <
[email protected]> wrote:
Thus, other build systems were created and more and more software
packages are moving to them. On contemporary GNU/Linux, the most
commonly used alternate build systems are:
Cmake
Meson (using Ninja as backend)
So what's the problem?
The difficulty is that now the software builder has to learn
several different systems and things are no longer as simple
as they once were with Autotools. Compared to Autotools, these
alternative build systems are decidedly more complex for the
builder even if they might make things easier for the programmer.
Indeed! I don't know if I've encountered Meson, but CMake drives
me up the wall. It's also far more restrictive for compatibility
than Autotools' configure scripts - you need a recent version of
CMake installed to build recent source code releases. The
CMake developers ignored requests for an equivalent to
"./configure --help" early on, willfully making the transition
difficult for software builders. I think they have a
Windows-centric attitude where they expect only the software
developers to be compiling things and hence making the build
settings easy to understand for others isn't a priority. Granted
if projects actually followed their advice to document the CMake
build settings they use, that would help too.
I am always in favor of choice. In fact, choice is one of the
great strengths of GNU/Linux. Yet when it comes to software
building from source I feel that only a single protocol is
necessary.
If looking for new software that I'll need to build myself, then
CMake is an immediate turn-off - I'll choose an alternative. It's
difficult when software I'm already building and using switches to
CMake though.
--
__ __
#_ < |\| |< _#
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)