Proposal for a standard for D library naming

[Derek Parnell]

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. 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.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
25/09/2006 9:41:49 AM