apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Bowsher" <m...@ukf.net>
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 09:11:44 GMT
Justin Erenkrantz wrote:
> --On Friday, July 16, 2004 12:37 AM +0100 Max Bowsher <maxb@ukf.net>
wrote:
>
>> Regarding subversion: will probably want to absorb the new find_apr.m4,
in
>> order to permit experimental building against apr-1.0.0, but are locked
into
>> apr-0 for the 1.x release cycle officially by ABI guarantees, AFAIK.
>
> FWIW, I believe that's incorrect: Subversion supports APR 1.0, too.  The
> Subversion ABI requirements don't necessarily extend to its APR exposed
> interfaces - although this has been a point of contention raised by Greg
> Hudson over on dev@svn.  So, SVN should get a new drop of find_ap{ru}.m4
and
> either not specify the version to bundle against or pass [1 0].

Oh ok. But regardless, whatever policy svn adopts, they can do it be simply
setting the acceptable-majors parameter as required.

> Yet, that's a big problem with your patch: you are now making all of the
> arguments mandatory to APR_FIND_APR - the builddir and
implicit-install-check
> are not supposed to be mandatory - APR_FIND_APR(apr) is supposed to be all
> that is required.  So, I guess I'd rather see $4 default to [1 0] instead
of
> erroring out - or only error out if we don't have the bundled source.
This
> goes back to the idea that the bundled source is 'always' correct.  -- 
justin

They aren't exactly mandatory: APR_FIND_APR(,,,[1 0]) is perfectly
acceptable.

I don't think defaulting is a good idea:

1) Because we I suggest we should install find_apr.m4 into the system
aclocal dir, for projects to obtain it through the standard aclocal
mechanism.

2) Because it seems bad to leave something as important as required major
number to default to something which may be inappropriate for the project.

3) Because it is a very very small imposition on client projects to define
something as small an unchanging as major version requirements.

4) Because there is no sensible default. [1 0] implies that a project should
work with either. Unless project maintainers decide to maintain testing of
both versions, the secondary choice may well get stale.
Defaulting to [1] will result in projects that don't even consider whether
they can work with apr-0. And [0] is clearly useless.

5) Because requiring that an argument be present ensures that upgraders will
take note of this change.

Max.


Mime
View raw message