Re: [jamboost] [UI] system libraries

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-28 02:17:41

Rene Rivera wrote:

>>I agree that using a single "lib" is attractive. After all, we
>>already use it for both static and dynamic libraries. But note that
>>we have separate target types: STATIC_LIB and SHARED_LIB. And since
>>system libraries are special in some sense (you'd need to add "-l") flags,
>>to library names to command line, it makes perfect sense to introduce
>>SYSTEM_LIB target type first (and system-lib rule), and make it working.
>>
>>When "lib" interface is finialized, we'll make the "lib" rule use
>>"system-lib" rule and deprecate using that rule.
> 
> 
> OK, that makes sense :-)

Then, I'll think about implementation as soon as I fix a little
bug... which requires to shake targets.jam pretty much :-)

>>>2. System available library, OS default linking:
>>>
>>> lib zlib : z : <system>true ;
>>
>>What I don't like here is that "z" is not a source for "zlib".
>>It would make UI confusing and implementation rather tricky. Can we
>>do
>>
>> lib zlib : : <system>true <name>z ;
>>
>>?
> 
> 
> Sure. After all we had previously mentioned, long time ago, that specifying
> the <name> is desired in other circumstances.

Agreed.

>>>4. Externally available library, on a given location:
>>>
>>> lib zlib : z : <search>/usr/local/lib ;
>>
>>How does this interact with "prebuilt" rule? We can change "prebuilt"
>>to work in this way
>>
>> lib fs : : <file>/a/b/c/libfs.a ;
> 
> 
> Not sure if that's enough. After all one would want to specify multiple
> locations to find the library, mapped to "-L" switch. For example:
> 
> lib fs : : <name>fs <search>/usr/local/lib <search>/opt/lib ;

I think one might want both approaches. Mapping to "-L" is fine
for libraries, but for arbitrary target type only <file>
can work.

>>The problem is that "prebuilt" is not restricted to "lib" targets.
>>Therefore, we must make "file" feature work for all target type, i.e.
>>make a special generator, which is always selected when "file" is
>>specified and does what "prebuilt" does now.
>>
>>That's nice, except for empty argument :-). The only problem is that
> 
> generator 
> 
>>selection is still underdesigned :-(. So, I don't know if we can create a 
>>generator which will be *always* selected when there's <file> property.
> 
> 
> Did you just convince yourself to not use <file> in prebuilt?

Just the opposite. The <file> requirement instead of "prebuilt" rule
is attactive and if we avoid using generators matching, it will never
be finished.

So, to summarize, we'd want:

1. <system>true to specify linking to a system library,
in which case <name> gives the name and
<version> optionally gives the version.

2. <search> to specify linking to an external library, with
"-L"/"-l" switches. <name> gives the name.

3. <file> to specify linking to a prebuilt file (of any type),
using its location.

4. The <shared> feature will determine if library is linked
statically or dynamically.

Is this settled now?

- Volodya