[gnutls-devel] GnuTLS | consider using an alternative build system (#320)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Mon Dec 30 14:24:21 CET 2019
Xavier Claessens commented on a discussion: https://gitlab.com/gnutls/gnutls/issues/320#note_265862431
Glib indeed has it's own copy of gnulib code and wrote their own meson build definition for it.
However, now that glib dropped autotools, I think they should instead use gnulib as subproject, and either:
- merge meson build definition upstream
- have a "fork" git repo with meson
- put it in wrapdb, it's a collection of projects for which meson.build files are stored in a separate tarball. That helps using common non-meson projects as meson subproject.
Having gnulib as subproject means meson can download and build it for you if not found on the system. On less dependency to care about for the user.
Doing this, and having gnutls as meson project, would mean glib-networking could use gnutls as subproject, and share the same build of gnulib, instead of having 2 copies currently, as far as I understand.
IMHO the build speed is great but it's not the main adventage of meson. I like meson because it makes the build definition a lot nicer than obscure shell and m4 scripts that nobody really understand. And it supports more advanced features like subproject.
Finally, I don't think Python 3 is a big dependency. It is available everywhere and much easier to install that autotools. Especially on Windows autotools requires msys2 or similar Unix env, that is not needed with meson.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/320#note_265862431
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/20191230/100ee588/attachment.html>
More information about the Gnutls-devel
mailing list