Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 12:25 PM 7/16/2004, Max Bowsher wrote:
>Justin Erenkrantz wrote:
>> --On Friday, July 16, 2004 5:02 PM +0100 Max Bowsher <ma...@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.

Bill

Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.

[Max Bowsher <ma...@ukf.net>]

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