Re: [jamboost] Shared libraries on OpenBSD...

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-01-15 10:49:52

[2003-01-15] David Abrahams wrote:

>Vladimir Prus <ghost_at_[hidden]> writes:
>
>> Rene Rivera wrote:
>>
>>> 2. Do we have anything in the design of BBV2 to handle such a platform
>>> requirement?
>>
>> I need to understand how this should be handled, first. There's a
rule/action
>> pair gcc.link-dll. I think version numbers should be handled by them?
>>
>> So, you'd have
>>
>> toolset.flags gcc VERSION_NUMBER : version-number ;
>>
>> and
>>
>> actions gcc.link-dll
>> {
>> <ordinary-stuff>
>> ln -s $(<) $(<).$(VERSION_NUMBER)
>> }
>>
>> The last line should be tweaked to expand to nothing with VERSION_NUMBER
>> is empty, but you get the idea. Then, on all platforms but OpenBSD,
>> the default value of VERSION_NUMBER will be "", and on OpenBSD it will be
>> "0.0". Will that work?

That's what BBV1 bassically does, the symlink has to be reversed, and it
barely works. I was trying to add the version support to BBV2 last month,
but the fast changing code makes it harder ;-)

My solution is to use the symlink target and change the build graph so that
it inserts the symlink target "in front" of the library target. It would
create the dependence like so:

libfoo.so (symlink-target) --> libfoo.so.0.0 (link-dll-target)

The problem is that the pair needs to be kept together, like targets that
generate multiple files.

>Just a small meta-comment: let's be sure to keep in mind that this is
>a platform requirement, not a (direct) toolset requirement, so ideally
>we'll find a way to encode this stuff in the platform. That is to
>say, (for example) the constructor for library target objects should
>automatically handle adding version numbers to the target filename.

Yes, which is another reason I'd rather have another target handle the
symlink part. So that the toolset itself doesn't have to.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq