unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: David Bremner <david@tethera.net>,
	Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: subsequent rebuilds of notmuch always re-build sphinx and ruby
Date: Mon, 22 Apr 2019 19:19:31 -0400	[thread overview]
Message-ID: <87h8apvda4.fsf@fifthhorseman.net> (raw)
In-Reply-To: <87mukjcg3l.fsf@tethera.net>

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Sun 2019-04-21 16:29:02 -0300, David Bremner wrote:
> the html rebuild is much faster than the texinfo + info rebuilds.

agreed, in the runs that i've been doing as well.  I was concerned that
the html rebuild itself may have been *triggering* the rebuild of the
texinfo stuff, though.  Sounds like you don't think that's the case.

> I've posted some patches for the sphinx-doc issues a couple of hours ago
> (id:20190421171245.19729-1-david@tethera.net). 

thanks!  your own commentary on that series seems to acknowledge that
there are problems with it (though i don't understand the tradeoffs
well).  i'm not super comfortable with make-style "stamping": my
experience with it is that it creates a synchronization problem, and
it's easy for the "sync" between the stamp and the generated artifacts
to break, at which point the safest thing is to "make clean" and start
fully over.

Is there no way to give make itself full visibility into the specific
generated files so it can do its comparisons directly?  I'm obviously
not asking you to rewrite the entire native sphinx build system, i'm
just observing that at present it seems suboptimal, though i don't know
how to fix it either :/

> Currently the ruby rebuild doesn't seem to be slowing things down much
> for me.
>
> ╭─ convex:~/software/upstream/notmuch 
> ╰─ (git)-[wip/make-docs]-% /usr/bin/time make ruby-bindings 1>/dev/null
> 0.13user 0.02system 0:00.15elapsed 101%CPU (0avgtext+0avgdata 11504maxresident)k
> 0inputs+208outputs (0major+6523minor)pagefaults 0swaps
>
> That's with an SSD, so maybe there's more of hit for other environments.

I agree, this one isn't particularly slow, and it appears to be a leaf
dependency (for now), so it's not the worst thing.  But it's still
pretty clearly a bug that this thing loops.

       --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

  reply	other threads:[~2019-04-22 23:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-20 20:43 subsequent rebuilds of notmuch always re-build sphinx and ruby Daniel Kahn Gillmor
2019-04-21  0:12 ` David Bremner
2019-04-21  3:14   ` Daniel Kahn Gillmor
2019-04-21 19:29     ` David Bremner
2019-04-22 23:19       ` Daniel Kahn Gillmor [this message]
2019-04-23  0:03         ` David Bremner
2019-04-23 21:43           ` Daniel Kahn Gillmor
2019-04-24  1:09             ` David Bremner
2019-04-24  5:11               ` Daniel Kahn Gillmor
2021-12-24 16:20             ` [PATCH] doc: add dep. on stamp file for rebuilding gzipped man pages David Bremner
2021-12-25  9:39               ` Tomi Ollila
2021-12-25 11:37               ` David Bremner
2021-10-30 20:48 ` Add stamp files to prevent rebuilds David Bremner
2021-10-30 20:48   ` [PATCH 1/3] doc: introduce stamp file for info build David Bremner
2021-10-30 20:48   ` [PATCH 2/3] ruby: don't use a directory as a target David Bremner
2021-10-30 20:48   ` [PATCH 3/3] python-cffi: introduce stamp file David Bremner
2021-12-04 23:44   ` Add stamp files to prevent rebuilds David Bremner
2021-12-04 23:47   ` [PATCH 1/2] doc: replace phony target with variable David Bremner
2021-12-04 23:47     ` [PATCH 2/2] doc: introduce stamp file for info build David Bremner
2021-12-23 12:24     ` [PATCH 1/2] doc: replace phony target with variable David Bremner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h8apvda4.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=david@tethera.net \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).