Ethereal-dev: [ethereal-dev] Some autoconf/automake/... changes checked in
I checked in changes that fix up some problems I found when checking out
a vanilla tree from CVS and trying "configure" and "make":
the "configure" script needs to recurse into the "wiretap"
directory - given that the CVS checkout creates "XXX" before
creating "XXX.in", makes try to redo all the "auto*" stuff, and
somewhere along the line it got upset at the lack of a
"config.status" file in the "wiretap" directory;
I added a "acinclude.m4" file that defines a
"AC_ETHEREAL_STRUCT_SA_LEN" macro (modeled after similar macros
provided with "autoconf") to check whether "struct sockaddr" has
an "sa_len" member, and defines or undefines "HAVE_SA_LEN"
appropriately, so that I could use all the "auto*" stuff without
it complaining about "AC_LBL_SOCKADDR_SA_LEN" not being defined.
The latter change was needed in order to actually make the "configure"
script using "autoconf".
The latter change also fixes the configure script to check whether
"struct sockaddr" has "sa_len" (the version that was in CVS just had the
line
AC_LBL_SOCKADDR_SA_LEN
which didn't actually do anything when run in a shell script, other than
complain about not being able to find the command
"AC_LBL_SOCKADDR_SA_LEN".
(I didn't pick up the LBL macro because it's covered by a Berkeley
copyright, which imposes a "give credit" restriction on redistribution,
and I've heard claims - nothing authoritative, unfortunately - that this
conflicts with the GPL. The macro I added was based on a macro from
"autoconf", which is covered by the GPL.
I also sent the macro to "bug-gnu-utils", for possible inclusion in a
future version of "autoconf".)
However, there's still another nuisance I ran across when testing the
configure-and-build from a freshly-checked-out CVS tree. Given that, as
I noted, "XXX" is checked out from CVS before "XXX.in", the "make" will
try to run "automake" and "autoconf" and company to build various "XXX"s
from the corresponding "XXX.in"s, and that fails because, as the files
were checked out from CVS, they're not writable.
Should files generated by "automake", "autoconf", "autoheader", and
"aclocal" be in CVS? *Not* putting them in CVS would clear up the
problem I noted, although
1) it means you have to run all the "auto*" stuff if you check
out a fresh CVS tree;
2) that means you have to have that stuff even if you aren't
tweaking any of the "*.in" or "*.am" files;
3) "automake" *might* not be clever enough to include them as
part of a tarball when you do "make dist".
