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 ".".

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.

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

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.

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

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 ".".

> 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

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

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

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