DSSS, the D Shared Software System, is a tool to ease the building, installation, configuration and acquisition of D software.

0.72 and 0.72.1 have been fairly tiny releases. 0.72 just fixed a bug. 0.72.1 is tiny in terms of changes, but the one change is big:
 - Now supports D 2.0.

Note that 2.0 support is not extensively tested (my primary platform is GDC), but it did compile some simple tests.

As per usual, more information and downloads are available at http://www.dsource.org/projects/dsss/

 - Gregor Richards

Thank you!

Gregor Richards escribió:
> DSSS, the D Shared Software System, is a tool to ease the building, installation, configuration and acquisition of D software.
> 
> 0.72 and 0.72.1 have been fairly tiny releases. 0.72 just fixed a bug. 0.72.1 is tiny in terms of changes, but the one change is big:
>  - Now supports D 2.0.
> 
> Note that 2.0 support is not extensively tested (my primary platform is GDC), but it did compile some simple tests.
> 
> As per usual, more information and downloads are available at http://www.dsource.org/projects/dsss/
> 
>  - Gregor Richards

The makefile doesn't seem to be updated:

make: *** No rule to make target `traits.o', needed by `rebuild'.  Stop.

-- 
Carlos Santander Bernal

Carlos Santander wrote:
> Gregor Richards escribió:
>> DSSS, the D Shared Software System, is a tool to ease the building, installation, configuration and acquisition of D software.
>>
>> 0.72 and 0.72.1 have been fairly tiny releases. 0.72 just fixed a bug. 0.72.1 is tiny in terms of changes, but the one change is big:
>>  - Now supports D 2.0.
>>
>> Note that 2.0 support is not extensively tested (my primary platform is GDC), but it did compile some simple tests.
>>
>> As per usual, more information and downloads are available at http://www.dsource.org/projects/dsss/
>>
>>  - Gregor Richards
> 
> The makefile doesn't seem to be updated:
> 
> make: *** No rule to make target `traits.o', needed by `rebuild'.  Stop.
> 

I had forgotten to svn add traits.c. I've updated the sources. The binaries are right.

 - Gregor Richards

Gregor Richards escribió:
> Carlos Santander wrote:
>>
>> The makefile doesn't seem to be updated:
>>
>> make: *** No rule to make target `traits.o', needed by `rebuild'.  Stop.
>>
> 
> I had forgotten to svn add traits.c. I've updated the sources. The binaries are right.
> 
>  - Gregor Richards

Thanks. Another error, though:

g++ -g  access.o array.o attrib.o cast.o class.o compile.o cond.o config.o constfold.o dchar.o declaration.o delegatize.o doc.o dsymbol.o dump.o entity.o enum.o expression.o func.o gnuc.o hdrgen.o html.o id.o identifier.o impcnvtab.o import.o inifile.o init.o inline.o interpret.o lexer.o link.o lstring.o macro.o mangle.o mars.o mem.o module.o mtype.o opover.o optimize.o parse.o response.o root.o scope.o statement.o staticassert.o stringtable.o struct.o template.o traits.o unialpha.o utf.o version.o whereami.o -o rebuild
/usr/bin/ld: Undefined symbols:
VarExp::VarExp(Loc, Declaration*)
ForeachRangeStatement::inlineScan(InlineScanState*)
collect2: ld returned 1 exit status

-- 
Carlos Santander Bernal

Carlos Santander wrote:
> Gregor Richards escribió:
>> Carlos Santander wrote:
>>>
>>> The makefile doesn't seem to be updated:
>>>
>>> make: *** No rule to make target `traits.o', needed by `rebuild'.  Stop.
>>>
>>
>> I had forgotten to svn add traits.c. I've updated the sources. The binaries are right.
>>
>>  - Gregor Richards
> 
> Thanks. Another error, though:
> 
> g++ -g  access.o array.o attrib.o cast.o class.o compile.o cond.o config.o constfold.o dchar.o declaration.o delegatize.o doc.o dsymbol.o dump.o entity.o enum.o expression.o func.o gnuc.o hdrgen.o html.o id.o identifier.o impcnvtab.o import.o inifile.o init.o inline.o interpret.o lexer.o link.o lstring.o macro.o mangle.o mars.o mem.o module.o mtype.o opover.o optimize.o parse.o response.o root.o scope.o statement.o staticassert.o stringtable.o struct.o template.o traits.o unialpha.o utf.o version.o whereami.o -o rebuild
> /usr/bin/ld: Undefined symbols:
> VarExp::VarExp(Loc, Declaration*)
> ForeachRangeStatement::inlineScan(InlineScanState*)
> collect2: ld returned 1 exit status
> 

Well that's strange. I compiled it cleanly, from scratch, and had no such issues. Are you compiling from the source .tar.bz2 or svn? If svn, did you try 'make clean' in rebuild? Sometimes with big upgrades and old .o files it can get wonky.

