Re: [jamboost] [UI] system libraries

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-27 00:56:14

Rene Rivera <grafik666_at_[hidden]> writes:

> [2002-11-26] David Abrahams wrote:
>
>>Hmm. Isn't it true that you can link statically or dynamically to the
>>same .so on unix?
>
> Not AFAIK. You can link to a static(*.a) or dynamic(*.so) version. And
> additionally to specific numbered versions.

Oh, OK. I thought I just learned this. I could've sworn this was what
Markus was talking about with find-library-static. But I guess that
just finds libxxx.a or libxxx.so... so I guess I'll un-learn it now
;-)

> ...I think the idea of reducing the number of ways to specify a library is
> good. But I think the "system-lib" UI is not enough of a reduction. 

Agreed.

> A rather more flexible and cohesive solution would be to incorporate
> the various instances of a library into the "lib" target. 

Yes, I had the same thought.

> Here are the various ones I can think of, and how they might be
> declared:
>
> 1. Locally built library:
>
> lib test : test.cpp ;
>
> 2. System available library, OS default linking:
>
> lib zlib : z : <system>true ;
>
> 3. System available library, static linking:
>
> lib zlib : z : <system>true <shared>false ;

What about a library available in both static and dynamic forms?

> 4. Externally available library, on a given location:
>
> lib zlib : z : <search>/usr/local/lib ;

Why not just:

lib zlib : /usr/local/lib/z ;

in that case?

> 5. System library, a specific version:
>
> lib zlib : z : <system>true <version>1
>
> And you can extrapolate all the various combinations from that. But
> the relevant features are:
>
> * <system> : true = Search standard locations and names, uses
> the source as the base name (above "z" would look for libz.so,
> libz.a, etc), false = The default, external or internal library.

false needs more explanation

> * <search> : Present = Search for non-standard locations but
> standard names using the source as the base name. One could specify
> more than one, and different ones depending on the toolset and/or
> platform.
>
> * <version> : For internal libraries this does the soname procedures.
> For external libraries, links to the specific version of the library (above
> it would mean linking to "libz.so.1").
>
> With this approach it would be possible to support the possibility of having
> a library which can be both internally built or externally linked. The
> previously mentioned example was expat, which is normally included in the
> system in Linux, but not in Windows. For example:
>
> lib expat : expat : <system>true ;
> lib expat : source1.c source2.c ;
> exe test : main.cpp <library>expat/<system>true : <os>LINUX ;
> exe test : main.cpp <library>expat : <os>NT ;
>
> Of course that brings up the idea of having a feature to identify/select the
> OS/PLATFORM.

Yup. And we'll eventually need to deal with both host and target ;-/

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution