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.
prev parent 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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 \
/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.
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).