Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]

[Krzysztof Kosiński <tweenk pl gmail com>]

2010/8/5 Simon McVittie <simon mcvittie collabora co uk>:
> ... but it appears to be distribution-hostile, at least in its current state:
>
>    http://www.mail-archive.com/debian-devel lists debian org/msg281373.html
>
> Yes, autofoo also results in embedding a copy of itself in tarballs, but
> distributions who have a newer/more-bugfixed version of autofoo than the
> upstream can generally autoreconf it. Waf doesn't seem to be upgradable in a
> similar way.

My take on this is:
1. Several projects using Waf had the "binary" in their tarball to
avoid any possible incompatibilities between Waf versions
2. Debian knew better and tried to replace them with one single copy the script
3. Build breakages ensued
4. Projects and Waf upstream got angry about this
5. Maintainer used some weird threats to get the system-wide Waf
package out of Debian
6. Debian attempted a "compromise" (e.g. they still knew better) but
finally capitulated
7. Now everyone thinks that Waf maintainer is "uncooperative"

The problem appears to be conceptual: Waf upstream regards Python as
the actual build system and the Waf "binary" as a local component
similar to the configure script, while Debian thinks Waf is like the
Autoconf or Automake executables.

Waf is also "upgradable", but is not as API stable as Autotools. In
most cases you can drop a new version of the Waf "binary" into your
project directory and it will build without modification, but in some
cases it won't, so one ships the version that was verified to work. By
the way: why it's OK to bundle parts of build system code (like
libtool, m4 macros, preprocessed configure script, etc.) in the
tarball, but it's not OK to bundle the *entire* build system code?

In any case, I'm not saying that current Waf is better than current
Autotools, but that its model of execution (execute user's Python
script that defines the targets to build, use the Python interpreter
to spawn tasks) is superior to Autotools (preprocess Makefile.am,
preprocess shell script, run shell script, run "make" to spawn tasks).
I want this model, not Waf in particular.

> See this mail from Piotr Ożarowski (who packages a large proportion of the
> Python modules in Debian), which lists "use waf as build-system" alongside
> "release different tarballs with the same version number" (!) among things
> to avoid:
>
>    http://www.mail-archive.com/python-dev python org/msg47681.html

It looks out of place on this list. Comparing Waf use to version
number aliasing is dramatizing. Debian people should get over the
assumption that every "respectable" build system should work like
Autotools or CMake.

Regards, Krzysztof