On Sep 20, 2013, at 6:02 AM, Michael Richardson <m...@sandelman.ca> wrote:
> > Michal Sekletar <notificati...@github.com> wrote: >> We should really drop those generated files from SCM. I never >> understood why we track them in the first place. Committing regenerated >> versions just clutters development history. > > If you ./configure and friends, history has proven that the autoconf/automake > toolset is not stable over time or release schedule. It often has changed in > ways that aren't forward or backwards compatible, and without the *exact* > version to generate ./configure, one is screwed. > That makes regression testing and building new versions on old distros > impossible. > > (For instance, autoconf2.13 and autoconf2.5 and a newer one, could not be > substituted at all) This is definitely an argument in favor of distributing the configure script - not just the source files that generate the configure script - as part of the release tarball. It also might be considered an argument in favor of not having the generated configure script checked into the SCM system: if it's checked into SCM, it means that whoever updates configure.in or aclocal.m4 needs to regenerate the configure script on their machine and check the result in, meaning that there might be several different versions of autoconf used to generate the configure script that ends up in a release tarball; if it's *not* checked into SCM, but generated by "make releasetar", it means that only the version of autoconf on the machine used to build the official release tarballs is used to generate the configure script that ends up in a release tarball; so not checking "configure" (and "config.h.in") into SCM means that we have *more* control over the version of autoconf used to generate it. > If you are suggesting ripping out the entire autoconf infrastructure, I am > not opposed: HPUX, Interactive Unix, Xenix and AIX 3 are long dead, and so > are the weirdness they brought to the world of the 1990s. But, we still have > things like QNX and Cygwin... More importantly, we support still-alive platforms for which some versions have features that older still-supported versions don't, and support optional packages for tcpdump, and support Solaris (for which tcpdump needs to be linked with some extra libraries), and need to deal with different compilers/linkers, etc., so we still need *some* configuration infrastructure. It's perhaps unfortunate that the autotools don't eliminate support for older platforms as fast as one might like, so that autotools-generated scripts do a bunch of now-pointless tests, but I don't see that as a reason to dump autoconf. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers