bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/6] build-aux/bootstrap that doesn't need to replace itself


From: Bruno Haible
Subject: Re: [PATCH 0/6] build-aux/bootstrap that doesn't need to replace itself
Date: Tue, 27 Dec 2022 22:09:36 +0100

Hi Paul,

You write in <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56749>:

> I put the latter script into the gzip 
> repository but did not put the auxiliary files there. I did not notice 
> the error in my testing, since the three auxiliary files were there in 
> my working copy.

I'm sorry that the mechanism that I coded in July got you into making
a mistake.

But I strongly object against the backwards move regarding the autopull.sh /
autogen.sh *concepts*.

The concepts, as I described them in
  <https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00053.html>
  <https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00078.html>
are that

  * There are two preparation phases for a git repo, before the user
    can run configure: './autopull.sh' then './autogen.sh'.

  * These are *interfaces* between the package's code and the developer.
    Like the *interface* behind the 'configure' script. The purpose
    is that — over time, as more and more packages adopt these two script
    names — developers can just use these two script names as part of their
    habits.

The implementation (bootstrap script, bootstrap-funclib.sh function library)
are just an implementation of these concepts. If your implementation works
better than mine (by avoiding some possible pitfalls), then that's fine.

But what I object to is that you are killing the incentive for more packages
to adopt the autopull.sh / autogen.sh separation. In particular:

  * It's better to recommend in README-hacking

        $ # 1. Fetch auxiliary files from the network.
        $ ./autopull.sh
        $
        $ # 2. Generate files locally.
        $ ./autogen.sh

    because that's the two command names that the developer should remember
    and get used to work with.

    If you write

        $ ./bootstrap --pull  # 1. Fetch some files from the network.
        $ ./bootstrap --gen   # 2. Generate other files locally.

    then we have different command names for the same thing, and it
    encourages packages to clump two different things into a single
    script.

  * I object against omitting autopull.sh and autogen.sh from what gets
    copied into the package.

  * I object against documentation such as

        running @samp{./bootstrap --pull} or @file{autopull.sh}

    because two different commands (with 'or') does not help in creating
    a habit that is easy to remember and easy to use.

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]