September 19, 2006 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | Gregor Richards wrote: > Please respond with any opinions. Sounds good. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi |
September 19, 2006 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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 Re: Proposal for a standard for D library naming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gregor Richards | 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 |
Copyright © 1999-2021 by the D Language Foundation