apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: library versioning name
Date Thu, 19 Sep 2002 22:12:46 GMT
On Thu, Sep 19, 2002 at 02:53:37PM -0700, Wilfredo Sanchez wrote:
> On Monday, September 16, 2002, at 06:00  PM, Greg Stein wrote:
>...
> > Yup. But try and build those *today* and have them still link against
> > DB-3.3. You need the parallel install stuff.
> 
>    The problem isn't solved by making everyone use -lapr-1.  You also 
> have to (as noted in the document Ben sent us) make everyone #include 
> <apr-1/foo.h>, otherwise you are linking to a library other than the 
> one your headers correspond to.

No... you put .../apr-1/ into INCLUDES, and people #include <foo.h>

And before you speak up on the issue, let's check something out:

$ apr-config apr-config --includes
 -I/usr/local/svn/include/apr-0

Looky there! It *already* does what you requested.

> So unless you are going to do that as 
> well, I think the exercise is a waste of time, pretending to fix 
> something, but falling short in ways that could create some 
> interestingly hard to find bugs.

Preaching to the choir. Did you take a look at the implementation? :-)

>    You also have to bump the version whenever the library is no longer 
> backwards-compatible, such as adding an argument to an existing 
> function, or deleting a function.

Ahem. http://apr.apache.org/versioning.html

And from apr_version.h:

 ...
 *
 * APR version numbering follows the guidelines specified in:
 *
 *     http://apr.apache.org/versioning.html
 */


So it appears that we already have hard and fast rules on compatibility.

>    Now the drag is that if you upgrade APR, you have to go through all 
> your code and fix the #includes.  That kinda sucks.

If you use "apr-config --includes" (as you should be doing), then this does
not apply.

>    So maybe encapsulating the whole install in versioned directories is 
> a better option.

It is a possibility, but the FHS provides for distributed installations
(e.g. into /usr or /usr/local) along with installations into /opt. I'm not
sure what it recommends for libraries (e.g. is /opt just for apps?)


Fred: how about if you take a look at the existing stuff, and see whether
that works for you :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message