Alan Conway <[EMAIL PROTECTED]> wrote: > On Mon, 2006-12-04 at 15:33 +0000, Steven Shaw wrote: >> On 04/12/06, Jim Meyering <[EMAIL PROTECTED]> wrote: >> > I think you said Debian. If so, you can safely use apt preferences >> > (see man apt_preferences) to get automake, autoconf, and libtool from >> > "unstable", which btw, doesn't deserve that name any more. >> >> Does that mean that it will work now with autoconf >2.59 ? > > It was originally working with 2.60, I downgraded to 2.59 because that's > the latest on fedora 6. I've no objection to downgrading further, e.g. > for RHEL 4. I don't know why you would be having trouble with a higher > version though. > >> Perhaps you could post the ./configure script. That's all I need. Or >> perhaps commit it to svn under a sneaky name like "configure.sneaky". > > What do you think Jim? My instinct is to never commit generated files,
That's my preference, too. There are problems no matter which approach you take. In the four months since I switched GNU coreutils development to the ./bootstrap-style approach, I get the impression that it makes the development code base more accessible to potential participants. Before, derived files like configure, aclocal.m4, and Makefile.in were all version-controlled, but it was too easy to change configure.ac or a Makefile.am file and then forget to regenerate-and-commit the associated generated files. That would render a checked-out-copy unbuildable by average users. In addition, there would sometimes be conflicts in those generated files due to developers using differing versions of tools like automake and autoconf. > but if this is likely to get in the way of contributors then perhaps we > should consider it. I've found that it's better to try to educate developers than to try to accommodate inadequate build environments. Maybe we need more detailed instructions on how to set up a proper build environment from scratch? Or a FAQ, on things that can go wrong? Also, for *developers*, there is little point in providing too much backwards compatibility wrt tools like automake and autoconf. There is no harm in requiring that they upgrade to the latest tools. And there *is* harm in our spending time (and more importantly making the infrastructure less modern) to backport developer-only infrastructure. Jim
