Re: guinea pigs wanted!

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Tuesday, April 17, 2001 2:54 AM
Subject: 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?

Possibly. The unix side issue is with the modules and the archive
locations, one thing automake is really bad at is putting targets
outside the current directory. I tried linking/copying and so on, but it
really didn't want to play. However CVS automake has had support for
subdir sources, where the sources aren't in the current directory for
quite some time. That is how and why the modules are built in (say) fs,
with the archives in fs and the source in fs/foo.

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

Yes, but where should I give you developers a taste test of the results
of make dist (if you don't want to roll your own..)

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

See above for some info. Expanding on that, targets like
../lru.a: heap_lru.c

don't automake well. We could keep traditional Makefiles there, but
there's little point. We also get the benefit of better parallelism in
the makes.

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

Weeel, yes. Thats the outcome. The problem is that automake needs to
build a tree of makefile.ams. It can't late bind them as it has to tell
what Makefile's will come from Makefile.am->Makefile.in and what ones it
has to provide extra directory-above targets for. (I.E. It makes a make
clean in the level above a non-automake makefile have special make clean
etc targets to clean the subdir in case that particular makefile
doesn't.

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

Makefile.in's from make.am's aren't made to be easily human readible -
they can change quite a bit from minor makefile.am changes. (Not meaning
to be alarmist... but I suggest you try changing something and diffing
the results.)

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

Sure. And as I said, we can automake snapshot generation. make distcheck
will make a snapshot and test compile it.

Rob
Received on Mon Apr 16 2001 - 16:10:01 MDT