Re: [jamboost] [UI] system libraries

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-02 01:32:12

David Abrahams wrote:

>>>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
> 
> 
> Hmm, I don't think that was really the idea. Ullrich's idea was to
> create a small Jam description file that could be "installed" by
> Boost.Build along with built products (or crafted by hand). When
> working with prebuilt targets, Boost.Build would look for a
> corresponding Jamreport file to learn about the build properties of
> the targets.

Right. And what that "small description file" would contain? IMO,
it can contain just a list of prebuilt targets. You then would use
that file just like a regular project. For example, if that file
lives in

/space/pool ;

you'd write

use-project /pool : /space/pool ;

and will access the target in 'pool' as it they were regular targets.
But actually, they are pre-created and installed target. You need
no access to sources.

I fail to understand how it's different from Ullrich's idea. Except that
we don't autogenerate such files yet --- "prebuilt" is just a mechanism
how those file might work.

>> > ...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.
> 
> 
> On linux, apparently, -lfoo will find libfoo.so or libfoo.a.

Yes. But I don't understand what follows.. Maybe, I'm just not very
smart at 9:30 :-)

- Volodya