[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. Index: .cvsignore === RCS file: /home/mirror/cvsmirror/misc-cvs/apr/.cvsignore,v retrieving revision 1.24 diff -u -p -r1.24 .cvsignore --- .cvsignore 9 Jul 2004 15:51:58 - 1.24 +++ .cvsignore 15 Jul 2004 11:54:04 - @@ -6,6 +6,7 @@ config.status configure libtool apr-config +apr-*-config apr-config.out LibD LibR Index: Makefile.in === RCS file: /home/mirror/cvsmirror/misc-cvs/apr/Makefile.in,v retrieving revision 1.106 diff -u -p -r1.106 Makefile.in --- Makefile.in 1 Jul 2004 14:34:48 - 1.106 +++ Makefile.in 15 Jul 2004 11:50:27 - @@ -44,7 +44,7 @@ CLEAN_TARGETS = apr-config.out apr.exp e build/apr_rules.out DISTCLEAN_TARGETS = config.cache config.log config.status \ include/apr.h include/arch/unix/apr_private.h \ - libtool apr-config build/apr_rules.mk apr.pc + libtool $(APR_CONFIG) build/apr_rules.mk apr.pc EXTRACLEAN_TARGETS = configure aclocal.m4 include/arch/unix/apr_private.h.in \ build-outputs.mk build/ltcf-c.sh build/ltmain.sh build/libtool.m4 @@ -56,8 +56,8 @@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ # Create apr-config script suitable for the install tree -apr-config.out: apr-config - sed 's,^\(location=\).*$$,\1installed,' apr-config $@ +apr-config.out: $(APR_CONFIG) + sed 's,^\(location=\).*$$,\1installed,' $(APR_CONFIG) $@ # Create apr_rules.mk suitable for the install tree build/apr_rules.out: build/apr_rules.mk @@ -97,9 +97,8 @@ install: $(TARGET_LIB) apr-config.out bu if [ ! -d $(DESTDIR)$(bindir) ]; then \ $(top_srcdir)/build/mkdir.sh $(DESTDIR)$(bindir); \ fi; - $(LIBTOOL) --mode=install cp apr-config.out $(DESTDIR)$(bindir)/apr-config $(LIBTOOL) --mode=install cp apr-config.out $(DESTDIR)$(bindir)/$(APR_CONFIG) - chmod 755 $(DESTDIR)$(bindir)/apr-config $(DESTDIR)$(bindir)/$(APR_CONFIG) + chmod
Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
--On Friday, July 16, 2004 12:37 AM +0100 Max Bowsher [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
Justin Erenkrantz wrote:
--On Friday, July 16, 2004 12:37 AM +0100 Max Bowsher [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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.
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.
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.
--On Friday, July 16, 2004 5:02 PM +0100 Max Bowsher [EMAIL PROTECTED] 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.
Justin Erenkrantz wrote:
--On Friday, July 16, 2004 5:02 PM +0100 Max Bowsher [EMAIL PROTECTED]
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.
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 [EMAIL PROTECTED]
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.
