Proposal for a standard for D library naming

[Gregor Richards]

Anders F Björklund wrote:
> Gregor Richards wrote:
> 
>> (This section applies only to UNIX)
>>
>> The UNIX convention for naming of libraries is:
>>
>> lib<name>.so.<major>.<minor>.<revision>
>>
>> with symlinks for each of:
>>
>> lib<name>.so.<major>.<minor>
>> lib<name>.so.<major>
>>
>> and also a symlink of:
>>
>> lib<name>.so
>>
>> if the library has its headers installed. There is no compelling
>> reason to break from this standard, so it is left as such in this
>> document.
> 
> 
> Not to rain on your parade, but Darwin libraries use:
> 
> lib<name>.<major>.<minor>.<revision>.dylib
> lib<name>.<major>.<minor>.dylib ->
> lib<name>.<major>.dylib ->
> lib<name>.dylib ->
> 
> So you might want to make the "so" name flexible... ?
> 
> Using the -L and -l flags works as expected, though.
> (With GDC that is, DMD uses those flags differently)
> 
> Everything else applies.
> --anders
> 
> 
> SIDE NOTE:
> However, most Mac OS X libraries are instead packaged
> as "frameworks" which include *both* libs and includes.
> (Similar to how the Mac OS X applications are bundled up
> as "apps" which include both executables and resources)
> 

I didn't mean to imply that these extensions were the only ones 
possible, I used them because they were the ones I knew about.


> Frameworks are linked with the -framework flag, and the
> headers are automatically searched for in the system dirs.
> Don't think that the D libraries will ever be packaged as
> frameworks, so it only applies to libs like OpenGL and SDL.
 >

But it /doesn't/ apply to libraries like OpenGL and SDL, they're not 
written in D, and would still need to be manually included.


 > Why does the fact that it uses D have to be reflected in the name ?
 >

So that a unique namespace can be guaranteed - remember, these library 
names are to be not only human-understandable but machine-generatable.


 > I don't see any C++ libraries advertising that they are using that,
 > so I still need to remember to link them to libstdc++ or get errors.

This is a good thing?


 > Don't think it would be that bad to avoid prefixing them with "D.",
 > and instead get similar link errors from Phobos (and the D runtime).

But what's the advantage? The D prefix is more of a note that a D 
package name is coming than something to say "this is written in D"

eg if you wrote a library in D that exports a C interface, you may be 
inclined to name it in a more traditional way, as that library is for 
use by C (or D), so the D build tool does not necessarily need to 
generate the paths in the same way.


 >
 > So I would rather continue to name them as lib<name>.a/<name>.lib...
 >

The entire idea behind my naming proposal is that it makes everything 
100% computer and human generatable while adding very little confusion. 
  Having things named lib<name>.<extension> makes associating packages 
and libraries difficult.

Because C/++ don't have such a nice, structured package style, they 
don't have a naming convention for library files (there really couldn't 
be one), but I think that's a terrible reason to not use a naming 
convention for D.  It would building, even against libraries, 
ridiculously easy.


 > --anders

  - Gregor Richards