thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.35 2021-12-25T11:32:27Z 2021-12-25T11:32:27Z David Bremner david@tethera.net 2021-12-24T16:20:31Z urn:sha1:02d8ff376d77e5d96389c30576221a7ac5b4bea1 In [1] Daniel observed that the gzipped man pages were only being rebuild every second time when building with `make -j4'. This may be caused by a race condition between sphinx-build rebuilding the roff files and the recipe to gzip them. This commit sequentializes these two steps by making the stamp file a prerequisite for (all of) the gzip files. [1]: id:87tveotn1g.fsf@fifthhorseman.net 2021-12-23T12:01:28Z David Bremner david@tethera.net 2021-12-04T23:47:51Z urn:sha1:b7e08901e8ab695fb75de0528871771009f49aa8 This partially fixes (i.e. just for sphinx) the problem reported by Daniel in id:87r29wwgq2.fsf@fifthhorseman.net. 2021-12-23T12:01:11Z David Bremner david@tethera.net 2021-12-04T23:47:50Z urn:sha1:d825847b522f2b84abf087d90b57275502f37163 Depending on a phony target seems like a good way to always trigger a recipe. 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.