thanks for the review, Bremner!

On Sat 2019-04-20 21:12:07 -0300, David Bremner wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>> 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.

but it's not just texinfo, right?  it starts with the html build
itself.  can we at least diagnose why that's happening?

>> 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.

I'd be happy to test any proposed patches.  I don't really understand
this toolchain, or why anyone would build a makefile that rewrites
itself :/

       --dkg