Re: guinea pigs wanted!

Robert Collins wrote:

> 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.

Hmm.. would it be possible to write the automake files in such way that
they work both with the current "stable" version and the CVS version?

> 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 ...)

Sure. Plenty of space there, but my intention with using Sourceforge is
not really to have it as a distribution point. It is meant for
development and testing.

> 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.

Agreed. Having a "included fragment" as a .c file is confusing. It is
not a full c file, it is a code fragment.

> * configure no longer searches for makefiles for the AC_OUTPUT line.
> This is a limitation in automake.

Ouch.. so now we need to maintain a list of every makefile, and people
adding their own modules must have the full development tool chain.

> * Removed all Makefile.in's. This is inline with the sourceforge source
> tree policy of not keeping the derived autoconf files in the repository.

Good.

> 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.

Only original data should be CVS:ed. Derived data should only exists in
the working directory of the developer.

In this case it is even more important, as any manual changes to
"Makefile.in" files is quite likely to get lost or cause server
conflicts. If you need changes, make them in the original source.
Period.

> 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).

Both I guess. The cvs.squid-cache.org is mostly a distribution and
history repository. There it makes sense to have all files needed in a
distribution.
  a) In case problems are caused/fixed by changes in the tool chain, the
CVS repository should be able to show what changed in the resulting
files between two releases.
  b) It is expected that "power end-users" who like to stay on the
bleeding edge uses CVS to download the source. It cannot be expected
that these have the full development toolchain.

But my preference is if users builds from snapshots. This mainly to make
sure the result is properly versioned with a timestamp.

> * new file bootstrap.sh in the top directroy. This is for us
> developers to use [...]

Thanks.

> * 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 :].

Or we simply revert to not having the icons extracted from the
makefiles, and instead include this in the "bootstrap.sh" file.

> * Makefile.am's are _much_ simpler than makefile.in's.

Agreed.

> * Automake avoids gnu makeisms. The code it generates is
> (theoretically) best-practice cross platform makefiles.

Good. Starting to get tired of all the make oddities there are..

> * 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.

Pre-parsing the documentation sound like a good idea. Not sure about the
header files..

--
Henrik