Re: [jamboost] RFC: naming, dll versions and installing

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2004-12-13 05:19:32

Hi,

I vote for approach 2. We've been using a hacked-in solution similar to 
that one with very good results.
What I think is important is the ability to fully customize the name, 
both in terms of its form, and to
which of the files generated for a target it applies. E.g.
- Linux: libA.so.1.2.3
- Mac OS X: libA.1.2.3.dylib
- Windows: A.1.2.3.dll, A.1.2.3.pdb and A.lib
- etc.

Regards,

Pedro

Em 9 Dec 2004, às 09:30, Vladimir Prus escreveu:

>
>
> Hi,
> there's a design question that I'd like to discuss. It's related to 
> "install"
> support for Boost.
>
> Sometimes, the names of installed libraries must follow special 
> convention.
> One example is encoding library version in name (very common on Unix).
> Another is encoding build variant in name (used in Boost, some other
> libraries have single-thread and mt variants). However, on Linux, 
> change of
> library names requires relinking, you can't just copy a file.
>
> What's worse, if libA uses libB, you need to use relinked libB when 
> relinking
> libA, which means the sources of libA must be also changed.
>
> Now, there's another approach, but I can't decide which is best.
>
> Approach 1. Relinking. The naming convention is specified on the stage 
> rule
> using the <so-version> and <tag> features:
>
> lib a : a.cpp ;
> stage dist : a :
> <so-version>1.32.0 <tag>@stage.encode-variant-and-compiler ;
>
> this requires relinking
>
> Approach 2. Always using the same names:
>
> lib a : a.cpp :
> <so-version>1.32.0 <tag>@stage.encode-variant-and-compiler ;
> stage dist : a ;
>
> There are couple of use cases.
>
> Use case 1: single naming scheme. Suppose that a single naming scheme 
> is
> always used by a project.
>
> Advantages of approach 2: no relinking, so somewhat faster.
> Disadvantages of approach 2:
> - The additional properties must be specified for every library.
> - The names of libraries will be longer even when not installing,
> and we have long names already.
>
> Use case 2: several naming schemes. For example, boost has two 
> variants of
> library naming for install.
>
> Additional disadvantages of approach 2:
>
> - The obvious solution is that top-level Jamfile will compute proper
> properties and store them in variable TAG. Each lib will be 
> defined as:
>
> lib a : a.cpp : $(TAG) ;
>
> In this case, it won't be possible to install with two naming 
> conventions
> at the same time.
>
> - After building with a different naming convention, the tree will 
> contain
> several versions of each library (one for each naming convention)
>
> Can anyone comment? Do we need stage to be able to change the names of
> libraries and relink them?
>
> - Volodya
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>