Re: Squid-2.5

----- Original Message -----
From: "Henrik Nordstrom" <hno@squid-cache.org>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Thursday, October 04, 2001 1:23 AM
Subject: Re: Squid-2.5

> Robert Collins wrote:
>
> > I think that the sf cvs should have the automatic rebuild on - can
we
> > make sure that that does not come across?
>
> Not really, and probably not wanted. The build environments should be
> identical I think.

Granted... but we already filter the autotools created files. IMO this
setting is another user convenience. One of the notes in
the --enable-maintainer-mode is that a downside is the developers no
longer experience what the user does.

> > I also recall some discussion on the automake list to the effect
that
> > this option is worse than having the rebuild on.
>
> Any pointer that makes sense for the causal user (not developer)?

Sure. We manage to muck up a release and haven't bootstrapped it because
this switch has disabled the built-in protection against out-of-date
files and we are not yet generating the releases via 'make dist'. Every
squid user then writes us to complain that option xyz never configures -
because autoconf.h.in was out of date.

> Sure, there will (and is) issues with people patching their sources,
> leaving the build environment out of sync. But to address this we do
> have the "bootstrap.sh" script, and telling people that they must run
> "bootstrap.sh" after patching or use the --enable-maintainer-mode is
not
> a big deal, provided we can also give then a pointer to a good
automake
> release.

bootstrap.sh should not be in the distributed tarballs. It's a developer
only tool - like --enable-maintainer-mode - that is _only_ required when
downloading from a CVS without the autotool generated *.in and configure
files.

> > The summary IIRC was that the rebuild only triggers on changes to
> > makefile.am/configure.in etc, so if it triggers on a users site they
> > have done something that *needs the rebuild to happen*.
>
> Which quite likely won't be possible on their system as they don't
have
> the full toolchain installed, and if thet do they most likely don't
have
> a compatible version of automake. Also, most likely this will be
> triggered accidently by touching one of these files without actually
> changing them.

Automake is meant to handle this - the 'missing' script will print a
warning _and let make continue_ if they do not have a new enough version
of tool foo.

> The automatic rebuild WILL screw things up for users. Having it on in
> releases is not acceptable. We have attempted similar things at a
> smaller scale before (more specifically automatic reconfigure on
> changes) and it sure did screw things up for people more badly than
not
> having it.

Ah. Did you use the missing script from automake, or a custom brewed
recipe? This _can_ be tricky.

> At the time that the automake version we use is "mainstream" then this
> can be discussed again, but I don't think my mind will change. It is
not
> only about automake.

I understand - I'm happy from my user/developer perch right here - just
raising the issues as I see em. I'd hate for us to make things harder
than they have to be.

Rob
Received on Wed Oct 03 2001 - 09:31:22 MDT