Proposal for a standard for D library naming

[Gregor Richards]

Derek Parnell wrote:
> On Mon, 18 Sep 2006 21:10:46 -0700, Gregor Richards wrote:
> 
> 
>>Since there aren't many libraries for D (that is, builds that produce 
>>.so files or the ilk)
> 
> 
> In fact, are there any? I vaguely remember reading that D does not yet
> support the creation of .so files. Is that still the case?
> 
> Anyhow, let's break Gregor's proposal into two parts:
> (a) creating shared libraries (DLL in Windows, .so in Linux, ? in other
> *nix)
> (b) using shared libraries in the build process
> 
> I will defer (a) until I know how to do it :-)
> 
> With (b) I'm willing to add this feature to Build but with idea that
> failure to locate a library from a package name is not a failure to build.
> I'm not convinced that Gregor's idea that every (top-level) package must
> also be a library is a valid idea. I can imagine people still wanting to do
> static linking of object files.
> 

This last paragraph makes me think that I've miscommunicated my concept 
*urk*

1) Failure to locate an appropriately-named library is /not/ a failure, 
just a failure in that subsystem (if indeed the symbol can't be found 
anywhere, that'd be a failure).  This would probably be a 
report-but-continue type warning.
2) My creation of libraries is slightly more flexible than what you're 
suggesting, but less flexible than what you'd like I think.  Any 
/package/ can be a library (whether top-level or not), only making 
libraries of top-level packages is just a /default/.  The only reason 
for making this restriction is, to not place a reasonable restriction on 
what modules are contained in a library makes the naming exponentially 
complex or impossible.  Urk.

As per making .so files, DMD can't do it but GDC can.  For DMD to do it, 
it would need the equivalent of an -fPIC option, to produce 
position-independent code - the linking part is easy.  Of course, since 
either can create .a files, its implementable so long as DMD users are 
willing to surrender the ability to make .so files until it's capable. 
If build did this all in its automatic processing, the source maintainer 
wouldn't need to care whether the compiler being used is capable of 
producing libraries of any sort.

(Actually, DMD may be producing position independent code already for 
all I know, in which case it's perfectly capable, just need -L-shared - 
unfortunately, this is hard to test, since much software will "just 
work" even if it's not made position independent)

Furthermore, this proposal is not shared-library specific, it just shows 
its greatest benefit there (since the reliability in naming is carried 
through every conceivable stage of making/running a program).

  - Gregor Richards