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
