Re: more build sherrif-ery (and a touch of auto*)

[Daniel Reed <n ml org>]

On 2004-11-12T15:38+0800, James Henstridge wrote:
) Havoc Pennington wrote:
) >It may need to be clarified to upstream automake guys that if two
) >versions are compatible, they should have the same binary name?
) Maybe Daniel can answer this question.

Earlier releases of Automake may have changed the API version primarily due
to breakage between the previous release and the new, allowing packagers to
stick to an older version for packages that relied on the previous
[now-considered-buggy] behavior.

As the control file format stabilizes more and more, Automake might change
the API version primarily when significant new features are introduced,
allowing packagers to guarantee use of a *newer* version for packages that
rely on the newly-available features. (For example, if a package requires
functionality present only in 1.8, and for whatever reason the user installs
Automake 1.7 after installing 1.8, the /bindir/automake executable might be
repointed to the 1.7 version. If the user then changes a build control file,
such as Makefile.am, the package's build scripts would need to be able to
get at 1.8 even with 1.7 installed.)



As of the 1.9.2 release, GNU Automake includes its history in its Info
manual. The API bits:

2001-08-23 Automake 1.5
     A major and long-awaited release, that comes more than two years
     after 1.4.  It brings many changes, among which:
        * The new dependency tracking scheme that uses `depcomp'.
           ...

        * Support for per-target compilation flags.

        * Support for reference to files in subdirectories in most
          `Makefile.am' variables.

        * Introduction of the `dist_', `nodist_', and `nobase_'
          prefixes.

        * Perl 4 support is finally dropped.

     1.5 did broke several packages that worked with 1.4.  Enough so
     that Linux distributions could not easily install the new Automake
     version without breaking many of the packages for which they had
     to run `automake'.

     Some of these breakages were effectively bugs that would
     eventually be fixed in the next release.  However, a lot of damage
     was caused by some changes made deliberately to render Automake
     stricter on some setup we did consider bogus.  For instance `make
     distcheck' was improved to check that `make uninstall' did remove
     all the files `make install' installed, that `make distclean' did
     not omit some file, and that a VPATH build would work even if the
     source directory was read-only.  Similarly, Automake now rejects
     multiple definitions of the same variable (because that would mix
     very badly with conditionals), and `+=' assignments with no
     previous definition.  Because these changes all occurred suddenly
     after 1.4 had been established for more that two years, it hurt
     users.

     To make matter worse, meanwhile Autoconf (now at version 2.52) was
     facing similar troubles, for similar reasons.

2002-03-05 Automake 1.6
     This release introduced versioned installation (*note API
     versioning::).  This was mainly pushed by Havoc Pennington, taking
     the GNOME source tree as motive: due to incompatibilities between
     the autotools it's impossible for the GNOME packages to switch to
     Autoconf 2.53 and Automake 1.5 all at once, so they are currently
     stuck with Autoconf 2.13 and Automake 1.4.

     The idea was to call this version `automake-1.6', call all its
     bug-fix versions identically, and switch to `automake-1.7' for the
     next release that adds new features or changes some rules.  This
     scheme implies maintaining a bug-fix branch in addition to the
     development trunk, which means more work from the maintainer, but
     providing regular bug-fix releases proved to be really worthwhile.

     Like 1.5, 1.6 also introduced a bunch of incompatibilities, meant
     or not.  Perhaps the more annoying was the dependence on the newly
     released Autoconf 2.53.  Autoconf seemed to have stabilized enough
     since its explosive 2.50 release, and included changes required to
     fix some bugs in Automake.  In order to upgrade to Automake 1.6,
     people now had to upgrade Autoconf too; for some packages it was
     no picnic.

     While versioned installation helped people to upgrade, it also
     unfortunately allowed people not to upgrade.  At the time of
     writing, some Linux distributions are shipping packages for
     Automake 1.4, 1.5, 1.6, 1.7, 1.8, and 1.9.  Most of these still
     install 1.4 by default.  Some distribution also call 1.4 the
     "stable" version, and present "1.9" as the development version;
     this does not really makes sense since 1.9 is way more solid than
     1.4.  All this does not help the newcomer.

 ...

2002-07-28 Automake 1.6.3
2002-07-28 Automake 1.4-p6
     Two releases on the same day.  1.6.3 is a bug-fix release.

     Tom Tromey backported the versioned installation mechanism on the
     1.4 branch, so that Automake 1.6.x and Automake 1.4-p6 could be
     installed side by side.  Another request from the GNOME folks.

2002-09-25 Automake 1.7
     This release switches to the new `configure.ac' scanner Akim was
     experimenting in 1.5.

 ...

2003-10-26 Automake on screen
     Episode 49, `Repercussions', in the third season of the `Alias' TV
     show is first aired.

     Marshall, one of the character, is working on a computer virus
     that he has to modify before it gets into the wrong hands or
     something like that.  The screenshots you see do not show any
     program code, they show a `Makefile.in' `generated by automake'...

 ...

2003-12-10 Automake 1.8
      ...

     Automake also has seen its guts rewritten.  Although this rewriting
     took a lot of efforts, it is only apparent to the users in that
     some constructions previously disallowed by the implementation now
     work nicely.  Conditionals, Locations, Variable and Rule
     definitions, Options: these items on which Automake works have
     been rewritten as separate Perl modules, and documented.

 ...

2004-07-28 Automake 1.9
     This release tries to simplify the compilation rules it outputs to
     reduce the size of the Makefile.  The complaint initially come from
     the libgcj developers.  Their `Makefile.in' generated with
     Automake 1.4 and custom build rules (1.4 did not support compiled
     Java) is 250KB.  The one generated by 1.8 was over 9MB!  1.9 gets
     it down to 1.2MB.

     Aside from this it contains mainly minor changes and bug-fixes.



See "info automake" /History for the full text (it's more interesting than
the change log).

-- 
Daniel Reed <n ml org>	http://people.redhat.com/djr/	http://naim.n.ml.org/
A democracy is a sheep and two wolves deciding on what to have for
lunch. Freedom is a well armed sheep contesting the results of the
decision. - Benjamin Franklin