www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DSSS 0.72.1 released.

reply Gregor Richards <Richards codu.org> writes:
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
Aug 26 2007
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Thank you!
Aug 27 2007
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
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
Aug 27 2007
parent reply Gregor Richards <Richards codu.org> writes:
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
Aug 27 2007
parent reply Carlos Santander <csantander619 gmail.com> writes:
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
Aug 27 2007
parent reply Gregor Richards <Richards codu.org> writes:
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
Aug 27 2007
parent Carlos Santander <csantander619 gmail.com> writes:
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
Aug 27 2007
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Aug 27 2007
parent reply Gregor Richards <Richards codu.org> writes:
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
Aug 27 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Aug 27 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:
 Gregor Richards wrote:
 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
Yes, well, my setup is kinda flaky. It's amazing anything works at all...
 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
Maybe DSSS should have a separate concept of compilers to version flags. So when you install something, it compiles it for each of the installed compilers; that way, DMD 1, DMD 2, GDC, DMD+Tango, etc. can all cooperate. -- Daniel
Aug 28 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Keep wrote:
 
 Bill Baxter wrote:
 Gregor Richards wrote:
 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
Yes, well, my setup is kinda flaky. It's amazing anything works at all...
 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
Maybe DSSS should have a separate concept of compilers to version flags. So when you install something, it compiles it for each of the installed compilers; that way, DMD 1, DMD 2, GDC, DMD+Tango, etc. can all cooperate.
I figured out what the problem was with dsss. I had built once using the dmd-posix profile, and those dsss_imports were still lying around. Apparently they don't get re-generated when the profile changes. YOu have to manually delete them. Something to watch out for. --bb
Aug 28 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Gregor,

 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
 
Feature request: can we get some of dimple's functionality added to DSSS? http://www.shfls.org/w/d/dimple/
Aug 28 2007
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
BCS wrote:
...
 Feature request: can we get some of dimple's functionality added to DSSS?
 
 http://www.shfls.org/w/d/dimple/
 
 
That would be nice. Bud has a -uses flag which lists for each module what it imports, that should be enough to recreate dimple in a straightforward manner.
Aug 28 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Lutger,

 BCS wrote:
 ...
 Feature request: can we get some of dimple's functionality added to
 DSSS?
 
 http://www.shfls.org/w/d/dimple/
 
That would be nice. Bud has a -uses flag which lists for each module what it imports, that should be enough to recreate dimple in a straightforward manner.
I'm thinking it would be nice if DSSS could generate some sort of build report. Ideally this would be a html file that would list things like: the build status of every module the output from each modules (sorted by some regex rules) an import graphs, greps of any recompiled source (for coding standard checks) the process run time (how long the build took the used command lines flags the command lines run external libs used ... The next step would be a cgi wrapper script that would kick DSSS and then return the status page. (but we needn’t go there yet :)
Aug 28 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
BCS wrote:
 
 I'm thinking it would be nice if DSSS could generate some sort of build 
 report.
 
 Ideally this would be a html file that would list things like:
  the build status of every module
  the output from each modules (sorted by some regex rules)
  an import graphs,
  greps of any recompiled source (for coding standard checks)
  the process run time (how long the build took
  the used command lines flags
  the command lines run
  external libs used
  ...
 
 The next step would be a cgi wrapper script that would kick DSSS and 
 then return the status page. (but we needn’t go there yet :)
 
That would be awesome. I mentioned the -uses option because I thought it might be a good way to get the same thing with less work for Gregor.
Aug 28 2007
prev sibling parent reply BCS <ao pathlink.com> writes:
Reply to Gregor,

 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
when is the scripting/output capture stuff coming out? weeks? months? minutes? I ask because I'm hoping to convert a project of mine to use DSSS but I don't want to unless I can get some additional processing stuff at the same time. Another issue/question: Can DSSS be set up to consider a particular file as a library? I ask because the project in consideration has a build time of about 3 sec for all but one file that has a build time of more like 30 sec. (it uses lots of templates) I want to do full rebuilds every time, but that is not going to be practical for that one file. What I'd like to do is run a full rebuild of the whole project and do a partial rebuild of only that part.
Sep 02 2007
parent reply Gregor Richards <Richards codu.org> writes:
BCS wrote:
 Reply to Gregor,
 
 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
when is the scripting/output capture stuff coming out? weeks? months? minutes?
The next release should have a midbuild hook command, which will allow you to capture build output, unless I get hung up on stupid stuff. It will also lay the framework for scripting support, though it'll be a release or two before any of that appears. I can't really give good timelines, but somewhere between "weeks" and "months" is probably right.
 
 I ask because I'm hoping to convert a project of mine to use DSSS but I 
 don't want to unless I can get some additional processing stuff at the 
 same time.
 
 Another issue/question: Can DSSS be set up to consider a particular file 
 as a library? I ask because the project in consideration has a build 
 time of about 3 sec for all but one file that has a build time of more 
 like 30 sec. (it uses lots of templates) I want to do full rebuilds 
 every time, but that is not going to be practical for that one file. 
 What I'd like to do is run a full rebuild of the whole project and do a 
 partial rebuild of only that part.
 
 
Sure. Just like making a package a library, except use a module as the section header: [foo/a.d] type=library - Gregor Richards
Sep 03 2007
parent BCS <ao pathlink.com> writes:
Reply to Gregor,

 BCS wrote:
 
 Reply to Gregor,
 
 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
 
when is the scripting/output capture stuff coming out? weeks? months? minutes?
The next release should have a midbuild hook command, which will allow you to capture build output, unless I get hung up on stupid stuff. It will also lay the framework for scripting support, though it'll be a release or two before any of that appears. I can't really give good timelines, but somewhere between "weeks" and "months" is probably right.
 I ask because I'm hoping to convert a project of mine to use DSSS but
 I don't want to unless I can get some additional processing stuff at
 the same time.
 
 Another issue/question: Can DSSS be set up to consider a particular
 file as a library? I ask because the project in consideration has a
 build time of about 3 sec for all but one file that has a build time
 of more like 30 sec. (it uses lots of templates) I want to do full
 rebuilds every time, but that is not going to be practical for that
 one file. What I'd like to do is run a full rebuild of the whole
 project and do a partial rebuild of only that part.
 
Sure. Just like making a package a library, except use a module as the section header: [foo/a.d] type=library - Gregor Richards
so if I want to build main.d, b.d and foo/b.d in one thing but build foo/a.d in another go (assuming that main.d imports everything), that will work? Something like this: [main.d] [foo/a.d] type=library
Sep 03 2007