thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.34.3 2021-12-04T00:25:59Z 2021-12-04T00:25:59Z David Bremner david@tethera.net 2021-10-29T14:54:59Z urn:sha1:48b5263646bae2ce40e3ec17e0cfae26a7abc91f Previously the python-cffi bindings either failed to build, or built for the wrong module by using the installed module. The fix requires correction the module path, building the bindings before docs, and helping python find the built libnotmuch. Based on patch / discussion from Micheal Gruber [1] [1]: id:cover.1634808719.git.git@grubix.eu 2020-12-10T01:55:38Z David Bremner david@tethera.net 2020-12-10T01:55:38Z urn:sha1:ed7ca948ae31ac0e1d3633a2f58fb3e4aecd03de Under a sufficiently high level of parallelism [1] there seems to be a a race condition that allows sphinx-build to start running before the docstrings are extracted. This change moves the docstring stamp from the phony targets sphinx-html and sphinx-info to the file targets that they depend on. I'm not sure why this makes things better, but I am fairly confident it does not make things worse, and experimentally it seems to eliminate the race condition. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976934 2020-08-10T00:14:36Z Jonas Bernoulli jonas@bernoul.li 2020-08-08T11:49:49Z urn:sha1:c4541353765dec837c1c2f912b1bf6661827429c Use `makefile-gmake-mode' instead of `makefile-mode' because the former also highlights ifdef et al. while the latter does not. "./Makefile.global" and one "Makefile.local" failed to specify any major mode at all but doing so is necessary because Emacs does not automatically figure out that these are Makefiles (of any flavor). 2020-07-15T11:32:15Z David Bremner david@tethera.net 2020-07-11T13:20:26Z urn:sha1:0e03e2d45e36edb635229f356bf41f153c30a70f It is getting unwieldy to pass configuration options on the sphinx-build command line, and I anticipate further use of conditionals. As far as I could tell, execing a string is the idiomatic way to emulate include in Python. 2020-07-11T16:57:17Z Jonas Witschel diabonas@archlinux.org 2020-07-11T16:04:35Z urn:sha1:a962842d9b0b43b7d218860b196eecd5ef666088 gzip includes the name of the uncompressed file and its modification timestamp into the compressed archive. The latter makes it hard to reproduce the generated files bit for bit at a later time, so omit this information from the archive using the "--no-name" option. This is a reproducibility best practice, see https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders 2020-06-01T12:07:50Z David Bremner david@tethera.net 2020-05-31T16:15:03Z urn:sha1:ee8dba1c3013a00c0d1185583ea084f8ce3699b7 The sphinx-doc include directive does not have the ability to include files from the build tree, so we replace the include with reading the files in conf.py. The non-trivial downside of this is that the emacs docstrings are now defined for every rst source file. They are namespaced with docstring::, so hopefully there will not be any surprises. One thing that is noticable is a small (absolute) time penalty in running sphinx-doc. 2019-06-12T22:58:30Z David Bremner david@tethera.net 2019-06-12T00:12:38Z urn:sha1:a6a8df7e0379bfb6e69b9541d7813ac71f624f2e The extra flexibility of having both HAVE_EMACS (for yes, there is an emacs we can use) and WITH_EMACS (the user wants emacs support) lead to confusion and bugs. We now just force WITH_EMACS to 0 if no suitable emacs is detected. 2019-06-11T00:48:03Z David Bremner david@tethera.net 2019-06-10T10:11:50Z urn:sha1:3ec47e1165064d4937044c02e882612a3e3a7671 In 40b025 we stopped building the notmuch-emacs documentation if HAVE_EMACS=0 (i.e. no emacs was detected by configure). Unfortunately we continued to try to install the (non-existent) documentation, which causes build/install failures. As a bonus, we also avoid installing the documentation if the user configures --without-emacs. Thanks to Ralph Seichter for reporting the problem, and testing previous versions of this fix. 2019-06-11T00:46:55Z David Bremner david@tethera.net 2019-06-11T00:06:57Z urn:sha1:71bf459596c72cf72b89c6ae2f47b1f5cf7548db Since the docstrings are not built in the case of --without-emacs, even if emacs is detected, don't let sphinx build the emacs docs. This avoids a large number of error messages due to missing includes. It's actually a bit surprising sphinx doesn't generate an error for the missing include files. 2019-06-03T10:35:30Z David Bremner david@tethera.net 2019-06-01T02:24:52Z urn:sha1:6edc073e4496b71d24e339f4d0cca41c2e4ac3e1 It seems our previous attempt with order-only targets was not sufficient to avoid problems with sphinx-builds doctree cache [0]. Looking around at other people's approaches [1], using separate doctrees was suggested. I guess there might be a slight loss of efficiency, but it seems more robust. [0]: build failures were first noticed in Debian experimental, but I was able to duplicate it in my usual build environment about 1 in 8 builds. [1]: in particular https://salsa.debian.org/mpd-team/mpc/commit/9e3fc1657d043d75755993846c93f7700b97f907