Re: [libpcap] fix typo on manpage install (#320)

[Guy Harris <guy () alum mit edu>]

On Sep 20, 2013, at 6:02 AM, Michael Richardson <mcr () sandelman ca> wrote:

> Michal Sekletar <notifications () 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