Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <002901c46b59$e2ce5190$5308a8c0@robinson.cam.ac.uk>
From: "Max Bowsher" <maxb@ukf.net>
To: <dev@apr.apache.org>
References: <040c01c46ac4$a6df1ab0$5308a8c0@robinson.cam.ac.uk>
 <1F948DCCC1D27633EA7956D4@[10.0.1.59]>
 <002501c46b14$eccafb20$5308a8c0@robinson.cam.ac.uk>
 <6.1.2.0.2.20040716081932.0574cc50@pop3.rowe-clan.net>
 <00c101c46b4e$5f1354a0$5308a8c0@robinson.cam.ac.uk>
 <4C0F32D70EDD5E88A8628161@[10.0.1.60]>
Subject: Re: [PATCH] Stop installing apr-config,
 and give clients an  APR_FIND_APR that works with apr-1-config.
Date: Fri, 16 Jul 2004 18:25:19 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Justin Erenkrantz wrote:
> --On Friday, July 16, 2004 5:02 PM +0100 Max Bowsher <maxb@ukf.net> wrote:
>
>> And since svn, apache, etc. would need to manually import the new
>> find_apr.m4 or rewrite their build system to use aclocal to get the new
>> macro, it's not worth making this a default, when doing so sacrifices the
>> guarantee that careless upgraders will be forced to notice this change.
>
> Considering aclocal is part of automake, there's zero chance of httpd or
> Subversion ever using aclocal.
>
> The point isn't about the system install path, it's about people dropping
in a
> new find_ap{ru}.m4 to projects that already have it without doing any
> modifications.  That is: what is the closest behavior to what we had
> previously - to me that's clearly a default of '[1 0]'.

I agree that [1 0] is closest, but I don't think what we have now is right!

Once 1.0 is released, projects will have a real series of official tarballs
on which they can base themselves. Unless they explicitly take action to
repeatedly test compatiblility with 0.9, it's quite possible they will break
compatibility with 0.9 without knowing it.

If this happens, the compile will fail with some kind of undefined symbol
error. It's much clearer and easier to debug (and more likely for people to
post useful info to mailing lists when asking questions) if the configure
stops when trying to find an APR.

Therefore, I don't believe the macro distributed with apr-1 should find
apr-0 unless it is explicitly asked to do so.

> I don't believe that we *must* force all APR-using projects to change
their m4
> invocation because of this.  Those that have specific version bindings can
> call APR_FIND_APR with the 'right' version (i.e. httpd 2.1+) - but most
> projects so far don't care - 0.9 and 1.0 are mostly API compatible or
projects
> build against both (like Subversion, flood, etc, etc.).  I'd expect that
might
> change in APR 2.0, so going beyond [1 0] doesn't make sense.  -- justin

If one of these projects *wants* to support apr-0, they can! But I think it
should be by explicit choice, not by a default.

Max.