From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-02 01:32:12
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
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 :-)
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