Ray Donnelly wrote (NOTE: I reordered the quotes so that my replies can be
read in order):
> I work in the Anaconda Distribution as a software packager and spend a
> significant amount of my working day battling cmake. As I say it's "ok"
> for developers but not for packagers.
I'm a packager for Fedora, a GNU/Linux distribution. I find CMake to be the
nicest build system to work with. It is common enough for there to be macros
and snippets/templates making it easy to package software using it.
The same theoretically applies to the Autotools, but the Autotools are a
pain as soon as you need to change something, because:
* the script that is executed is generated, so if you make any changes to
the actual source code, you have to rerun autoreconf or equivalent, and
* the syntax is harder to work with, so it is harder to make changes to
begin with.
CMake, on the other hand, only requires you to edit the CMakeLists.txt
file(s), with a much nicer syntax.
In addition, if we fix a bug in the autotools themselves, or in some aclocal
snippet, we also have to regenerate or patch the generated files in dozens
of packages bundling the generated scripts. On the other hand, if we fix a
bug in CMake or in a Find*.cmake/*Config.cmake installed systemwide, a
rebuild with no changes is enough to get other packages to pick up the fix.
Custom build systems only used by one or a handful project(s), such as QBS,
GN, etc. are a pain because they require custom build instructions in our
package specfiles that are specific to that build system (e.g., whereas
Autotools and CMake use DESTDIR, QMake insists on INSTALL_ROOT) and because
there are often no templates for those custom instructions (because your
package's specfile likely *is* the template).
(Sadly, I don't think we will ever be able to build QtWebEngine without GN
or yet another Chromium-only replacement (GN was already the replacement for
Gyp). Chromium insists on using custom non-standard tooling.)
And then there are the build systems that are a *real* pain, e.g., those
that try to automatically download dependencies from the Internet (a no-go
during our package builds). The only way to get dependencies downloaded is
*before* the build starts and only from Fedora packages (not some random web
location), by specifying them as BuildRequires in the specfile. The build
system must *never* attempt to download anything. As I understand it, Bazel
is one of the major offenders there.
> I'll not going to do this for you, sorry. I also pointed out the lack of
> isolation from system libraries by default as a major problem.
Here in Fedora, we actually *want* CMake to find system libraries. The
situation on Windows is of course different, and third-party packages for
GNU/Linux may or may not want to use the system libraries, but our
distribution packages definitely want to use them.
Kevin Kofler
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
