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 20:52:53 GMT
William A. Rowe, Jr. wrote:
> At 12:25 PM 7/16/2004, Max Bowsher wrote:
>> 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.
>
> WAIT!!! you got it upside down :)
>
> Folks already invoke APR_FIND_APR.  They may have merged it into
> aclocal - as autoconf suggests they do.
>
> Only 0.9.x has been released.  Ergo, only 0.9 is expected, today, when
> an application invokes APR_FIND_APR.
>
> Tomorrow (next week, what have you) an APR 1.0 will exist.  It isn't
> compatible.  New app developers will learn only APR 1.0, but they can
> add a little effort to APR_FIND_APR(,,,1) for their application.
>
> A few users, then, will check the version and support both 0, 1, but they
> will be the absolute exception - not a rule.  In fact, the only sensible
> reason I can think of not to just adopt 1.0, is that you are an apache
> or svn module author who must remain compatible with older builds.
>
> If the default remains apr-0, then nothing is broken, because nothing
> has been released on top of apr-1 yet.  But if the default changes, then
> older apps supporting only apr-0 may be broken.


The fact that we are having a huge discussion about the default seems to
support my view that we shouldn't have a default - acceptable-majors should
be a mandatory argument, as it is in my patch.

Max.


Mime
View raw message