Re: [jamboost] [UI] system libraries

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-02 08:24:15

Vladimir Prus <ghost_at_[hidden]> writes:

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

I don't see any place for a description of the build properties that
have been used to generate these prebuilts to appear. That was central
to what Ullrich was talking about.

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

Nothing neccessarily follows. It's merely an observation, since you
were discussing STATIC and SHARED in the same breath.

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