bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Simon Josefsson <simon@josefsson.org>
Cc: bug-gnulib@gnu.org
Subject: Re: gnulib-tool caching
Date: Mon, 19 Feb 2024 22:50:29 +0100	[thread overview]
Message-ID: <8818676.c0te8JeNC1@nimes> (raw)
In-Reply-To: <87plws4nqh.fsf@kaka.sjd.se>

Simon Josefsson wrote:
> I now
> remember that something like this was discussed before:
> https://git.savannah.gnu.org/cgit/libidn.git/commit/?id=9ae53e866a6fafa56db26d184ccae9c39dae7446
> https://lists.gnu.org/archive/html/bug-gnulib/2021-05/msg00077.html

I see... you are building a cache that will become invalid when either
  - the bootstrap.conf changes, or
  - there is a change in gnulib in one of the request modules (in the
    module description or in code).

> My usage pattern is to frequently re-bootstrap from a clean git checkout
> to confirm that my changes still work properly for fresh rebuilds.  The
> reason is that I don't trust 'make clean', 'make distclean', etc.

With your cache, you'll now have to trust your decision whether to use
or erase the cache. But at least, you can automate this decision:
erase the cache when bootstrap.conf or the referenced gnulib submodule
was changed.

In other words, replace the cache file name


  reply	other threads:[~2024-02-19 21:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-19  1:24 [PATCH] gnulib-tool.py: Fix function call on incorrect object Collin Funk
2024-02-19  2:17 ` Bruno Haible
2024-02-19  8:59   ` Simon Josefsson via Gnulib discussion list
2024-02-19 10:38     ` gnulib-tool caching Bruno Haible
2024-02-19 12:55       ` Simon Josefsson via Gnulib discussion list
2024-02-19 21:50         ` Bruno Haible [this message]
2024-02-19 22:24           ` Sam James
2024-02-19 23:11             ` Bruno Haible
2024-02-19 23:17               ` Sam James
2024-02-19 18:37   ` [PATCH] gnulib-tool.py: Fix function call on incorrect object Collin Funk
2024-02-19 21:36     ` Bruno Haible
2024-02-19 22:42       ` Collin Funk

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:

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

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

  git send-email \
    --in-reply-to=8818676.c0te8JeNC1@nimes \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=simon@josefsson.org \


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