Proposal for a standard for D library naming

Gregor Richards Richards at codu.org
Sun Sep 24 17:14:06 PDT 2006


Derek Parnell wrote:
> On Sun, 24 Sep 2006 02:24:06 -0700, Gregor Richards wrote:
> 
> 
>>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*
> 
> 
> Oh, I wouldn't blame my failure to understand on your ability to
> communicate ;-)
> 
> 
>>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.
> 
> 
> You still seem to be saying that the *only* place that module ought to
> reside in is in libraries.

Aha!  This is a core misunderstanding.  All of this library stuff is 
supposed to come well after failing to find it in an object file - the 
order in my head is: source files, object files, specified libraries, 
automatically-discovered libraries.  That is, it should FIRST look for 
source, then objects, and only if failing in both of those should it 
look at libraries - libraries are solely for things that are NOT 
included with the source!

> Whereas I maintain that they *could* also reside
> in object files (.o/.obj) files. So if Build doesn't find a library that
> matches the import name, why can't it use the object file that maps to the
> import name - and if the object file doesn't exist then why can't I have
> Build compile the module's source to create it?  The fact that the library
> doesn't exist is not a failure then - or must there be a switch to say that
> only libraries are acceptable for this build process?
> 
> Example:
>   import a.b.c;
> 
> Looks for 
>    libD.a.b.so
>    libD.a.b.a
>    libD.a.so
>    libD.a.a
>    a.b.c.o
> 
> and places the first one it comes across onto the linker command line. If
> it finds none of these, it will compile a.b.c.d to form an object file.
> 
> And then looks for
>    a.b.c.di
>    a.b.c.d
> 
> to see if the source file is more recent than the 'object' file found
> earlier.
> 
> So a further complication is what should Build do if the module source
> files are more recent than the matching library? Currently, it recompiles
> the source files and uses the resulting object files in the linkage.
> 

The timing on source/object files has no reason to change - the only 
issue is with conflicts, and in my opinion source should /always/ trump 
libraries on conflicts.

  - Gregor Richards



More information about the Digitalmars-d mailing list