On Mon, May 30, 2005 at 08:14:09AM +0200, Tollef Fog Heen wrote: > * Eric Dorland > > [Substituting your fixed sentence in the text below] > > | I think a build-dependency on automake and autoconf is almost always > | a bad idea. It makes the build more unpredictable, which is > | generally a bad thing. You should just run automake and/or autoconf > | on the unpacked source and ship it in the .diff.gz. An extra 2K > | won't hurt. > > You can argue this for a lot of files. An example is texinfo files > which get their headers updated with information in the language of > the build locale. Or why should docs be built as part of the build > process at all? Or X fonts? > > Because we want to test for buildability. We want to make it possible > to change any part of the program and barring real errors, it should > still build. That upstream writes crap configure.in/.ac and > Makefile.ams is not an excuse, it's just a bug which should be fixed. In the case of toshutils, however, the problem is not crappy configure.in or other such files. The problem is that the latest upstream version shipped about 4 years ago. TTBOMK, GTK2 did not even exist back then. toshutils was written to compile against GTK+. Now, a simple patch that updates configure.in to look for libgtk2.0-dev followed by an autoreconf is all that is needed. Having discussed it with folks, the consensus was that I should take that approach, rather than patch and "rerelease" the upstream source. The reason for that is that I don't want to give the impression that I am taking over upstream maintenance unless that is what I really intend to do. In this case, everything is working out OK with the build requiring autoconf and automake. So, I am not going to worry about it too much. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr
Attachment:
pgprv90cEq02h.pgp
Description: PGP signature