Mayhaps this is something unique to OS X?

 - Gregor Richards

Gregor Richards escribió:
> Carlos Santander wrote:
>>
>> g++ -g  access.o array.o attrib.o cast.o class.o compile.o cond.o config.o constfold.o dchar.o declaration.o delegatize.o doc.o dsymbol.o dump.o entity.o enum.o expression.o func.o gnuc.o hdrgen.o html.o id.o identifier.o impcnvtab.o import.o inifile.o init.o inline.o interpret.o lexer.o link.o lstring.o macro.o mangle.o mars.o mem.o module.o mtype.o opover.o optimize.o parse.o response.o root.o scope.o statement.o staticassert.o stringtable.o struct.o template.o traits.o unialpha.o utf.o version.o whereami.o -o rebuild
>> /usr/bin/ld: Undefined symbols:
>> VarExp::VarExp(Loc, Declaration*)
>> ForeachRangeStatement::inlineScan(InlineScanState*)
>> collect2: ld returned 1 exit status
>>
> 
> Well that's strange. I compiled it cleanly, from scratch, and had no such issues. Are you compiling from the source .tar.bz2 or svn? If svn, did you try 'make clean' in rebuild? Sometimes with big upgrades and old ..o files it can get wonky.
> 
> Mayhaps this is something unique to OS X?
> 
>  - Gregor Richards

SVN. "make clean" solved it. Sometimes I forget to do that. Thanks.

-- 
Carlos Santander Bernal

Gregor Richards wrote:
> DSSS, the D Shared Software System, is a tool to ease the building, installation, configuration and acquisition of D software.
> 
> 0.72 and 0.72.1 have been fairly tiny releases. 0.72 just fixed a bug.
> 0.72.1 is tiny in terms of changes, but the one change is big:
>  - Now supports D 2.0.
> 
> Note that 2.0 support is not extensively tested (my primary platform is GDC), but it did compile some simple tests.
> 
> As per usual, more information and downloads are available at http://www.dsource.org/projects/dsss/
> 
>  - Gregor Richards

Hooray.

Also, your slides were very entertaining.  The graph of UNIX build tools was particularly amusing.

So, anyway.  DSSS is putting me in a bit of a palava.  I actually have four different, incompatible compilers on my system: DMD 1.x with Phobos, DMD 1.x with Tango, DMD 2.x with Phobos and GCD 0.somethingorother with GPhobos.  You'll note I haven't tried getting GDC w/ Tango to work yet, which would make it five.

Now, I can use the -dc=blah switch to go between them, which is fine... until I actually use any libraries from DSSS.  The problem is that DSSS *insists* on compiling everything down to libraries, which means that if I `dsss net install` DerelictGL, say, using -dc=dmd-win, then I cannot compile a program using -dc=dmd-win-tango with DSSS.

It gets more fun when you manually check out the latest Derelict source into your project's source folder, recompile, and discover that DSSS's import directory is before everything else on the command line.  Which means you would have to completely remove Derelict from DSSS.  Which I believe is because arguments get inserted into the command line as `$DFLAGS $COMMAND_LINE`.

Which, in the end, means I can't really use DSSS for projects on different compilers that use the same library.  Funnily enough, that's the exact same set of projects I'm trying to use DSSS for... :(

So, question: are you planning to add versioning to DSSS at some point in the future?  I don't need it *right now*, but it would be nice to know.  In the meantime, is there any chance of getting a "you know what, don't bother compiling this to a library; just use the source every time.  Yes, I know it's not efficient, but it's that or linker errors. Don't give me that puppy-dog-eyes look!  Just do it" flag?

	-- Daniel

Daniel Keep wrote:
> Gregor Richards wrote:
>> DSSS, the D Shared Software System, is a tool to ease the building,
>> installation, configuration and acquisition of D software.
>>
>> 0.72 and 0.72.1 have been fairly tiny releases. 0.72 just fixed a bug.
>> 0.72.1 is tiny in terms of changes, but the one change is big:
>>  - Now supports D 2.0.
>>
>> Note that 2.0 support is not extensively tested (my primary platform is
>> GDC), but it did compile some simple tests.
>>
>> As per usual, more information and downloads are available at
>> http://www.dsource.org/projects/dsss/
>>
>>  - Gregor Richards
> 
> Hooray.
> 
> Also, your slides were very entertaining.  The graph of UNIX build tools
> was particularly amusing.
> 
> So, anyway.  DSSS is putting me in a bit of a palava.  I actually have
> four different, incompatible compilers on my system: DMD 1.x with
> Phobos, DMD 1.x with Tango, DMD 2.x with Phobos and GCD
> 0.somethingorother with GPhobos.  You'll note I haven't tried getting
> GDC w/ Tango to work yet, which would make it five.
> 
> Now, I can use the -dc=blah switch to go between them, which is fine...
> until I actually use any libraries from DSSS.  The problem is that DSSS
> *insists* on compiling everything down to libraries, which means that if
> I `dsss net install` DerelictGL, say, using -dc=dmd-win, then I cannot
> compile a program using -dc=dmd-win-tango with DSSS.
> 
> It gets more fun when you manually check out the latest Derelict source
> into your project's source folder, recompile, and discover that DSSS's
> import directory is before everything else on the command line.  Which
> means you would have to completely remove Derelict from DSSS.  Which I
> believe is because arguments get inserted into the command line as
> `$DFLAGS $COMMAND_LINE`.
> 
> Which, in the end, means I can't really use DSSS for projects on
> different compilers that use the same library.  Funnily enough, that's
> the exact same set of projects I'm trying to use DSSS for... :(
> 
> So, question: are you planning to add versioning to DSSS at some point
> in the future?  I don't need it *right now*, but it would be nice to
> know.  In the meantime, is there any chance of getting a "you know what,
> don't bother compiling this to a library; just use the source every
> time.  Yes, I know it's not efficient, but it's that or linker errors.
> Don't give me that puppy-dog-eyes look!  Just do it" flag?
> 
> 	-- Daniel

