Re: [jamboost] [UI] system libraries

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-27 03:13:16

David Abrahams wrote:

>> Moreover, consider that on Windows, a library
>> called 'expat' must be built by Boost.Build, so we
>> have to write
>>
>> exe main : main.cpp : <library>expat
>>
>> But on Linux this library is already awailable, so we better
>> use
>>
>> exe main : main.cpp : <find-library>expat
>>
>> This difference is messy.
> 
> 
> Yup.
> 
> I think it's time to look at
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Configuration_And_Installation
> again.

I had that in mind all the time. Moreover, I've recently implemented and just 
documented "prebuilt" targets, which do almost what is proposed in the page 
you mention. At least I think so, check out:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/tools/build/boost_build_v2.html?rev=HEAD&content-type=text/html#prebuilt_targets

>>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"?

Because it's a library that's supposed to be installed system-wide. In
this case, on Linux, zlib is supposedly located in /usr/lib. And it's
refered by "-lzlib" in the command line, not by absolute name.

I also considered "standard" but it's more ambiguious.

The libraries built by different tools, but which are not in
a system locations, i.e. those which are not referred by "-l" option,
but by full name, case be specified using prebuilt target.

prebuilt LIB foo : /home/ghost/lib/foo.a
: <shared>false ;

prebuilt LIB foo : /home/ghost/foo.so
: <shared>true ;

exe a : a.cpp foo ;

Rene Rivera wrote:

>>> 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?

Yes.

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

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.

> 1. Locally built library:
>
> lib test : test.cpp ;
>
> 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 ;

?

> 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 ;

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.

>
> 5. System library, a specific version:
>
> lib zlib : z : <system>true <version>1

Oh... version is very good!

> 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 ;

Wow, I like this very much! Target alternatives find more uses.

- Volodya