You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Max Bowsher <ma...@ukf.net> on 2004/07/16 01:37:08 UTC
[PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
Log message:
[[[
Make the config script be named apr-MAJOR-config, even in the build
directory.
* .cvsignore: Add apr-*-config.
* Makefile.in: Throughout, change apr-config to $(APR_CONFIG).
Do not install the config script as apr-config as well as $(APR_CONFIG).
* apr-config.in: Add @APR_MAJOR_VERSION@ where appropriate so the help
output
reflects reality.
* configure.in: Generate apr-MAJOR-config from apr-config.in .
Enhance the APR_FIND_APR macro, to correctly handle multiple major API
versions.
* build/find_apr.m4 (APR_FIND_APR): Introduce an additional argument
specifying
desired major versions. Correct text not accounting for the full range
of
possible types of arguments to --with-apr.
]]]
I see from the mail on the dev list that I need to explain my rationale for
some of what I've done above.
Summary aim: Allow apr-0 and apr-1 to be installed and used side-by-side in
the same prefix.
Stopping installing apr-config alongside apr-1-config permits side-by-side
installs.
The APR_FIND_APR macro is updated to take a new mandatory argument listing
acceptable apr major versions.
Any library which uses apr and exposes apr types in it's own ABI *must*
limit itself to one major version of apr, if it is to maintain any ABI
guarantees itself. Therefore, the ability to require just 1 version of apr
is required.
Any app coded to the intersection of the apr-0 and apr-1 APIs may be able to
work with either, so the macro allows for multiple apr versions to be deemed
acceptable.
Note: I also make the apr-config be named apr-MAJOR-config in the *build*
directory, as well as in the install. This means that when a bundled apr is
used, the patch uses sed to probe the major, so it knows the name of the
apr-MAJOR-config that will be created.
This change is important! Apr currently
supports --with-apr=path/to/built/but/not/installed/apr. We cannot continue
to do this without the above change, as we must *not* accept a bare
apr-config file as valid unless apr-0 is deemed acceptable by the macro
invoker. Therefore the apr-config in a build directory must include the
major version, so that APR_FIND_APR can know it is acceptable to use.
OK, so here it is, the patch, complete AFAIK.
Comments welcomed.
As soon as this is approved, I will produce the equivalent patch for
apr-util.
Regarding httpd-HEAD: the only change they need to make is to call
APR_FIND_APR with a new 4th argument of "1".
Regarding httpd-2.0.x: will remain using apr-0.9.x, will never see any of
these changes.
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.
Subversion can absorb the new find_apr.m4, and just needs to add a 4th
argument of "0" to the APR_FIND_APR invocation. Apr-1 builds can be forced
despite this with --with-apr=/path/to/apr-1-config when desired.
Max.
Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
Posted by 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.
Re: [PATCH] Stop installing apr-config, and give clients an
APR_FIND_APR that works with apr-1-config.
Posted by "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.
Posted by Max Bowsher <ma...@ukf.net>.
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.
> 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.
Re: [PATCH] Stop installing apr-config, and give clients an
APR_FIND_APR that works with apr-1-config.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--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 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
Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
Posted by Max Bowsher <ma...@ukf.net>.
William A. Rowe, Jr. wrote:
> At 04:11 AM 7/16/2004, Max Bowsher wrote:
>> 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.
>
> No, [0] as default means the app was built for an older APR_FIND_APR,
> e.g. 0.9 - and every modern user can choose between [1] and [0 1]
> depending on the amount of compatibility effort.
>
> Anyone trusting that a shared apr_find.m4 installed in aclocal.m4 does the
> 'right thing' needs the reassurance that svn, apache etc will pick apr 0.
True.
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.
Max.
Re: [PATCH] Stop installing apr-config, and give clients an
APR_FIND_APR that works with apr-1-config.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:11 AM 7/16/2004, Max Bowsher wrote:
>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.
No, [0] as default means the app was built for an older APR_FIND_APR,
e.g. 0.9 - and every modern user can choose between [1] and [0 1]
depending on the amount of compatibility effort.
Anyone trusting that a shared apr_find.m4 installed in aclocal.m4 does the
'right thing' needs the reassurance that svn, apache etc will pick apr 0.
Bill
Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> --On Friday, July 16, 2004 12:37 AM +0100 Max Bowsher <ma...@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.
Re: [PATCH] Stop installing apr-config, and give clients an
APR_FIND_APR that works with apr-1-config.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, July 16, 2004 12:37 AM +0100 Max Bowsher <ma...@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].
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
Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
Posted by Noah Misch <no...@cs.caltech.edu>.
On Mon, Jul 19, 2004 at 11:57:50AM +0100, Max Bowsher wrote:
> >> + if test -z "$4"; then
> >> + AC_MSG_ERROR([the APR_FI@&t@ND_APR macro requires an
> acceptable-majors
> >> parameter]) + fi
> >
> > You could have used an m4 conditional and ``errprint'' to raise this error
> at
> > autoconf-time.
>
> I'll read up on that, and produce a new version of the patch, but this
> probably doesn't need to hold up 1.0
Agreed. It may not even be a good idea, but I figured I would throw it out.
> > What is that @&t@ business?
>
> It expands to nothing. Without it there, APR_FIND_APR contains the string
> APR_FIND_APR, and m4 recurses infinitely.
Would this be clearer?: [the APR_F][IND_APR macro ...]
> >> + case $apr_bundled_major in
> >> + "")
> >> + AC_MSG_ERROR([failed to find major version of bundled APR])
> >> + ;;
> >> + 0)
> >> + apr_temp_apr_config_file="apr-config"
> >> + ;;
> >> + *)
> >> + apr_temp_apr_config_file="apr-$apr_bundled_major-config"
> >> + ;;
> >> + esac
> >
> > Would this make more sense as follows?
> >
> > case $apr_bundled_major in
> > 0)
> > apr_temp_apr_config_file="apr-config"
> > ;;
> > [[:digit:]])
> > apr_temp_apr_config_file="apr-$apr_bundled_major-config"
> > ;;
> > *)
> > AC_MSG_ERROR([failed to find major version of bundled APR])
> > ;;
> > esac
>
> Is [[:digit:]] portable?
POSIX requires it. It works (with /bin/sh) on HP/UX and Tru64. It does not
work on FreeBSD or NetBSD. One must use /usr/xpg4/bin/sh and not /bin/sh on
Solaris 2.8. It works on bash.
Okay, I would not use it, and I will add this information to the Autoconf
manual's shell portability notes.
> This will work until apr 10.0 is released :-)
[[:digit:]])
[[:digit:]][[:digit:]])
[[:digit:]][[:digit:]][[:digit:]])
apr_temp_apr_config_file="apr-$apr_bundled_major-config"
;;
... should suffice for a few millenia of Apache.
> Perhaps I should use expr instead of shell globbing?
Maybe, but I think your solution is fine. Sorry for the noise.
Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
Posted by Max Bowsher <ma...@ukf.net>.
Noah Misch wrote:
> On Fri, Jul 16, 2004 at 12:37:08AM +0100, Max Bowsher wrote:
>
> Thanks for taking care of this. For my part, I think your patch is
> appropriate for the next RC and in turn for 1.0. It establishes an
Autoconf
> API that should serve APR well. I have included a few technical
suggestions.
>
> (Regarding whether to make the arguments to APR_FIND_APR mandatory, I
don't
> have a solid opinion.)
>
>> + if test -z "$4"; then
>> + AC_MSG_ERROR([the APR_FI@&t@ND_APR macro requires an
acceptable-majors
>> parameter]) + fi
>
> You could have used an m4 conditional and ``errprint'' to raise this error
at
> autoconf-time.
I'll read up on that, and produce a new version of the patch, but this
probably doesn't need to hold up 1.0
> What is that @&t@ business?
It expands to nothing. Without it there, APR_FIND_APR contains the string
APR_FIND_APR, and m4 recurses infinitely.
>> + case $apr_bundled_major in
>> + "")
>> + AC_MSG_ERROR([failed to find major version of bundled APR])
>> + ;;
>> + 0)
>> + apr_temp_apr_config_file="apr-config"
>> + ;;
>> + *)
>> + apr_temp_apr_config_file="apr-$apr_bundled_major-config"
>> + ;;
>> + esac
>
> Would this make more sense as follows?
>
> case $apr_bundled_major in
> 0)
> apr_temp_apr_config_file="apr-config"
> ;;
> [[:digit:]])
> apr_temp_apr_config_file="apr-$apr_bundled_major-config"
> ;;
> *)
> AC_MSG_ERROR([failed to find major version of bundled APR])
> ;;
> esac
Is [[:digit:]] portable?
This will work until apr 10.0 is released :-)
Perhaps I should use expr instead of shell globbing?
Max.
Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
Posted by Noah Misch <no...@cs.caltech.edu>.
On Fri, Jul 16, 2004 at 12:37:08AM +0100, Max Bowsher wrote:
Thanks for taking care of this. For my part, I think your patch is appropriate
for the next RC and in turn for 1.0. It establishes an Autoconf API that should
serve APR well. I have included a few technical suggestions.
(Regarding whether to make the arguments to APR_FIND_APR mandatory, I don't have
a solid opinion.)
> + if test -z "$4"; then
> + AC_MSG_ERROR([the APR_FI@&t@ND_APR macro requires an acceptable-majors parameter])
> + fi
You could have used an m4 conditional and ``errprint'' to raise this error at
autoconf-time.
What is that @&t@ business?
> + case $apr_bundled_major in
> + "")
> + AC_MSG_ERROR([failed to find major version of bundled APR])
> + ;;
> + 0)
> + apr_temp_apr_config_file="apr-config"
> + ;;
> + *)
> + apr_temp_apr_config_file="apr-$apr_bundled_major-config"
> + ;;
> + esac
Would this make more sense as follows?
case $apr_bundled_major in
0)
apr_temp_apr_config_file="apr-config"
;;
[[:digit:]])
apr_temp_apr_config_file="apr-$apr_bundled_major-config"
;;
*)
AC_MSG_ERROR([failed to find major version of bundled APR])
;;
esac
Again, thanks.