[gnutls-devel] GnuTLS | consider using an alternative build system (#320)

[Development of GNU's TLS library]

autotools is strong with cross-compilation in a *nix environment and has an interface that users are familiar with, but other than that I dislike autotools:

- Its configure step is slow. A cache might help a bit with incremental runs, but that does not help with new builds.
- It requires autoreconf to be run before anything useful can be done. The dist tarball basically includes a binary blob (nobody is going to read the configure and Makefile.in files).
- It pollutes the source tree with Makefile.in and other autogenerated files. I am not aware of any solution for this problem.

I've limited experience with Meson (mostly as user), but with have more experience with CMake (I ported over autotools -> CMake for some projects and also work on Wireshark which supports Linux, macOS and Windows through CMake). Some projects spent the majority in autoreconf + configure, more than the actual compilation O_O.

CMake:

- Incremental builds are fast due to a cache (CMakeCache.txt). This file also remembers previous configuration options.
- No need for autoreconf, you can run the "configure" equivalent straight away.
- Support for out-of-source tree build without polluting the source tree.
- The configuration language is different, but should be more readable than shell code for some equivalent functionality.
- Support for native build systems like MSVC (would help with CI on Windows, #638).
- Supports generating a "compilation database" with `cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1`, useful for tools like `clang-check` or editor integration which can use the exact same compile options.
- PkgConfig is ubiquitous on Linux for locating packages, but not so much on Windows. CMake supports PkgConfig, but to locate dependencies you would use a "Find" module that locates the library file, header paths and version. This works for all platforms.
- I've never tried cross-compiling, but you'd typically use a "toolchain file" and set some other variables (like the root of the target).

Note that I have not built GnuTLS from git yet. I aborted it after it tried to spend a lot of time retrieving submodules (like openssl). The bootstrap process seems quite complex, couldn't it be simplified?

In general this is how autotools and CMake projects could run:

    autoreconf -vifs && mkdir build && cd build &&
    CFLAGS="-g" ../configure --disable-doc &&
    make -j$(nproc) &&
    DESTDIR=$PWD/tmp make install

    mkdir build && cd build &&
    cmake -GNinja -DCMAKE_BUIlD_TYPE=Debug -DENABLE_DOC=OFF .. &&
    ninja &&
    DESTDIR=$PWD/tmp ninja install

With meson I believe it will be something like:

    # set CC to avoid using ccache if installed. Meson does too much magic.
    CC=gcc meson setup build && cd build &&
    meson configure -Dbuildtype=debug -Denable_doc=false &&
    ninja &&
    DESTDIR=$PWD/tmp ninja install

Conversion of GnuTLS build system to either might be quite an undertaking since it has quite some custom logic (configure.ac and .mk files). When converting, typically both systems remain next to each other. Eventually one or more older build systems gets dropped when the CMake system is mature enough.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/320#note_122487335
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181205/1eb5621b/attachment-0001.html>