Re: [jamboost] [UI] system libraries

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-11-26 23:23:26

[2002-11-26] David Abrahams wrote:

>Vladimir Prus <ghost_at_[hidden]> writes:
>
>> I has thinking about the way system libraries are
>> used. For now, there's inherited from V1 method
>>
>> exe a : a.cpp : <find-library>zlib <library-file>helper.a ;
>>
>> So, I propose to
>>
>> 1. Kick "find-library". Introduce new "system-lib" target type.
>> For example:
>>
>> system-lib zlib ;
>> exe a : a.cpp : <library>zlib ;
>
>Why "system"?
>
>
>> It's possible to specify static linking
>>
>> system-lib zlib : <shared>false ;
>
>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.

>> There will be some implementation gotchas, but they're not
>> serious. How does it look from the interface standpoint?
>
>Not sure yet. I need a more precise description of what it's supposed
>to do.

The idea is nice, but the interface is lacking.

>> 2. Kick <library-file> as well. Allow to specify file name as value
>> of <library> features.
>>
>> exe a : a.cpp : <library>zlib <library>helper.a ;
>
>library-file also allows full path specification. Are we going to do
>that, too?

...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. A rather
more flexible and cohesive solution would be to incorporate the various
instances of a library into the "lib" target. 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 ;

4. Externally available library, on a given location:

lib zlib : z : <search>/usr/local/lib ;

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.

* <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.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]