Re: subsequent rebuilds of notmuch always re-build sphinx and ruby

[David Bremner <david@tethera.net>]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> Hi folks--
>
> when i run "make" from my source tree, and it succeeds, i typically
> expect that running "make" again will show that nothing needs to be
> done.
>
> but that's not the case.  Both the sphinx-based documentation and the
> ruby notmuch.so are always rebuilt, i think due to some sort of
> dependency loop.
>
> But i don't really understand the dependencies there.  Maybe someone who
> understands either ruby or sphinx better than i do can clean it up?
> Having clean dependency tracking and quick rebuilds makes a project a
> lot more fun to hack on.
>
> Here's a trace of the rebuild process:
>
> 0 dkg@alice:~/src/notmuch/notmuch$ ./configure && make
>  […]
> make[1]: Leaving directory '/home/dkg/src/notmuch/notmuch/bindings/ruby'
> 0 dkg@alice:~/src/notmuch/notmuch$ make --trace
> doc/Makefile.local:53: update target 'sphinx-html' due to: docstring.stamp
> sphinx-build -b html -d doc/_build/doctrees -q ./doc doc/_build/html
> doc/Makefile.local:56: update target 'sphinx-texinfo' due to: docstring.stamp
> sphinx-build -b texinfo -d doc/_build/doctrees -q ./doc doc/_build/texinfo
> doc/Makefile.local:59: update target 'sphinx-info' due to: sphinx-texinfo
> make -C doc/_build/texinfo info
> make[1]: Entering directory '/home/dkg/src/notmuch/notmuch/doc/_build/texinfo'
> Makefile:32: update target 'notmuch-search-terms.info' due to: notmuch-search-terms.texi

This is not our Makefile, but something generated by sphinx; it would
not be that hard to replace if the problem was there. Alas I think the
underlying problem seems to be that "sphinx-build -b texinfo" is
regenerating (or at least touching) all of the texi files. I suspect
that's a limitation of sphinx-builder texinfo output.

> cd bindings/ruby && \
> 	EXTRA_LDFLAGS="-Wl,--no-undefined" \
> 	LIBNOTMUCH="../../lib/libnotmuch.so" \
> 	NOTMUCH_SRCDIR='/home/dkg/src/notmuch/notmuch' \
> 	ruby extconf.rb --vendor
> creating Makefile
> make -C bindings/ruby
> make[1]: Entering directory '/home/dkg/src/notmuch/notmuch/bindings/ruby'
> Makefile:258: update target 'notmuch.so' due to: Makefile
> echo linking shared-object notmuch.so
> linking shared-object notmuch.so
> rm -f notmuch.so
> gcc -shared -o notmuch.so database.o directory.o filenames.o init.o message.o messages.o query.o status.o tags.o thread.o threads.o -L. -L/usr/lib/x86_64-linux-gnu -L. -Wl,-z,relro -Wl,-z,now -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,--compress-debug-sections=zlib   ../../lib/libnotmuch.so -lruby-2.5  -lpthread -lgmp -ldl -lcrypt -lm   -lc
> make[1]: Leaving directory '/home/dkg/src/notmuch/notmuch/bindings/ruby'
> 0 dkg@alice:~/src/notmuch/notmuch$

This Makefile is generated by "ruby extconf.rb --vendor". It includes a
dependency on itself, so it always fires after running "ruby
extconf.rb". It might be only running "ruby extconf.rb" if
bindings/ruby/Makefile does not exist would fix this particular
issue. That sounds more gnu make specific than ruby specific.

d