Dear List, I've been working on implementing a meson[0] build for Balsa, as an alternative to the autotools build. Git users may have noticed some related commits. No non-meson files were touched, so the usual 'configure-make-make install' works the same as always. The meson files obviously have to incorporate the build information embodied in configure.ac and all the Makefile.am files, so I had to go through them line by line to decipher that information. Much of it is quite inscrutable! One odd legacy option is --with-gnome. Choosing it has three consequences: (1) Add "GNOME" to the Categories in Balsa's .desktop files. (2) If libsecret is not being used to manage passwords, gnome-keyring is checked as an alternative; it has been deprecated in favor of libsecret for a while, but libsecret may not be available in all distributions. (3) HAVE_GNOME is defined; it is referenced only in the toolbar code, where GSettings is used only if HAVE_GNOME is defined. Of these, (1) seems reasonable. (2) might be better implemented as a separate option like '--with-password-manager = libsecret | gnome-keyring | internal' (Balsa does have its own private config file for passwords), as there is no apparent reason for tying it to the content of the .desktop files. But (3) baffles me: GSettings is part of libgio, which is always used by Balsa. It does require a backend, but is there any setup where none is provided? If there is, we should have another option like '--enable-gsettings = yes | no", but I see no reason for tying it to --with-gnome. Any insights or suggestions are welcome! Peter [0] http://mesonbuild.com/
Attachment:
pgpxw6RSD27wv.pgp
Description: PGP signature