guinea pigs wanted!

I've got the automake changes committed to the tag squid-amake on
sourceforge. (I was hoping it'd be a 1 day thing so I hadn't documented
it on the projects page. I will document it v. soon).

I've test built with
$
../configure --enable-async-io --enable-removal-policies=lru,heap --enab
le-snmp --enable-basic-auth-helpers=ncsa --enable-ntlm-auth-helpers=fake
auth,NTLMSSP --enable-auth=basic,digest,ntlm --enable-digest-auth-helper
s=password -C && make -j9

with no problems on cygwin, and similarly on openBSD.

Now I'm looking for brave souls to try it from
(a) a developers perspective and
(b) from a users perspective.

I particularly want bug reports: files missing from make dist,
dependency problems etc. "Hey it's nice" quotes would be ok too :]

for a) you will need CVS automake (sorry.. but I'm on cgywin and as such
_need_ current bugfixes.). I'm not intending to keep on the bleeding
edge any longer than needed. I'm happy to take a snapshot of the needed
automake and plonk that on sourceforge if/when the automake changes go
in. You also need all the current squid development tools :]. Finally if
you want to try the make dist or make distcheck targets you need the
attached patch to automake which fixes a small problem with subdir
sources.

for b) you need an archive made with make dist. Henrik: is there space
on sourceforge for me to upload a tarball (~ current size of a squid
source tarball).? Only the current squid build tools are needed.
(perl/awk ...)

Anyway,
please have a look and say what you think. If you recall the reason I'm
doing this is to make libtool work down the track for loadable modules
easier.

Rob

=== Notes for interest ===
In doing the change to automake, I've tried to minimise changes to
layout/filenames etc. However while automake saves makefile maintenance
it does introduce some limits/default behaviour. The changes I've made
have been where a limit was hit, or where we can make use of the default
behaviour via a small change on our part. I'm also assuming that most
readers of this email are not familiar with automake.

Short list of changes:
* module makefiles are now empty stubs. All modules are built from their
parent directory. (object files stilll go into the sub dir). This was
due to a limitation with targets in different dirs to the makefile.
* cf_parser.c->cf_parser.h. This was due to a default we'd have had to
override. (Automake chains forward from source to primary). Also as we
never build cf_parser.o this makes more sense to me.
* mime.conf and squid.conf -> .conf.default. This lets us use automakes
default install rules to install the default files, and only test for a
missing .conf file (and we don't overwrite a present file). This also
makes more sense to me - we are generating the defaults after all.
* configure no longer searches for makefiles for the AC_OUTPUT line.
This is a limitation in automake.
* src/auth/basic/helpers/SMB/Changelog->ChangeLog. This is due to a
collision between NT's case preserving, case insensitive file system,
and inbuilt automake defaults (ie look for ChangeLog).
* Removed all Makefile.in's. This is inline with the sourceforge source
tree policy of not keeping the derived autoconf files in the repository.
I have no personal preference for or against keeping the Makefile.in's
in the repository. Without automake developers cannot edit Makefile.am's
anyway, so I guess it depends on whether the developers are expected to
change configure.in &| makefile.in's. I suspect it's simpler to remove
the Makefile.in's and get every developer to be fully equiped.
   For cvs.squid-cache.org the question is: are end users going to build
from CVS or from snapshots? (See the make dist target discussed below).
If they are building from snapshots, we can trivially automake the
regeneration of configure & the autoheader files and all the
makefile.in's.
* new file bootstrap.sh in the top directroy. This is for us developers
to use when we checkout the source tree and no configure script or
makefile.in's exist. It runs autoconf && aclocal && makefile with the
correct options in the correct order to avoid errors.
* module.a files are now libmodule.a. This is a limitation in automake.
* icons new extract into the build dir. I tried to avoid this
(rememebring the previous discussions), but one of things distcheck does
is test teh vpath build with the source set to readonly. The icon
extraction collided with that.
I may have missed some: I'll do up a more comprehensive list based on a
cvs diff when I consider the work complete :].

New features we get with this:
* somewhat more reliable automatic dependency tracking. CVS Automake
(_not_ 1.4) has a wrapper script for dependency generation that works
with non gcc compilers. If the dependency generation requires two parses
(it's not a side effect) it needs to be explicitly enabled
via --enable-dependency-tracking. (But we've got the choice now).
* make dist and make distcheck. These new targets (respectively) build a
.tar.gz containing an extract of the CVS tree and build a .tar.gz file
and test building it with the current configure options. make dist
builds a tarball that can be distributed to end users that do not have
autoconf/automake on their systems. It extracts all the sources it knows
about from the source tree, and any additional files we tell it to make.
The nice thing about make distcheck is that it can be used to
automatically test builds (say on the sourceforge compile farm :]). The
other nice thing is that portions of the source that are only useful to
developers do not need to be included (ie icp-banger.pl or test-xxx).
Oh, the tarball is named after the current squid version from configure
(squid-2.5-DEVEL.tar.gz).
* Makefile.am's are _much_ simpler than makefile.in's. I haven't used
all the feature of automake, but there's room for even more time saving
than I've put in to date (for example the boilerplate for each Makefile
at the top can be an included file.).
* Automake avoids gnu makeisms. The code it generates is (theoretically)
best-practice cross platform makefiles.
* Uninstall capability.

Some things we can do in the future(if there's interest):
* When building snapshots (via make dist) generate some of the built
source files like cf_parser.h that depend wholly on the source and not
configure options, saving end users the need for (say) sed. Also we
could pre-parse the programmers guide into man pages/html.

Todos:
* I need to move the version identifier in version.h to be the variable
from configure.in to ensure consistency.
* src/Makefile.am is still very messy (my first goal was having make
distcheck work).
* snmplib & contrib are currently missed from the make dist.
* make distcheck doesn't complete (fails during uninstall) due to a
remaining automake bug, but I though getting some early feedback would
be useful.