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
