Observations on build of 'make-3.80' on Debian

[Soren A]

I am not sure who to complain to, but I am sure that I want to.

I must just be a sucker for advertizing, although I try not to be. I
don't generally go for the easy-to-spot hyped come-on's but I seem to
nonetheless be completely hooked and duped by the widespread notion that
knowing this formula ought to be enough to build most GNU and GNU-ish
software:

   [somedirspec]/configure [config-opts]
   make
   make test
   make install

Sure doesn't work for GNU make-3.80.

Let me back up and try to describe what I did. I acquired a fresh shiny
new Debian GNU-Linux system recently (kruft-free as it is a brand-new,
professionally prepared installation). 'Woody' [Stable] running kernel
2.4.18. I then began to add packages to get it to be a tricked-out
Development system (as opposed to adding stuff to make it a supercharged
WWW server, or a multimedia viewing platform, for example). It came with
the "Stable" releases of GNU Auto* [stuff] packages already installed, of
course.

I downloaded the Unstable branch of 'make' as source code
(make_3.80-1.dsc for those who understand how Debian distributes ported
software package sources). Two files accompany that named file to make a
trio of files (that is, a .dsc file, a .diff.gz file, and an
.orig.tar.gz file containing the 'make-3.80' sources and build-support
files as distributed by the "upstream maintainer" [that would be Paul D.
Smith]).

"Unstable" is the only branch of Debian that has 'make-3.80'.

Being concious of the need to improve my understanding of how Debian
packaging works, I tried to simulate in a stepwise fashion what the
Debian 'dpkg' tools would do to create a binary upload package from this
source code. So I first unpacked the Debian source files into their
distro dir:

  dpkg-source -x make_3.80-1.dsc

That creates the canonical 'make' dist-tree + a "debian/" subdir
with the Debian package control files in it. Amongst those files is one
called "rules" which is in fact a Makefile. I then did this:

  make -f debian/rules configure

to accomplish the configuration of the package build setup. It runs
fine, just as one would expect. The reason for doing this is that the
'rules' file contains Debian-appropriate settings for the 'configure'
options and runs 'configure' for you with things set as they ought to
be. Anyway, in the top-level dir of the dist-tree, a Makefile is
created, as it is in each subdir ('doc/','glob/', etc.).

I then tried to actually build 'make' using (of course) the generated
Makefile in the top-level dir. This fails. The problem, as usual, is the
Automake-generated Makefile that `config.status' brings into existance:

  cd . && \
        /bin/sh /home/somian/src/src.ref/make-3.80/config/missing --run 
automake-1.7 --gnu  Makefile
  /home/somian/src/src.ref/make-3.80/config/missing: automake-1.7: command 
not found
  WARNING: `automake-1.7' is missing on your system.  You should only need 
it if
                   you modified `Makefile.am', `acinclude.m4' or 
`configure.in'.
                   You might want to install the `Automake' and `Perl' 
packages.
                   Grab them from any GNU archive site.
  cd . && /bin/sh /home/somian/src/src.ref/make-3.80/config/missing --run 
autoconf
  aclocal.m4:211: error: Autoconf version 2.54 or higher is required
  aclocal.m4:211: the top level
  make: *** [configure] Error 1

I know I don't have the latest Autotools installed. I will get them
installed, later, always planned to. I am a developer, I know (and
deeply dislike because of years of experiences like this on Win32-ish
platforms) the Autotools. I had thought until now that maybe my numerous
miseries with Automake were partly due to it being imperfectly-ported to
Win32-ish build environments (Cygwin, MinGW). Nope, it appears not -- if
Automake doesn't create workable Makefile's on *GNU-Linux*, for Pete's
sake, then my long-held conviction that Automake is deeply broken seems
more true than ever.

Point: 'make' is a "bootstrapping" tool. You cannot get much done on a
*nix system without having a 'make' utility first. To argue that a user
first has to have a latest (or *any whatsoever*) version of Autotools
installed *first* before one can compile 'make' would seem very dubious
reasoning, so let's get that one out of the way right now.

Is the link between 'make' and 'Automake' so firmly welded at this point
that I have no other recourse but to run the build shell script, having
to eschew building 'make' with 'make' entirely?

It's going to require extra non-trivial effort to install latest
Autotools because (as some will know) that's not how Debian works -- it
isn't like Cygwin where you just update your installation with whatever
new release of a package is made available. Debian is very conservative
about new releases and overriding a "stable" - branch package selection
to get a "testing" or a "unstable" package version (when you are running
the "stable" release of Debian) is troublesome. I'll have to create a
'latest Auto*' setup from sourcecode for all the Autotools manually.
Non-trivial.

And not only non-trivial but also in violation of principle. For what
seems like the 30,521st time I will note publicly (and yes, I've told
Tom Tromey this) that "this isn't the way it was supposed to be" [with
Autotools]. Users were not supposed to have to have Autotools installed,
simply in order to build Autotool'ed packages. Autotools are in fact
making Open-Source/Free software *less* Open and Free by placing big
barriers in the way of the hacker and the porter or the tweaker or
optimizer who wants to build software from source code.

That statement bears repeating I think.

  ***Users were not supposed to have to have Autotools installed,
     simply in order to build Autotool'ed packages.***

So who is to blame here? Is it the Debian volunteer package maintainer
for 'make', or is it Paul Smith, or is just bad luck?

I have a suggestion for Paul irregardless of any other argument or
point: Paul, please enable AM_MAINTAINER_MODE in the 'configure' (via
"configure.ac") so that the troublesome dependencies that break the build
are commented-out in the final Makefile. It may cause you a little extra
trouble / work to do this, but I think it is philosophically the "Right
Thing"(TM) to do.

As Paul and others may remember, I had (last year) put a lot of time
into hacking on the build configuration for 'make-3.80rcN'. I
deliberately set aside that knowledge and work here to try to
demonstrate what will happen to a novice user who attempts to build
'make' without knowing much more than the basics (how to run 'configure'
and then invoke 'make'). Now that I have had this experience I will get
to work on creating a comprehensive patch comprising my suggested
changes for the 'make' build setup files, but the No. 1 suggestion is
simply the enablement of AM_MAINTAINER_MODE just cited above.

Thanks all readers for your time and attention.

  Best Regards,
    Soren Andersen