Boost logo

Boost :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2003-10-27 11:44:06


[2003-10-27] Rozental, Gennadiy wrote:

>>>> 2. lib prefix
>>>> What is a rationale for lib prefix for static libraries? First of all
>>>> of looks excessive since suffix is lib anyway. Second - dll is also
>>>> library and finally why not use suffix schema similar to other
>>>> options
>>>
>>> Good question, it's just the way in which bjam has always done it, so
>>> that's the format used in the header as well.
>
>>Not sure if this answers it...
>
>>Some simple reasons to have a lib prefix on libraries:
>
>> * It's the standard on *nix, so it's less confusin to make it that
>> way on all platforms.
>
>Note that on unix both static and dynamic libraries are named started with
>lib and difference is in suffex. Would you be willinf to introduce prefix
>based swithc I rather start shared libs with lib, while static libs are
>archives. No prefix for dlls seems like an arbitrary decision and may
>confuse users.

I would be willing to live with whatever the Boost community wants :-)

But, adding a switch seems uneeded, and will just introduce more variation
to the build which is what we are trying to avoid. What's needed is
consistent naming.

>> * It's needed in Windows because if those files are going to live
>> with a DLL build they need to have a different name in order to not
>> collide with the DLL import library file.
>
>You could always use suffix based separation.
>In my personal taste I do not like names like libaaa.lib.

We could. Specific suggestions are welcome ;-)

And for those that don't know here's what's currently generated:

On Unix...

    lib<lib-name><variant-tag>.so[.<version-tag>]
    lib<lib-name><variant-tag>.so (symlink)
    lib<lib-name><variant-tag>.a

On Windows...

    <lib-name><variant-tag>.dll
    <lib-name><variant-tag>.lib
    lib<lib-name><variant-tag>.a

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk