www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Q: DSSS: Library name being prefixed with S

reply Myron Alexander <someone somewhere.com> writes:
Hello.

I have just started using DSSS referencing their cookbook and I have a 
problem generating my library.

dsss.conf

 name = dbapi
 
 [dbapi]
 target     = dbapi
 buildflags = -unittest -debug -g
console output:
 Creating imports for dbapi
 
 dbapi => dbapi
 + C:\opt\dsss\dsss-0.65-dmd-win\bin\rebuild.exe -Idsss_imports\ -I. -S.\ 
    -IC:\opt\dsss\dsss-0.65-dmd-win\include\d
-SC:\opt\dsss\dsss-0.65-dmd-win\lib\
    -IC:\opt\dsss\dsss-0.65-dmd-win\include\d
-SC:\opt\dsss\dsss-0.65-dmd-win\lib
    -oqdsss_objs -unittest -debug -g  -explicit -lib -full dbapi\base.d 
    dbapi\c\sqlite3.d dbapi\helper.d dbapi\sqlite3.d -ofSdbapi.lib
 Digital Mars Librarian Version 8.02n
 Copyright (C) Digital Mars 2000-2007 All Rights Reserved
 http://www.digitalmars.com/ctg/lib.html
 Digital Mars Librarian complete.  
 Sdbapi.lib        
 
The problem is that the final library file is called "Sdbapi.lib" instead of "dbapi.lib". I'm using version 0.65. Is there something I am doing wrong? or is there a known bug? Can anyone help me? Thanks ahead, Myron. dprogramming...myron...alexander...com replace the first ... with , remove the second, and replace the third with ".".
Jun 12 2007
parent reply Myron Alexander <someone somewhere.com> writes:
Myron Alexander wrote:
 Hello.
 
 I have just started using DSSS referencing their cookbook and I have a 
 problem generating my library.
 
 dsss.conf
 
 name = dbapi

 [dbapi]
 target     = dbapi
 buildflags = -unittest -debug -g
console output:
 Creating imports for dbapi

 dbapi => dbapi
 + C:\opt\dsss\dsss-0.65-dmd-win\bin\rebuild.exe -Idsss_imports\ -I. 
 -S.\    -IC:\opt\dsss\dsss-0.65-dmd-win\include\d 
 -SC:\opt\dsss\dsss-0.65-dmd-win\lib\
    -IC:\opt\dsss\dsss-0.65-dmd-win\include\d 
 -SC:\opt\dsss\dsss-0.65-dmd-win\lib
    -oqdsss_objs -unittest -debug -g  -explicit -lib -full dbapi\base.d 
    dbapi\c\sqlite3.d dbapi\helper.d dbapi\sqlite3.d -ofSdbapi.lib
 Digital Mars Librarian Version 8.02n
 Copyright (C) Digital Mars 2000-2007 All Rights Reserved
 http://www.digitalmars.com/ctg/lib.html
 Digital Mars Librarian complete.  Sdbapi.lib       
The problem is that the final library file is called "Sdbapi.lib" instead of "dbapi.lib". I'm using version 0.65. Is there something I am doing wrong? or is there a known bug? Can anyone help me? Thanks ahead, Myron. dprogramming...myron...alexander...com replace the first ... with , remove the second, and replace the third with ".".
Ok, I went through DSSS sources and found that the prefixed "S" is hardcoded. It looks intentional. The question is: What problem is the "S" prefix trying to solve? I want to use DSSS but I also want control over the name of my library files. Regards, Myron.
Jun 12 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Myron Alexander wrote:
 Myron Alexander wrote:
 
 Hello.

 I have just started using DSSS referencing their cookbook and I have a 
 problem generating my library.

 dsss.conf

 name = dbapi

 [dbapi]
 target     = dbapi
 buildflags = -unittest -debug -g
console output:
 Creating imports for dbapi

 dbapi => dbapi
 + C:\opt\dsss\dsss-0.65-dmd-win\bin\rebuild.exe -Idsss_imports\ -I. 
 -S.\    -IC:\opt\dsss\dsss-0.65-dmd-win\include\d 
 -SC:\opt\dsss\dsss-0.65-dmd-win\lib\
    -IC:\opt\dsss\dsss-0.65-dmd-win\include\d 
 -SC:\opt\dsss\dsss-0.65-dmd-win\lib
    -oqdsss_objs -unittest -debug -g  -explicit -lib -full 
 dbapi\base.d    dbapi\c\sqlite3.d dbapi\helper.d dbapi\sqlite3.d 
 -ofSdbapi.lib
 Digital Mars Librarian Version 8.02n
 Copyright (C) Digital Mars 2000-2007 All Rights Reserved
 http://www.digitalmars.com/ctg/lib.html
 Digital Mars Librarian complete.  Sdbapi.lib       
The problem is that the final library file is called "Sdbapi.lib" instead of "dbapi.lib". I'm using version 0.65. Is there something I am doing wrong? or is there a known bug? Can anyone help me? Thanks ahead, Myron. dprogramming...myron...alexander...com replace the first ... with , remove the second, and replace the third with ".".
Ok, I went through DSSS sources and found that the prefixed "S" is hardcoded. It looks intentional. The question is: What problem is the "S" prefix trying to solve? I want to use DSSS but I also want control over the name of my library files. Regards, Myron.
Gregor might be able to answer this more completely, but it is so that you can have multiple different versions of the library installed side-by-side in DSSS. That's not the only prefix. I believe there are others for whether it was compiled with DMD or GDC; whether it's a static library or a dynamic one; and maybe whether it uses Phobos vs. Tango. (I don't recall what 'S' on its own means.) The idea is that, if you're compiling with DSSS, you'll also be compiling anything using your library with DSSS. DSSS knows what all those prefixes mean, and it should Just Work. If you want more complete control over the compilation process, you can try using Rebuild directly (althogh then you lose the extra power of DSSS.) -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jun 12 2007
parent reply Myron Alexander <someone somewhere.com> writes:
Kirk McDonald wrote:
 
 Gregor might be able to answer this more completely, but it is so that 
 you can have multiple different versions of the library installed 
 side-by-side in DSSS. That's not the only prefix. I believe there are 
 others for whether it was compiled with DMD or GDC; whether it's a 
 static library or a dynamic one; and maybe whether it uses Phobos vs. 
 Tango. (I don't recall what 'S' on its own means.)
 
 The idea is that, if you're compiling with DSSS, you'll also be 
 compiling anything using your library with DSSS. DSSS knows what all 
 those prefixes mean, and it should Just Work. If you want more complete 
 control over the compilation process, you can try using Rebuild directly 
 (althogh then you lose the extra power of DSSS.)
 
It makes sense in that context but it is not what I want. I tried rebuild but it kept on complaining about not having a module declaration in my main file so I have gone back to Bud for now. Until D gets a better library mechanism, I will be using source libraries. My library is open-source anyway so it does not affect me, yet.
Jun 12 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Myron Alexander wrote:
 Kirk McDonald wrote:
 Gregor might be able to answer this more completely, but it is so that 
 you can have multiple different versions of the library installed 
 side-by-side in DSSS. That's not the only prefix. I believe there are 
 others for whether it was compiled with DMD or GDC; whether it's a 
 static library or a dynamic one; and maybe whether it uses Phobos vs. 
 Tango. (I don't recall what 'S' on its own means.)

 The idea is that, if you're compiling with DSSS, you'll also be 
 compiling anything using your library with DSSS. DSSS knows what all 
 those prefixes mean, and it should Just Work. If you want more 
 complete control over the compilation process, you can try using 
 Rebuild directly (althogh then you lose the extra power of DSSS.)
It makes sense in that context but it is not what I want. I tried rebuild but it kept on complaining about not having a module declaration in my main file so I have gone back to Bud for now.
That's just a warning, and you can usually just ignore it. Getting rid of it is easy: If your main file is called "main.d", just add "module main;" to the top of it. It is related to how rebuild handles fully-qualified object files, and is only an issue if you somehow have another file called "main.d" which doesn't have a module declaration in your project. Always including a module declaration is good practice, so you should include one as a matter of course.
 Until D gets a better library mechanism, I will be using source 
 libraries. My library is open-source anyway so it does not affect me, yet.
-- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jun 12 2007
parent reply Myron Alexander <someone somewhere.com> writes:
Kirk McDonald wrote:
 That's just a warning, and you can usually just ignore it. Getting rid 
 of it is easy: If your main file is called "main.d", just add "module 
 main;" to the top of it. It is related to how rebuild handles 
 fully-qualified object files, and is only an issue if you somehow have 
 another file called "main.d" which doesn't have a module declaration in 
 your project. Always including a module declaration is good practice, so 
 you should include one as a matter of course.
 
Thanks. Just out of interest, do you have any pointers, on hand, as to why rebuild is better than bud? It does look like bud is not being developed but I have not had much experience with the tools yet. Thanks ahead, Myron. dprogramming...myron...alexander...com replace the first ... with , remove the second, and replace the third with ".".
Jun 13 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
 Just out of interest, do you have any pointers, on hand, as to why
 rebuild is better than bud? It does look like bud is not being developed
 but I have not had much experience with the tools yet.
 
 Thanks ahead,
 
 Myron.
One reason why I've started moving over to rebuild is -oqPATH. This tells rebuild to put the intermediate object files into the PATH directory with fully qualified names (aka: Gregorian Notation). The problem with bud is that, if I remember correctly, you either put the object files with the source files (which sticks them all over the bloody place), or all in one directory where you can get name clashes. That said, bud is slightly easier to use directly from the command line because you can have +targets. -- Daniel
Jun 13 2007
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Daniel Keep wrote:
 Just out of interest, do you have any pointers, on hand, as to why
 rebuild is better than bud? It does look like bud is not being developed
 but I have not had much experience with the tools yet.

 Thanks ahead,

 Myron.
One reason why I've started moving over to rebuild is -oqPATH. This tells rebuild to put the intermediate object files into the PATH directory with fully qualified names (aka: Gregorian Notation). The problem with bud is that, if I remember correctly, you either put the object files with the source files (which sticks them all over the bloody place), or all in one directory where you can get name clashes. That said, bud is slightly easier to use directly from the command line because you can have +targets. -- Daniel
Actually (as I recall) you can avoid the clashes by passing bud both of -odPATH and --op (note double-dashes) which will recreate the packaging of modules as a directory tree rooted at PATH. Not neccessarily as good as "Gregorian Notation" (which I still wish the compiler would adopt), but usable. -- Chris Nicholson-Sauls
Jun 13 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Chris Nicholson-Sauls wrote:
 Daniel Keep wrote:
 
 Just out of interest, do you have any pointers, on hand, as to why
 rebuild is better than bud? It does look like bud is not being developed
 but I have not had much experience with the tools yet.

 Thanks ahead,

 Myron.
One reason why I've started moving over to rebuild is -oqPATH. This tells rebuild to put the intermediate object files into the PATH directory with fully qualified names (aka: Gregorian Notation). The problem with bud is that, if I remember correctly, you either put the object files with the source files (which sticks them all over the bloody place), or all in one directory where you can get name clashes. That said, bud is slightly easier to use directly from the command line because you can have +targets. -- Daniel
Actually (as I recall) you can avoid the clashes by passing bud both of -odPATH and --op (note double-dashes) which will recreate the packaging of modules as a directory tree rooted at PATH. Not neccessarily as good as "Gregorian Notation" (which I still wish the compiler would adopt), but usable. -- Chris Nicholson-Sauls
This breaks as soon as you specify any source files as their absolute path. (I forget all the details; it's been a while since I went and worked all this out.) If Bud is unable to determine a sensible relative path, it defaults to placing the object file alongside the source file. (Which causes the usual litany of problems.) -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jun 13 2007
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 13 Jun 2007 16:04:47 -0700, Kirk McDonald wrote:

 Chris Nicholson-Sauls wrote:
 Daniel Keep wrote:
 
 Just out of interest, do you have any pointers, on hand, as to why
 rebuild is better than bud? It does look like bud is not being developed
 but I have not had much experience with the tools yet.

 Thanks ahead,

 Myron.
One reason why I've started moving over to rebuild is -oqPATH. This tells rebuild to put the intermediate object files into the PATH directory with fully qualified names (aka: Gregorian Notation). The problem with bud is that, if I remember correctly, you either put the object files with the source files (which sticks them all over the bloody place), or all in one directory where you can get name clashes. That said, bud is slightly easier to use directly from the command line because you can have +targets. -- Daniel
Actually (as I recall) you can avoid the clashes by passing bud both of -odPATH and --op (note double-dashes) which will recreate the packaging of modules as a directory tree rooted at PATH. Not neccessarily as good as "Gregorian Notation" (which I still wish the compiler would adopt), but usable. -- Chris Nicholson-Sauls
This breaks as soon as you specify any source files as their absolute path. (I forget all the details; it's been a while since I went and worked all this out.) If Bud is unable to determine a sensible relative path, it defaults to placing the object file alongside the source file.
No it doesn't. DMD does that, not Bud.
 (Which causes the usual litany of problems.)
What are these problems? I've not had them myself. -- Derek Parnell Melbourne, Australia "Justice for David Hicks!" skype: derek.j.parnell
Jun 13 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Derek Parnell wrote:
 On Wed, 13 Jun 2007 16:04:47 -0700, Kirk McDonald wrote:
 
 Chris Nicholson-Sauls wrote:
 Daniel Keep wrote:

 Just out of interest, do you have any pointers, on hand, as to why
 rebuild is better than bud? It does look like bud is not being developed
 but I have not had much experience with the tools yet.

 Thanks ahead,

 Myron.
One reason why I've started moving over to rebuild is -oqPATH. This tells rebuild to put the intermediate object files into the PATH directory with fully qualified names (aka: Gregorian Notation). The problem with bud is that, if I remember correctly, you either put the object files with the source files (which sticks them all over the bloody place), or all in one directory where you can get name clashes. That said, bud is slightly easier to use directly from the command line because you can have +targets. -- Daniel
Actually (as I recall) you can avoid the clashes by passing bud both of -odPATH and --op (note double-dashes) which will recreate the packaging of modules as a directory tree rooted at PATH. Not neccessarily as good as "Gregorian Notation" (which I still wish the compiler would adopt), but usable. -- Chris Nicholson-Sauls
This breaks as soon as you specify any source files as their absolute path. (I forget all the details; it's been a while since I went and worked all this out.) If Bud is unable to determine a sensible relative path, it defaults to placing the object file alongside the source file.
No it doesn't. DMD does that, not Bud.
Er, you're right, of course.
 (Which causes the usual litany of problems.)
What are these problems? I've not had them myself.
Primarily, this causes issues if the source files are located in directories to which the user does not have write access. -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jun 13 2007
parent Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 13 Jun 2007 21:55:53 -0700, Kirk McDonald wrote:

 Derek Parnell wrote:
 (Which causes the usual litany of problems.)
What are these problems? I've not had them myself.
Primarily, this causes issues if the source files are located in directories to which the user does not have write access.
A very good point indeed. It is because I don't work in such an environment (with D) I haven't had these issues. Of course, it would be better if the compiler did this rather than 3rd party tools, so we should be lobbying the C++ lads that influence Walter to get DMD improved. <G> I'll start working on Bud to provide this capability. I don't have Rebuild so my implementation of the concept is likely to be different, but I hope still useful. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 14/06/2007 5:41:07 PM
Jun 14 2007
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 14 Jun 2007 00:39:19 +1000, Daniel Keep wrote:

 Just out of interest, do you have any pointers, on hand, as to why
 rebuild is better than bud? It does look like bud is not being developed
 but I have not had much experience with the tools yet.
 
 Thanks ahead,
 
 Myron.
One reason why I've started moving over to rebuild is -oqPATH. This tells rebuild to put the intermediate object files into the PATH directory with fully qualified names (aka: Gregorian Notation). The problem with bud is that, if I remember correctly, you either put the object files with the source files (which sticks them all over the bloody place), or all in one directory where you can get name clashes.
A side effect of doing the -oqPATH is that is causes multiple runs of DMD, because DMD only knows how to write object files out to either the source file location or the location named on the -od switch. To have object files each placed in a separate location other than the source location means one has to run DMD separately for each source file (or at least for each unique source location). I have yet to workout why placement of object files is of such a critical issue. An object file is an intermediate file. It is used to either create an executable or a library, and then discarded. On rare occasions is can be retained to inspect the output machine code of the compiler, but why worry about where it lives. It will be discarded eventually. In Bud, I've chosen to reduce the number of calls to DMD instead of concerning myself about where to place temporary files. However, if this is really an issue I can have Bud call DMD multiple times for you to place temporary files in the folder of your choice. -- Derek Parnell Melbourne, Australia "Justice for David Hicks!" skype: derek.j.parnell
Jun 13 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Derek Parnell wrote:
 On Thu, 14 Jun 2007 00:39:19 +1000, Daniel Keep wrote:
 
 Just out of interest, do you have any pointers, on hand, as to why
 rebuild is better than bud? It does look like bud is not being developed
 but I have not had much experience with the tools yet.

 Thanks ahead,

 Myron.
One reason why I've started moving over to rebuild is -oqPATH. This tells rebuild to put the intermediate object files into the PATH directory with fully qualified names (aka: Gregorian Notation). The problem with bud is that, if I remember correctly, you either put the object files with the source files (which sticks them all over the bloody place), or all in one directory where you can get name clashes.
A side effect of doing the -oqPATH is that is causes multiple runs of DMD, because DMD only knows how to write object files out to either the source file location or the location named on the -od switch. To have object files each placed in a separate location other than the source location means one has to run DMD separately for each source file (or at least for each unique source location).
This is not strictly true. If there aren't actually any name collisions, you can just run DMD once and then rename/move the resulting object files to whatever scheme you want. If there is a name collision, then you can just compile all of the modules which don't collide first, rename them, and then compile the colliding ones. If I'm not mistaken, this is how rebuild works. Therefore, rebuild usually just calls DMD once, or sometimes twice.
 I have yet to workout why placement of object files is of such a critical
 issue. An object file is an intermediate file. It is used to either create
 an executable or a library, and then discarded. On rare occasions is can be
 retained to inspect the output machine code of the compiler, but why worry
 about where it lives. It will be discarded eventually.
 
It is highly desirable to be able to jam all of these temporary files into a specific, off-to-the-side place. I do not like cluttering my source tree with temporary files.
 In Bud, I've chosen to reduce the number of calls to DMD instead of
 concerning myself about where to place temporary files. However, if this is
 really an issue I can have Bud call DMD multiple times for you to place
 temporary files in the folder of your choice.
 
-- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Jun 13 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 13 Jun 2007 22:10:09 -0700, Kirk McDonald wrote:

 It is highly desirable to be able to jam all of these temporary files 
 into a specific, off-to-the-side place. I do not like cluttering my 
 source tree with temporary files.
I use the "-clean" switch to immediately remove them. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 14/06/2007 5:47:24 PM
Jun 14 2007
parent reply Myron Alexander <someone somewhere.com> writes:
Derek Parnell wrote:
 On Wed, 13 Jun 2007 22:10:09 -0700, Kirk McDonald wrote:
 
 It is highly desirable to be able to jam all of these temporary files 
 into a specific, off-to-the-side place. I do not like cluttering my 
 source tree with temporary files.
I use the "-clean" switch to immediately remove them.
Derek, Are you still developing Bud or do you consider Bud complete? I only ask because it has been 8 months since the last change. Regards, Myron.
Jun 14 2007
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 14 Jun 2007 12:49:45 +0200, Myron Alexander wrote:

 Derek Parnell wrote:
 On Wed, 13 Jun 2007 22:10:09 -0700, Kirk McDonald wrote:
 
 It is highly desirable to be able to jam all of these temporary files 
 into a specific, off-to-the-side place. I do not like cluttering my 
 source tree with temporary files.
I use the "-clean" switch to immediately remove them.
Derek, Are you still developing Bud or do you consider Bud complete? I only ask because it has been 8 months since the last change.
I am still developing it. I have a number of changes already coded into it but nothing revolutionary. I'll add the facility to name the alternative output file location(s) and then release the next version. I have been wondering about using some post V1.0 features but now I've decided not to do that yet. However, I've refactored a lot of the code to make the modules a lot more self-suffcient and reduce cohesion between them. -- Derek Parnell Melbourne, Australia "Justice for David Hicks!" skype: derek.j.parnell
Jun 14 2007
parent Myron Alexander <someone somewhere.com> writes:
Derek Parnell wrote:
 I am still developing it. I have a number of changes already coded into it
 but nothing revolutionary. I'll add the facility to name the alternative
 output file location(s) and then release the next version.
 
 I have been wondering about using some post V1.0 features but now I've
 decided not to do that yet. However, I've refactored a lot of the code to
 make the modules a lot more self-suffcient and reduce cohesion between
 them. 
 
 
That's good news. Thanks. Myron.
Jun 14 2007