This is an aspect of versioning I hadn't considered very thoroughly. This will definitely be subsumed by the library-versioning support DSSS will eventually have, but this is actually a comparably simple subset. I'll have to muddle over it.

I have several compilers, but all in different prefixes with their own DSSS'. It's nice to know that DSSS almost works with your setup ;)

 - Gregor Richards

Gregor Richards wrote:
> Daniel Keep wrote:
>> Gregor Richards wrote:
>>> DSSS, the D Shared Software System, is a tool to ease the building,
>>> installation, configuration and acquisition of D software.
>>>
>>> 0.72 and 0.72.1 have been fairly tiny releases. 0.72 just fixed a bug.
>>> 0.72.1 is tiny in terms of changes, but the one change is big:
>>>  - Now supports D 2.0.
>>>
>>> Note that 2.0 support is not extensively tested (my primary platform is
>>> GDC), but it did compile some simple tests.
>>>
>>> As per usual, more information and downloads are available at
>>> http://www.dsource.org/projects/dsss/
>>>
>>>  - Gregor Richards
>>
>> Hooray.
>>
>> Also, your slides were very entertaining.  The graph of UNIX build tools
>> was particularly amusing.
>>
>> So, anyway.  DSSS is putting me in a bit of a palava.  I actually have
>> four different, incompatible compilers on my system: DMD 1.x with
>> Phobos, DMD 1.x with Tango, DMD 2.x with Phobos and GCD
>> 0.somethingorother with GPhobos.  You'll note I haven't tried getting
>> GDC w/ Tango to work yet, which would make it five.
>>
>> Now, I can use the -dc=blah switch to go between them, which is fine...
>> until I actually use any libraries from DSSS.  The problem is that DSSS
>> *insists* on compiling everything down to libraries, which means that if
>> I `dsss net install` DerelictGL, say, using -dc=dmd-win, then I cannot
>> compile a program using -dc=dmd-win-tango with DSSS.
>>
>> It gets more fun when you manually check out the latest Derelict source
>> into your project's source folder, recompile, and discover that DSSS's
>> import directory is before everything else on the command line.  Which
>> means you would have to completely remove Derelict from DSSS.  Which I
>> believe is because arguments get inserted into the command line as
>> `$DFLAGS $COMMAND_LINE`.
>>
>> Which, in the end, means I can't really use DSSS for projects on
>> different compilers that use the same library.  Funnily enough, that's
>> the exact same set of projects I'm trying to use DSSS for... :(
>>
>> So, question: are you planning to add versioning to DSSS at some point
>> in the future?  I don't need it *right now*, but it would be nice to
>> know.  In the meantime, is there any chance of getting a "you know what,
>> don't bother compiling this to a library; just use the source every
>> time.  Yes, I know it's not efficient, but it's that or linker errors.
>> Don't give me that puppy-dog-eyes look!  Just do it" flag?
>>
>>     -- Daniel
> 
> This is an aspect of versioning I hadn't considered very thoroughly. This will definitely be subsumed by the library-versioning support DSSS will eventually have, but this is actually a comparably simple subset. I'll have to muddle over it.
> 
> I have several compilers, but all in different prefixes with their own DSSS'. It's nice to know that DSSS almost works with your setup ;)
> 
>  - Gregor Richards


I was having issues with this too.  It seems that despite the nice prefixes dsss uses to keep dmd and gdc versions of things distinct, when you do "dsss net install derelictgl" it just blows away the previous lib and then installs the new one, even if the prefixes are different.

Also I was trying to get my Luigi lib to build with dsss under gdc, but for some reason no matter what I try it wants to link apps with the SDD version of luigi instead of the SDG one.  All I should have to make dsss use gdc is to change the "profile=" line in etc/rebuild/default, right?  (this was on Linux)

--bb