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