Re: [jamboost] [Q] bbv2 -- How to control naming of, and symbolically linking to, the boost libraries?

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2004-12-03 10:34:59

Hi again,

>> this is something we've been doing here for a long time using some 
>> "hacks"
>> into Boost.Build.
>> I've been planning to send some patches but haven't yet had time to do 
>> it.
>>
>> I've just checked out the head of the CVS and tried it out. I've got a
>> couple of doubts, though:
>>
>> - Since only the staged target gets a different name, what if I include 
>> the
>> base target in the sources? Using the above example:
>>
>> lib foo : foo.cpp my_list ;
>>
>> foo.so will depend upon libmy_list.so and not libmy_list.so.1.32.0. Or 
>> did
>> I get it wrong?
>
> This is important question, that I, frankly, has missed. Indeed, foo.so 
> will
> depend on 'libmy_list.so', which is not what's intended. I see two 
> solutions:
>
> - since we relink when staging (now), it's probably possible to change the
> sources to the staged version of library -- libmy_list.so.1.32.0.
> - it's possible to apply this logic at each individual target. This will
> eliminate the need to relink libraries when staging, but I wonder if there
> any negative side effects?
>
>> - In addition to this, I think versioning is horizontal to all platforms.
>> E.g., for Windows what we do here is to change the DLL name but keep the
>> import lib name:
>>
>> MyDLL.dll --> MyDLL.1.32.0.dll
>> MyDLL.lib --> MyDLL.lib
>
> This is another important question. Current Boost install adds the version
> number to name and on Linux, *also* to suffix. The above scheme (add to 
> name
> on Windows, to suffix on Unix), is more reasonable, in my opinion, but I
> don't know yet why Boost install works this way.
>
> Why you don't change the name of import lib, BTW? Is import lib never
> distributed installed?

It is but I don't want my customers to have to change their VC projects or 
Makefiles:
they receive a new version of the software but continue to use the old 
names.

>> In order to do this, I changed generators.generated-targets so that, if a
>> <version-number> property exists:
>> - for gcc, the version number is appended to the name of SHARED_LIB
>> targets. - for msvc, the version number is inserted between the name and
>> the postfix of SHARED_LIB targets.
>> - IMPORT_LIB targets are kept unchanged.
>
> I see, this is a valid option -- though if we go this way I'd need to do
> something more clean than changing generators.generated-targets.

Agreed. That's one of the reasons I've never posted the patches: it's too 
low level a place to add this logic.
On the other hand, versioning is too important a feature not to add it.

Regards,

Pedro