A problem use-case for DSSS | was - Re: A question about modules - suggestion for convention

[Myron Alexander]

Robert Fraser wrote:
> You can use DSSS without putting the library in the net repository.
> DSSS also has support for version statements, etc., and you can
> always have multiple copies of a library in DSSS, for different
> purposes.

I have split my library into two libraries, dbapi and sqlite. The sqlite 
library is the glue code that used to be in the "dbapi/c" directory but 
I decided that it should be split from the dbapi code to make it easier 
to support different sqlite library versions. The dbapi depends on the 
sqlite library. The sqlite library is made up of two files: sqlite3.lib 
and sqlite3.di.

By hand, I create the library as follows:

implib /s out\sqlite3.lib sqlitedll\sqlite3.dll
dmd -c -o- -H -Hdout\di\sqlite src\sqlite\sqlite3.d

Now I want to translate it to DSSS and allow DSSS to store the result in 
the repository. It took a while, but I finally figured out how to do it. 
Here is my config file:

 > name    = sqlite3-glue-library-3.3.17
 > version = 3.3.17
 >
 > [+sqlite]
 > prebuild    = implib /s out\SDD-sqlite-3.3.17.lib sqlitedll\sqlite3.dll
 > postbuild   = dmd -c -o- -H -Hdout\di\sqlite src\sqlite\sqlite3.d
 > postinstall = install out/SDD-sqlite-3.3.17.lib  $LIB_PREFIX; \
 >               install out/di/sqlite/sqlite3.di $INCLUDE_PREFIX/sqlite

Now that I have used DSSS, I can safely say that my original comments 
about DSSS versioning weakness stands. It just copies all the includes 
into a global include directory, and all the libs into a global lib 
directory. The name is just for a package manifest. Here is what I said:

> What about debug libraries? Also, how does it handle versioning, specifically unreleased experimental versions that are distributed to a few alpha/beta testers? What about libraries that have special build conditions? Some example build conditions (outside of portability issues): trial versions, lite versions (only core features), modular vs monolithic versions, and so on.

Now let say that, for some reason, I have to make a tested version of 
dbapi linked to sqlite3.dll version 3.3.10. This could be due to some 
corporate that is using that version, happy with it, and won't change 
it. I create a copy of my 3.3.17 library and hand edit the .d file based 
on diffs between the .h versions (as I have been doing when upping the 
library version). The module name and relative location does not change, 
how do I install the .di file for 3.3.10 without overwriting 3.3.17?

The library is no problem as I will change the name to be 
SDD-sqlite-3.3.10.lib which will sit happily with SDD-sqlite-3.3.17.lib.

I hope I have shown that DSSS does not solve all problems, yet. What 
Gregor is trying to achieve is not trivial, but not impossible.

> 
> As far as your other suggestion goes, have you checked out DDL
> (http://www.dsource.org/projects/ddl )? It's designed primarily
> around dynamic libraries, but the format certainly contains enough
> information for static linking. It would be great if the same format
> could be used for both static and dynamic linking, though exactly how
> this would work I can't imagine. The project looks dead, but I think
> pragma said he plans to get back to it once tango gets to 1.0.
> 

Something to check out once the project gets going again.

Myron.
dprogramming...myron...alexander...com
replace the first ... with @, remove the second, and replace the third
with ".".