Bob Friesenhahn <bfrie...@simple.dallas.tx.us> writes: > On Thu, 29 Apr 2010, Russ Allbery wrote:
>> I think this just varies based on what your developers are like and how >> closed your project is, basically. People often say that they find it >> fairly easy to make all developers on a project use identical versions >> of the autotools. I find that sort of mind-boggling, since it would be >> absolutely impossible for the projects that I work on. People >> contribute to my projects using everything from NetBSD to Solaris, >> versions of Linux from RHEL 4 to Debian unstable, and all sorts of >> random locally-installed versions of stuff. I usually don't even have >> exactly the same versions of Autoconf and Automake on all the different >> systems that *I* use to do development. > I find that it typically takes less than ten minutes to install current > released FSF autotools on a system. It is unfortunate that your project > contributors are so challenged. They frequently have the same policy that I have personally, which is that I will not install anything that isn't packaged natively for the OS that I'm using. If it's important enough for me to override the current distribution version, I'll package it myself, but normally it's neither necessary nor really useful. I'd rather test that my build system works with a variety of versions or has the correct minimum version bounds configured. > What I do find challenging are projects which provide autotools source > files which don't work with current released FSF autotools, use custom > m4 macros which are not included in the source tree, or indicate which > versions might actually work. Yeah, that's another advantage of that policy of not installing anything that isn't packaged for the local OS. It helps avoid some of those problems, and it's really useful for ensuring that your software really does build and can be developed in a variety of environments. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
