September 19, 2006
Gregor Richards wrote:

> Also, I wouldn't be particularly opposed to moving the 'D' to the end, I just think that makes the suffixing a but confusing *shrugs*

I think there is a Windows standard that libraries with d suffix
means "debugging" versions, so a D prefix might actually be better.

> Remember, the entire purpose of this is for a build tool (say, build) to conform to a standard.  Only the build tool needs to figure out the flags for DMD/GDC, the person compiling should get the libraries "for free."

I haven't gotten Build to work for me, so I am still using Make.
To make things easier, I am using "gcc" to link - even for DMD.

--anders
September 19, 2006
Gregor Richards wrote:

> A Modest Proposal for Standardization in Naming of D Libraries
> --------------------------------------------------------------
> (by Gregor Richards)
[...]
> If anything is confusing here, please respond, and I will attempt to
> clarify. It's all quite clear in my head :)

Just to check I understood this, would these be standard names:

/usr/include/d/sdl/*
/usr/lib/libD.sdl.a

/usr/include/d/gl/*
/usr/lib/libD.gl.a

/usr/include/d/wx/*
/usr/lib/libD.wx.a

For the modules under "sdl." and "gl." and "wx." , respectively ?

--anders
September 19, 2006
Anders F Björklund wrote:
> Gregor Richards wrote:
> 
>> A Modest Proposal for Standardization in Naming of D Libraries
>> --------------------------------------------------------------
>> (by Gregor Richards)
> [...]
>> If anything is confusing here, please respond, and I will attempt to
>> clarify. It's all quite clear in my head :)
> 
> Just to check I understood this, would these be standard names:
> 
> /usr/include/d/sdl/*
> /usr/lib/libD.sdl.a
> 
> /usr/include/d/gl/*
> /usr/lib/libD.gl.a
> 
> /usr/include/d/wx/*
> /usr/lib/libD.wx.a
> 
> For the modules under "sdl." and "gl." and "wx." , respectively ?
> 
> --anders

That would be one means of dividing it.

Mind you, I'm not inclusive of include files, they are not in the scope of the text.

Furthermore, you could subdivide, if you wanted.  For example, if you have this:

/usr/include/d/sdl/amazingsdlplugina/*
/usr/include/d/sdl/*

You can do either one library:

libD.sdl.<extension>

Or more:

libD.sdl.<extension>
libD.sdl.amazingsdlplugina.<extension>

, so long as a module can always be found in the most specific, extant library.

 - Gregor Richards
September 19, 2006
Anders F Björklund wrote:
> Gregor Richards wrote:
> 
>> Also, I wouldn't be particularly opposed to moving the 'D' to the end, I just think that makes the suffixing a but confusing *shrugs*
> 
> I think there is a Windows standard that libraries with d suffix
> means "debugging" versions, so a D prefix might actually be better.

This is true, and I agree.

>> Remember, the entire purpose of this is for a build tool (say, build) to conform to a standard.  Only the build tool needs to figure out the flags for DMD/GDC, the person compiling should get the libraries "for free."
> 
> I haven't gotten Build to work for me, so I am still using Make.
> To make things easier, I am using "gcc" to link - even for DMD.

I didn't use Build until recently, and now I wouldn't do without it. Build makes using D similar to using Java but without the recompilation issues--ie. it "just works".  If Build could be made to work with different library designs in a clean and simple manner it would feel like cheating.


Sean
September 19, 2006
Gregor Richards wrote:

> Please respond with any opinions.

Sounds good.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
September 19, 2006
Gregor Richards wrote:
> Anders F Björklund wrote:
>> Gregor Richards wrote:
>>
>>> A Modest Proposal for Standardization in Naming of D Libraries
>>> --------------------------------------------------------------
>>> (by Gregor Richards)
>> [...]
>>> If anything is confusing here, please respond, and I will attempt to
>>> clarify. It's all quite clear in my head :)
>>
>> Just to check I understood this, would these be standard names:
>>
>> /usr/include/d/sdl/*
>> /usr/lib/libD.sdl.a
>>
>> /usr/include/d/gl/*
>> /usr/lib/libD.gl.a
>>
>> /usr/include/d/wx/*
>> /usr/lib/libD.wx.a
>>
>> For the modules under "sdl." and "gl." and "wx." , respectively ?
>>
>> --anders
> 
> That would be one means of dividing it.
> 
> Mind you, I'm not inclusive of include files, they are not in the scope of the text.
> 
> Furthermore, you could subdivide, if you wanted.  For example, if you have this:
> 
> /usr/include/d/sdl/amazingsdlplugina/*
> /usr/include/d/sdl/*

For D import files I settled on using /usr/import instead of /usr/include.  It seemed to provide a cleaner separation than sticking C/C++/D files all in the same tree.


Sean
September 19, 2006
Sean Kelly wrote:

> I didn't use Build until recently, and now I wouldn't do without it. Build makes using D similar to using Java but without the recompilation issues--ie. it "just works".  If Build could be made to work with different library designs in a clean and simple manner it would feel like cheating.

Build is like that cool power tool, that refuses to start when I try it.
Make is like that old rusty grandpa tool, that eventually does the job.

I'll switch, eventually. Meanwhile, make will do the job just fine. ;-)
--anders
September 19, 2006
Gregor Richards wrote:

> That would be one means of dividing it.
> 
> Mind you, I'm not inclusive of include files, they are not in the scope of the text.

I was just trying to make it more concrete, since those are
the libraries that I am using for SDL, OpenGL and wxWidgets.

In the RPM packages, the includes and libs travel together.

> Furthermore, you could subdivide, if you wanted. 

I really don't :-)

A minor problem is that wxD is now two libraries (wxc/wxd),
but I guess those objects could be stuffed into a libD.wx.a

--anders
September 19, 2006
Sean Kelly wrote:

> For D import files I settled on using /usr/import instead of /usr/include.  It seemed to provide a cleaner separation than sticking C/C++/D files all in the same tree.

Sure, but /usr/import is not in the Filesystem Hierarchy Standard (FHS).

And I don't really have a problem with combining C/C++/D together. But
if it is ever important, "import" can be a symlink over to "include/d".

--anders
September 21, 2006
Since there seems to be a lot of confusion as per the purpose of this library naming convention, I've added the following section:

Purpose

As there is much misunderstanding of the purpose of this library naming convention, it's outlined here:

    * The Library Naming Convention has no bearing whatsoever over the names or arrangement of source files.
    * The Library Naming Convention does not intend to replace build-style 'build everything from source with include paths' building, it intends to be a superior alternative.
    * The Library Naming Convention is a convention. That is, no one is required to conform to it, but (were it to be accepted) it would be inconveniencing not to.
    * The Library Naming Convention allows the source maintainer to choose what packages to make into libraries, with what level of division, etc. It has few rules over what is and what isn't in given libraries, as its purpose is the naming of libraries, not the content.
          o The only rule is that any module must be in the most specifically-named library corresponding to that module. That is, if you have libD.a.b.so.0 and libD.a.so.0, the module a.b.c should be in libD.a.b.so.0, not libD.a.so.0. Doing otherwise is fairly ridiculous anyway.



http://www.prowiki.org/wiki4d/wiki.cgi?LibraryNamingConvention