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