Re: split bootstrap in two phases - .sh suffix

[Bruno Haible]

Simon Josefsson wrote:
> > The first phase is a script 'autopull.sh'.
> > The second phase is a script 'autogen.sh'.
> ...
> > The names of these scripts end with '.sh' in order to make them easily
> > editable in editors that recognize the file type from the suffix.
> 
> What do you think about dropping the .sh suffix?  As far as I know, few
> if any tools that users/developers are expected to invoke have a .sh
> extension.  To me, these scripts are similar to ./configure or
> ./bootstrap and we haven't used the .sh suffix for those.

That was my initial thought too: If we want a standard interface for
invocation only, then we don't need a suffix.

But:
  * The majority of packages will probably (like libunistring, gettext,
    libiconv, libsigsegv, gperf, etc.) continue to use hand-written
    autopull and autogen scripts. Simply because a 10-lines hand-written
    script is easier to start with than yet another configuration
    file whose syntax and semantics has to be understood.

  * Such scripts share the same limitations as configure: They can call
    only the coreutils, sed, grep, and git. Therefore it's unlikely that
    they will be compiled programs or python or perl scripts.

  * By adding the suffix '.sh' we're inviting the developers to see what's
    in it, rather than to consider them as a black box. And to create
    their own from scratch.

> I know autogen.sh is a common idiom, but it does different things in
> different projects

If the concept of the two phases, that you defined, is convincing, the
other packages will converge to this semantics over time.

Bruno