bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Bruno Haible <bruno@clisp.org>
Cc: bug-gnulib@gnu.org
Subject: Re: [PATCH 0/6] build-aux/bootstrap that doesn't need to replace itself
Date: Tue, 27 Dec 2022 18:16:17 -0800	[thread overview]
Message-ID: <e9bd3452-94c8-a74f-21c5-87ce7776f849@cs.ucla.edu> (raw)
In-Reply-To: <2347260.KlZ2vcFHjT@nimes>

On 12/27/22 13:09, Bruno Haible wrote:
> I strongly object against the backwards move regarding the autopull.sh /
> autogen.sh *concepts*.

The concepts are still there; the only issue is the API. Whether the API 
should be './bootstrap --pull && ./bootstrap --gen' or './autopull.sh && 
./autogen.sh' is a relatively minor detail, as far as the 
pull-vs-generate concepts are concerned.

When the API was proposed I put it on my list of things to worry about, 
and unfortunately I didn't get around to thinking about it seriously 
until recently. Having done so, I took the trouble of implementing and 
suggesting a API that seems to be better for developers of gzip, tar and 
I assume other packages.

Even if we can't agree whether the newer API is better enough to 
standardize on, that should be OK. People doing software imports already 
have to deal with dozens of such APIs, and whether there's one vs two 
more APIs won't make much difference. That being said, if it matters to 
have just one API for Gnulib-using apps, I can volunteer to help migrate 
any packages already using the autogen.sh/autopull.sh API; it shouldn't 
be that hard, and these packages can even continue to support both APIs 
if that is needed for some reason.

>      it encourages packages to clump two different things into a single
>      script.

That shouldn't be much of a problem, any more that it's much of a 
problem that "git fetch" and "git diff" are in a single "git" command.

The current implementation is not cast in stone, and we can to work to 
make it better, more flexible, improve the documentation, etc.

PS. I got one private email from someone else in response to the recent 
patches, in that they didn't like the name "autogen". Not sure what name 
they'd prefer or why, but have asked.

      reply	other threads:[~2022-12-28  2:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-27 18:59 [PATCH 0/6] build-aux/bootstrap that doesn't need to replace itself Paul Eggert
2022-12-27 18:59 ` [PATCH 1/6] Move scriptversion= lines up in scripts Paul Eggert
2022-12-27 18:59 ` [PATCH] stdnoreturn: deprecate Paul Eggert
2022-12-27 18:59 ` [PATCH 2/6] Make autogen a shell function too Paul Eggert
2022-12-27 18:59 ` [PATCH 3/6] Make autopull " Paul Eggert
2022-12-27 19:00 ` [PATCH 4/6] Bootstrap with functions, not scripts Paul Eggert
2022-12-27 19:00 ` [PATCH 5/6] Support packages with just 'bootstrap' Paul Eggert
2022-12-27 19:00 ` [PATCH 6/6] Add --pull, --gen options to build-aux/bootstrap Paul Eggert
2022-12-27 21:09 ` [PATCH 0/6] build-aux/bootstrap that doesn't need to replace itself Bruno Haible
2022-12-28  2:16   ` Paul Eggert [this message]

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=e9bd3452-94c8-a74f-21c5-87ce7776f849@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.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).