--- Begin Message ---
On Fri, 6 Jan 2023 14:49:54 -0800
Guy Harris <ghar...@sonic.net> wrote:
> On Jan 6, 2023, at 2:24 PM, Denis Ovsienko <de...@ovsienko.info>
> wrote:
>
> > On Fri, 6 Jan 2023 13:25:14 -0800
> > Guy Harris <ghar...@sonic.net> wrote:
> >
> >> If we switch to making Debian Autoconf the new standard and keeping
> >> the generated configure script in the repository, would that mean
> >> that developers working from the repository would either have to
> >> install Debian Autoconf or use "git add -p" instead of "git add"?
> >
> > Yes. Right now it is the other way around (contributors that use
> > Debian or its derivatives have to filter their output). So perhaps
> > this switch would not be convenient for macOS and FreeBSD users.
>
> If we go that way, we should document it when addressing developers.
Yes, and it would be nice to have this documented even if we don't
(currently the contribution guidelines do not discuss this).
> Is there a place where people can download a tarball for Debian
> autoconf and just do ./configure, make, and make install, or will
> they have to download the Debian package and apply the patches? If
> the latter, we should, at minimum, give documentation on how to do
> that - or we could just do that ourselves and have a "Debian
> autoconf" source tarball to download.
It is the latter, and a custom Autoconf seems an unreasonable
requirement for contributing.
> An alternative would be *not* to keep the generated configure script
> in the repository (that's what Wireshark ended up doing before it
> ceased to use autoconf/automake), and generate it as part of the
> release-build process, which we would do on a machine on which Debian
> autoconf was installed.
Or the --runstatedir and LARGE_OFF_T bits between releases could appear
and disappear at random until it is a release time, then the standard
could be enforced as and if necessary.
> That requires that developers have autoconf installed if they're not
> going to be using CMake, but there are already tools they need
> installed (a C compiler, make, Flex, Bison/Berkeley YACC, ...) so I
> don't see that as a problem.
>
> It also means that configure.ac and aclocal.m4 would have to work
> with various sufficiently-recent versions of autoconf.
--
Denis Ovsienko
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
