Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
Sorry, thought I sent this last week... On Thu, Jul 01, 2004 at 06:44:45PM -0400, Greg Hudson wrote: I may not be understanding all of the constraints. Can you tell me what goes wrong with this solution? * apr-config does not get renamed in 0.9. * We introduce a new macro APR_FIND_APR1 to find apr 1.0 by looking for apr-1-config. That should work too. Having the version as an argument rather than using a new macro name was just the obvious way to avoid duplicating the macro. (BTW note that the apr-config script is only named apr-N-config by make install; it's still called apr-config in a build tree) Any reason that can't change? If it can't change, APR_FIND_APR1 can use apr-config when using a bundled apr directory. Possibly, I'm not sure. Renaming apr-config.in in CVS to apr-1-config.in would work but it would be the first time APR_MAJOR_VERSION is encoded anywhere other than in apr_version.h, which is a little ugly. (Also, since I haven't seen other people jumping up and volunteering to make this happen, where is the boundary between what you're willing to do and where I should submit a patch?) I'm not sure what you're asking here. If you submit a patch I'll commit it if it looks OK to me. Otherwise I'll do the work myself when I find time. joe
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Wed, Jun 30, 2004 at 10:39:16AM -0400, Greg Hudson wrote: On Wed, 2004-06-30 at 04:56, Joe Orton wrote: Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Greg wrote remove rather than rename, though indeed, I guess renaming should work. Renaming is also fine. Installing ap[ru]-$N-config alongside ap[ru]-config is probably all that's going to be feasible for the 1.0.0 release, at least I don't have time to deal with the fallout of removing ap[ru]-config entirely right now. The AP?_FIND_AP? macros in find_ap?.m4 need to be adjusted to take a minimum required library version argument, there's probably more... joe
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Thu, 2004-07-01 at 10:30, Joe Orton wrote: Installing ap[ru]-$N-config alongside ap[ru]-config is probably all that's going to be feasible for the 1.0.0 release, at least I don't have time to deal with the fallout of removing ap[ru]-config entirely right now. Hm. That's disappointing; it means that apr 0.9 can't be co-located on a system with apr 1.0 without hacking, and that apr-0.9-using apps will be screwed by the installation of apr 1.0.
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Thu, 2004-07-01 at 10:39, Joe Orton wrote: This is done on HEAD: patches welcome for below to expedite removal of ap[ru]-config. The AP?_FIND_AP? macros in find_ap?.m4 need to be adjusted to take a minimum required library version argument, there's probably more... Would it be okay to make it take just a library version argument, no minimum required? It means if an application wants to work against multiple major versions of APR, it has to implement its own fallback logic.
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Thu, Jul 01, 2004 at 10:45:54AM -0400, Greg Hudson wrote: On Thu, 2004-07-01 at 10:39, Joe Orton wrote: This is done on HEAD: patches welcome for below to expedite removal of ap[ru]-config. The AP?_FIND_AP? macros in find_ap?.m4 need to be adjusted to take a minimum required library version argument, there's probably more... Would it be okay to make it take just a library version argument, no minimum required? It means if an application wants to work against multiple major versions of APR, it has to implement its own fallback logic. If apr-config is not renamed in the 0.9 branch (which is really required for compatibility), then I guess yes, make the argument optional, and have logic: AP?_FIND_AP?(without extra version argument) = use apr-1-config if found else apr-config if found AP?_FIND_AP?(requires version N) = use apr-N-config if found else no fallback the app can always just call the macro again with a different N. (BTW note that the apr-config script is only named apr-N-config by make install; it's still called apr-config in a build tree) joe
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
Joe Orton wrote: If apr-config is not renamed in the 0.9 branch (which is really required for compatibility), then I guess yes, make the argument optional, and have logic: AP?_FIND_AP?(without extra version argument) = use apr-1-config if found else apr-config if found AP?_FIND_AP?(requires version N) = use apr-N-config if found else no fallback I may not be understanding all of the constraints. Can you tell me what goes wrong with this solution? * apr-config does not get renamed in 0.9. * We introduce a new macro APR_FIND_APR1 to find apr 1.0 by looking for apr-1-config. and similarly for apr-util and friends. httpd 2.1 changes to use APR_FIND_APR1 etc. instead of passing an argument to APR_FIND_APR. If an app wants to work against both versions of apr, it tries APR_FIND_APR1 and then tries APR_FIND_APR if apr_found is no. (BTW note that the apr-config script is only named apr-N-config by make install; it's still called apr-config in a build tree) Any reason that can't change? If it can't change, APR_FIND_APR1 can use apr-config when using a bundled apr directory. (Also, since I haven't seen other people jumping up and volunteering to make this happen, where is the boundary between what you're willing to do and where I should submit a patch?)
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? The entire httpd/apr-util/apr build system rests on the *-config scripts, for better or worse (usually the latter). joe
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
Joe Orton wrote: On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Max.
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Wed, Jun 30, 2004 at 09:49:48AM +0100, Max Bowsher wrote: Joe Orton wrote: On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Greg wrote remove rather than rename, though indeed, I guess renaming should work. joe
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
At 03:56 AM 6/30/2004, Joe Orton wrote: On Wed, Jun 30, 2004 at 09:49:48AM +0100, Max Bowsher wrote: Joe Orton wrote: On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Greg wrote remove rather than rename, though indeed, I guess renaming should work. Hmmm... If an app is written to support apr 2, 1 or 0, wouldn't a sanity check for the presence of apr-2-confiig / apr-1-config / apr-config solve this? Leave installed apr-config as a presumed-rev 0.9.x installed version. Now that Max mentions this - I have tripped over it once before. Bill
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Wed, 2004-06-30 at 04:56, Joe Orton wrote: Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Greg wrote remove rather than rename, though indeed, I guess renaming should work. Renaming is also fine.
apr pkgconfig use (apr.pc vs. apr-1.pc)
Imagine a library downstream from apr (say, Subversion) is trying to
follow the APR versioning guidelines
(http://apr.apache.org/versioning.html) in order to provide a stable
platform for third-party applications and libraries.
To do this, the downstream library must define the major version of
its upstream dependencies. If Subversion links against any old
version of APR it can find on the system, then the following sequence
of builds and installs breaks rapidsvn:
APR 0.9
svn 1.0
rapidsvn
APR 1.0
svn 1.1
because, although the APR soname has changed, the svn soname has not,
but it's exporting a different ABI (in relation to apr_off_t).
If that problem seems far from home, the same problem is going to
happen with {APR 0.9} {httpd 2.0.49} {plugin} {APR 1.0} {httpd
2.0.50}.
The solution to this problem is for the downstream library to rigidly
define the major version of its upstream dependencies. That's why
GNOME packages install things like libgnome-2.0.pc. (Which is
overboard; 2 would have been fine, and if you check you'll find that
the 2.0 didn't change for libgnome 2.2 or 2.4 or 2.6. But that's a
detail.) It is only this discipline which has allowed GNOME to manage
the GNOME 1 to 2 transition as gracefully as it did. (It's true that
GNOME 1 didn't use versioned library names or pkgconfig, but by
changing all the library names and adopting pkgconfig, GNOME 2
effectively created a separate universe, which is exactly the correct
thing for a major version upgrade, and is exactly the point of using
different library and pkgconfig names for a major version upgrade.)
So, please change the recently added pkgconfig support to install
apr-1.pc, so that upstream packages will run pkg-config --libs apr-1
instead of just looking for any old version of APR. By itself, that
won't help with the APR 0.9 to APR 1.x transition, but it will help
with APR 1.x to APR 2.x.
Separately, I will request that APR remove apr-config from APR 1.0 and
later in order to correctly manage the APR 0.9 - APR 1.0 transition,
but I bet that won't fly.
