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
>>>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:
>> 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk