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