www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - An open question to Rebuild users

reply Gregor Richards <Richards codu.org> writes:
Judging by the amount of feedback I receive on rebuild, vs the amount of 
feedback I receive on DSSS, I'd say that 95% of rebuild users are not 
DSSS users. That is, there are more users who use rebuild alone than in 
tandem with DSSS. I could be wrong - maybe DSSS just has no bugs :).

Rebuild was designed primarily to complement DSSS, and DSSS was designed 
to be the ideal replacement for 'make' and pals for D, so I find it a 
bit disconcerting that a tool I designed primarily to be a background 
tool is being used as a primary development tool by so many.

So, the obvious question is: Why? Why use rebuild and not DSSS? I 
imagine there must be some misconceptions about DSSS, what it is, what 
it's for, et cetera.

I imagine some common misconceptions are:

  * DSSS is intended solely to be D's answer to CPAN - that is, a 
network installation tool. This just isn't true, the net portion is only 
a small chunk of what DSSS can do.

  * DSSS provides no advantages over using just a build tool. Also not 
true - even if DSSS provided /only/ a convenient build configuration 
file format (dsss.conf), that would be a sizable advantage of rebuild. 
DSSS provides much more, however, including easy generation of libraries 
with associated .di files, installation, documentation, etc, etc. If you 
really want your rebuild profile for an application or library be 
portable, you would need to either have several Makefiles or response 
files wrapped around rebuild (nasty), or use DSSS (nice).

  * DSSS is not portable to Windows. I think most people know that I'm 
not a Windows user, and Windows is mostly a foreign environment to me. 
However, this is not true. I've done my best, and am very responsive to 
bug reports, and DSSS does indeed work on Windows just as well as it 
does on Posix systems.

  * `dsss` is hard to type. Well, I've typed it more than a dozen times 
in this post, and my left ring finger is in no particular pain :)

If your concern or concept isn't noted here, please tell me / ask me! If 
DSSS /isn't/ everything you need it to be, help me /make/ it what you 
need it to be :).

  - Gregor Richards
Apr 16 2007
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:


 So, the obvious question is: Why? Why use rebuild and not DSSS? I
 imagine there must be some misconceptions about DSSS, what it is,
 what it's for, et cetera.



  * DSSS provides no advantages over using just a build tool. Also not 
 true - even if DSSS provided /only/ a convenient build configuration 
 file format (dsss.conf), that would be a sizable advantage of rebuild. 
 DSSS provides much more, however, including easy generation of libraries 
 with associated .di files, installation, documentation, etc, etc. If you 
 really want your rebuild profile for an application or library be 
 portable, you would need to either have several Makefiles or response 
 files wrapped around rebuild (nasty), or use DSSS (nice).


I'm using Rebuild as a Bud/Build alternative, mostly since it was
easier to compile but also since it seems to be a lot faster too.

Eventually I might look into trying to replace several Makefiles
with dsss.conf, but there is a slight learning threshold involved ?
So while I'm sure it's nice, I just haven't gotten around to it...
Thus the process still uses: gnumake --> rebuild --> gdmd --> gdc

Is there a problem if one finds rebuild useful without using DSSS ?
"Good ol' make. Nuthin' beats that!" - "Make!" - "DSSS!" - "D'oh!" :-)

--anders

PS. A migration guide might help ?
Apr 16 2007
parent Howard Berkey <howard well.com> writes:


 
 I'm using Rebuild as a Bud/Build alternative, mostly since it was
 easier to compile but also since it seems to be a lot faster too.
 


That's why I initially grabbed it and dsss too, but I haven't looked back since
just using dsss for everything.


 Eventually I might look into trying to replace several Makefiles
 with dsss.conf, but there is a slight learning threshold involved ?


In my experience, very slight.  I found it pretty ridiculously easy to get
started with.  Granted the largest thing I have built with it are some projects
using derelict and others using gtkD; I haven't used it to replace makefiles in
a large system yet.  

Howard
Apr 16 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:


 If your concern or concept isn't noted here, please tell me / ask me! If 
 DSSS /isn't/ everything you need it to be, help me /make/ it what you 
 need it to be :).


I'm missing a --dry-run flag, that would print out everything it
would have done *if* you had executed it. Often used with install ?

And a man page, but I put one here: http://gdcgnu.sf.net/dsss.1

--anders
Apr 16 2007
parent reply Carlos Santander <csantander619 gmail.com> writes:
Anders F Björklund escribió:

 Gregor Richards wrote:
 

 If your concern or concept isn't noted here, please tell me / ask me! 
 If DSSS /isn't/ everything you need it to be, help me /make/ it what 
 you need it to be :).


 
 I'm missing a --dry-run flag, that would print out everything it
 would have done *if* you had executed it. Often used with install ?
 
 And a man page, but I put one here: http://gdcgnu.sf.net/dsss.1
 
 --anders


 From the usage instructions:

-n             just list the commands to be run, don't run them

That?

-- 
Carlos Santander Bernal
Apr 16 2007
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Carlos Santander wrote:


 I'm missing a --dry-run flag, that would print out everything it
 would have done *if* you had executed it. Often used with install ?


 
  From the usage instructions:
 
 -n             just list the commands to be run, don't run them


Yes, that flag - but it only seems to be for "rebuild" - not DSSS ?
i.e. dsss still executes commands, and then passes -n on to rebuild

I'll flag it as an enhancement Ticket...

--anders
Apr 16 2007
parent Carlos Santander <csantander619 gmail.com> writes:
Anders F Björklund escribió:

 Carlos Santander wrote:
 

 I'm missing a --dry-run flag, that would print out everything it
 would have done *if* you had executed it. Often used with install ?


  From the usage instructions:

 -n             just list the commands to be run, don't run them


 
 Yes, that flag - but it only seems to be for "rebuild" - not DSSS ?
 i.e. dsss still executes commands, and then passes -n on to rebuild
 
 I'll flag it as an enhancement Ticket...
 
 --anders


Oops, sorry. I completely missed you were talking about DSSS.

-- 
Carlos Santander Bernal
Apr 17 2007
prev sibling next sibling parent Howard Berkey <howard well.com> writes:
I use rebuild only through dsss, for what it is worth.  And I use dsss every
day I do anything with D, more or less.

Howard

Gregor Richards Wrote:


 Judging by the amount of feedback I receive on rebuild, vs the amount of 
 feedback I receive on DSSS, I'd say that 95% of rebuild users are not 
 DSSS users. That is, there are more users who use rebuild alone than in 
 tandem with DSSS. I could be wrong - maybe DSSS just has no bugs :).
 
 Rebuild was designed primarily to complement DSSS, and DSSS was designed 
 to be the ideal replacement for 'make' and pals for D, so I find it a 
 bit disconcerting that a tool I designed primarily to be a background 
 tool is being used as a primary development tool by so many.
 
 So, the obvious question is: Why? Why use rebuild and not DSSS? I 
 imagine there must be some misconceptions about DSSS, what it is, what 
 it's for, et cetera.
 
 I imagine some common misconceptions are:
 
   * DSSS is intended solely to be D's answer to CPAN - that is, a 
 network installation tool. This just isn't true, the net portion is only 
 a small chunk of what DSSS can do.
 
   * DSSS provides no advantages over using just a build tool. Also not 
 true - even if DSSS provided /only/ a convenient build configuration 
 file format (dsss.conf), that would be a sizable advantage of rebuild. 
 DSSS provides much more, however, including easy generation of libraries 
 with associated .di files, installation, documentation, etc, etc. If you 
 really want your rebuild profile for an application or library be 
 portable, you would need to either have several Makefiles or response 
 files wrapped around rebuild (nasty), or use DSSS (nice).
 
   * DSSS is not portable to Windows. I think most people know that I'm 
 not a Windows user, and Windows is mostly a foreign environment to me. 
 However, this is not true. I've done my best, and am very responsive to 
 bug reports, and DSSS does indeed work on Windows just as well as it 
 does on Posix systems.
 
   * `dsss` is hard to type. Well, I've typed it more than a dozen times 
 in this post, and my left ring finger is in no particular pain :)
 
 If your concern or concept isn't noted here, please tell me / ask me! If 
 DSSS /isn't/ everything you need it to be, help me /make/ it what you 
 need it to be :).
 
   - Gregor Richards
Apr 16 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Gregor Richards wrote:


 Judging by the amount of feedback I receive on rebuild, vs the amount of
 feedback I receive on DSSS, I'd say that 95% of rebuild users are not
 DSSS users. That is, there are more users who use rebuild alone than in
 tandem with DSSS. I could be wrong - maybe DSSS just has no bugs :).


I've found more bugs in Rebuild. For me that's to only reason. I use
both of them.

I think being able to install Tango with DSSS would increase its
popularity. I've probably set up my system wrong since 'dsss net install
dmd' breaks my manually installed Tango.


 Rebuild was designed primarily to complement DSSS, and DSSS was designed
 to be the ideal replacement for 'make' and pals for D, so I find it a
 bit disconcerting that a tool I designed primarily to be a background
 tool is being used as a primary development tool by so many.
 
 So, the obvious question is: Why? Why use rebuild and not DSSS? I
 imagine there must be some misconceptions about DSSS, what it is, what
 it's for, et cetera.
 
 I imagine some common misconceptions are:
 
  * DSSS is intended solely to be D's answer to CPAN - that is, a network
 installation tool. This just isn't true, the net portion is only a small
 chunk of what DSSS can do.


Most probably this.


  * DSSS provides no advantages over using just a build tool. Also not
 true - even if DSSS provided /only/ a convenient build configuration
 file format (dsss.conf), that would be a sizable advantage of rebuild.
 DSSS provides much more, however, including easy generation of libraries
 with associated .di files, installation, documentation, etc, etc. If you
 really want your rebuild profile for an application or library be
 portable, you would need to either have several Makefiles or response
 files wrapped around rebuild (nasty), or use DSSS (nice).


I think the misconception here is that people really don't know how to
do all this. I hope you take this constructively: the documentation
sucks. In fact, I haven't found one anywhere. :-P The 'dsss --help' does
not count. I would like to see a real manual with some simple examples.
'dsss net install foobar' does not save any easily readable
configuration files to any well documented location.

In fact, I was considering makefiles + rebuild for my next project since
I don't know how to use DSSS. Maybe that will change now. ;)


  * DSSS is not portable to Windows. I think most people know that I'm
 not a Windows user, and Windows is mostly a foreign environment to me.
 However, this is not true. I've done my best, and am very responsive to
 bug reports, and DSSS does indeed work on Windows just as well as it
 does on Posix systems.


No.


  * `dsss` is hard to type. Well, I've typed it more than a dozen times
 in this post, and my left ring finger is in no particular pain :)


Certainly not. :)
Apr 16 2007
parent reply Gregor Richards <Richards codu.org> writes:
Jari-Matti Mäkelä wrote:
...

 I think being able to install Tango with DSSS would increase its
 popularity. I've probably set up my system wrong since 'dsss net install
 dmd' breaks my manually installed Tango.


Actually, it's not at all surprising that that would break it, since 
`dsss net install dmd` installs the entirety of the DMD distribution, 
including Phobos.

Sort of a problem ... I should probably add a check for that.

  - Gregor Richards
Apr 16 2007
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Gregor Richards wrote:

 Jari-Matti Mäkelä wrote:
 ...

 I think being able to install Tango with DSSS would increase its
 popularity. I've probably set up my system wrong since 'dsss net install
 dmd' breaks my manually installed Tango.


 
 Actually, it's not at all surprising that that would break it, since
 `dsss net install dmd` installs the entirety of the DMD distribution,
 including Phobos.
 
 Sort of a problem ... I should probably add a check for that.


You previously said you will not add support for Tango (dsss net install
tango) because it breaks phobos. Wouldn't it be easier (for us users) to
have both. So that you can update them via 'dsss net install' and then
change to the correct library with something like 'dsss profile set
phobos/tango/tango-svn'. Or maybe 'dsss net install dmd' should only
update the binaries and 'dsss net install phobos' the rest of the
distribution. Then, a profile system for dmd/gdc would be cool too.


 
  - Gregor Richards
Apr 17 2007
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 Apr 2007 12:51:24 -0700, Gregor Richards wrote:


 Why use rebuild and not DSSS?


Actually, there is (at least) one person that uses neither <G>

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Apr 16 2007
next sibling parent reply torhu <fake address.dude> writes:
Derek Parnell wrote:

 On Mon, 16 Apr 2007 12:51:24 -0700, Gregor Richards wrote:
 

 Why use rebuild and not DSSS?


 
 Actually, there is (at least) one person that uses neither <G>
 


Make that two.  Any bud development going on?
Apr 17 2007
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 17 Apr 2007 21:31:24 +0200, torhu wrote:


 Derek Parnell wrote:

 On Mon, 16 Apr 2007 12:51:24 -0700, Gregor Richards wrote:
 

 Why use rebuild and not DSSS?


 
 Actually, there is (at least) one person that uses neither <G>
 


 
 Make that two.  Any bud development going on?


Yes, there is quite a bit done since the last release. 

I have been waiting to deliberately allow Rebuild some time to gain
momentum and maturity before continuing to offer an alternative. I feel it
might have been unfair to 'compete' while it was still formative.

Though I admit I haven't even downloaded or looked at Rebuild to know what
it can or can't do. As for DSSS, I don't know what the problem is it is
trying to solve so I don't know if I need to use it or not.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Apr 17 2007
next sibling parent reply Jesse Phillips <Jesse.K.Phillips+Digitalmars gmail.com> writes:
On Wed, 18 Apr 2007 07:20:31 +1000, Derek Parnell wrote:


 On Tue, 17 Apr 2007 21:31:24 +0200, torhu wrote:
 

 Derek Parnell wrote:

 On Mon, 16 Apr 2007 12:51:24 -0700, Gregor Richards wrote:
 

 Why use rebuild and not DSSS?


 
 Actually, there is (at least) one person that uses neither <G>
 


 
 Make that two.  Any bud development going on?


 
 Yes, there is quite a bit done since the last release. 
 
 I have been waiting to deliberately allow Rebuild some time to gain
 momentum and maturity before continuing to offer an alternative. I feel it
 might have been unfair to 'compete' while it was still formative.
 
 Though I admit I haven't even downloaded or looked at Rebuild to know what
 it can or can't do. As for DSSS, I don't know what the problem is it is
 trying to solve so I don't know if I need to use it or not.


is rebuild and bud really competing? I just thought rebuild was just
trying to but the il back in bud. No seriously, I thought it just
a modified bud to work more closely with dsss. I suppose I should ask what
is the benefits to rebuild to bud? Was it Gregor's intent to fork bud as a
competitor? And maybe what prevents bud from having that which is added to
rebuild?

As for DSSS I love the concept that it provides. I'm not doing any major
projects, everything I have done fits nicely in one file. However I have
done multiple file stuff and still find dmd easy enough to use. But if I
were to create and distribute D software, I would definitely go with
distributing it in a dsss compatible format.
Apr 17 2007
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 17 Apr 2007 22:35:14 +0000 (UTC), Jesse Phillips wrote:


 I thought it (Rebuild) just
 a modified bud to work more closely with dsss. ... 
 Was it Gregor's intent to fork bud ...


My understanding, and this could be totally wrong of course, is that
Rebuild is a C++ program based on the DMD front-end code. I don't think it
is using any code from the Bud application.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
18/04/2007 9:43:15 AM
Apr 17 2007
prev sibling parent Gregor Richards <Richards codu.org> writes:
Jesse Phillips wrote:

 is rebuild and bud really competing? I just thought rebuild was just
 trying to but the il back in bud. No seriously, I thought it just
 a modified bud to work more closely with dsss. I suppose I should ask what
 is the benefits to rebuild to bud? Was it Gregor's intent to fork bud as a
 competitor? And maybe what prevents bud from having that which is added to
 rebuild?


Well, here's the honest truth behind why rebuild exists. Some may find 
it offensive, but I assure you it's just brutally honest :)

I originally wrote DSSS to work with bu[il]d. The reason was simple: Why 
rock the boat? However, even the first revision of DSSS ended up needing 
a branch of bu[il]d, because it was broken on GDC.

OK, so I posted fixes, and the next version worked on GDC (sort of), but 
it was broken (as I recall) on DMD+GNU/Linux.

*sigh*, OK, fine. I kept my branch up to date while also having it 
changed enough to actually work everywhere. However, I also needed new 
features, like shared library support and cross-compilation support.

Two threads on bu[il]d's forum, both went nowhere fast.

At this point, I was spending far more time working /around/ bu[il]d 
than I was working /with/ bu[il]d. However, I persisted because I 
figured everybody used bu[il]d for a reason.

But then I started talking about it on IRC, and what did I discover? 
Nearly everyone I talked to who was either using GDC or trying to do 
anything more complex than .d file -> binary was unhappy with bu[il]d.

So, tired of munging with my branch, I abandoned it and wrote rebuild. I 
based rebuild on DMD's frontend because there was no D parser in D that 
worked well and was portable.

Rebuild supports shared object files, it supports cross-compilation. 
Also, it has the -oq option, which gives object files fully-qualified 
names. That's quite helpful for Posix ar-style libraries. Most of these 
features I added to meld it with DSSS, but they're certainly not useless 
in isolation.

In short: If you use bu[il]d and have never had any problem with it, 
there is no reason for you to switch to rebuild. Are they in 
competition? Yes, of course, that's the nature of similar software. But 
they serve the same function, and even do so in a similar way.

Again, with apologies to anyone this offends,

  - Gregor Richards
Apr 18 2007
prev sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Why not help DSSS instead of compete?
I really see no advantage in competition in a little community like this.
Apr 18 2007
next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Frank Benoit (keinfarbton) wrote:

 Why not help DSSS instead of compete?
 I really see no advantage in competition in a little community like this.


I second that request.
Apr 18 2007
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 18 Apr 2007 21:06:09 +0200, Frank Benoit (keinfarbton) wrote:


 Why not help DSSS instead of compete?
 I really see no advantage in competition in a little community like this.


I have no opinion about DSSS yet. I was talking specifically about Rebuild
only. 

But why compete, well why have GDC then? And in any case, Bud existed prior
to Rebuild so I guess it would be unusual for me to say "Somebody has
created another application that does the same task as mine so I better
stop working on mine now."

As Gregor has said, he started Rebuild because he, and others, were unhappy
that I couldn't meet their needs in the timeframe that was acceptable. I
believe this is reasonble justification for starting up a competitive
application.

A little healthly competition can, and probably will, provide the D
community with two or more excellent choices, each with a particular
feature set more suitable to one situation over another situation.

Bud is fairly mature and stable and Rebuild is getting that way quickly.
The D community will benefit from this. At the moment, Bud supports DMD
better than GDC and Rebuild is the other way round (I think). Bud is
written in D and Rebuild in C++, and that might be a relevent point of
differentiation for some users. Bud does not yet support Tango and Rebuild
does. etc ...

Should I stop working on Bud and begin helping Gregor improve Rebuild? I
don't think so. Not yet anyway.

As for DSSS, I'm still not sure of its purpose or capabilities. I guess it
is a tool to create installation packages, and that has to be a good thing.
As I come from a Windows background, I find it really weird that so many
Linux applications need to be be recompiled after installation.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Apr 18 2007
next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Derek Parnell schrieb:

 But why compete, well why have GDC then? And in any case, Bud existed prior
 to Rebuild so I guess it would be unusual for me to say "Somebody has
 created another application that does the same task as mine so I better
 stop working on mine now."


Sure, i can understand that.

I think it can be helpful if bud would integrate into DSSS, and the user
can choose via a DSSS configuration.

It would be really great (and REAL man like) if you both can cooperate
in this point. :)
Apr 18 2007
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 19 Apr 2007 00:47:48 +0200, Frank Benoit (keinfarbton) wrote:


 I think it can be helpful if bud would integrate into DSSS, and the user
 can choose via a DSSS configuration.


Yes, that makes a lot of sense.
-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
19/04/2007 9:38:05 AM
Apr 18 2007
prev sibling parent Gregor Richards <Richards codu.org> writes:
Frank Benoit (keinfarbton) wrote:

 Derek Parnell schrieb:

 But why compete, well why have GDC then? And in any case, Bud existed prior
 to Rebuild so I guess it would be unusual for me to say "Somebody has
 created another application that does the same task as mine so I better
 stop working on mine now."


 
 Sure, i can understand that.
 
 I think it can be helpful if bud would integrate into DSSS, and the user
 can choose via a DSSS configuration.
 
 It would be really great (and REAL man like) if you both can cooperate
 in this point. :)
 


Absolutely. I don't think it's good that DSSS depends absolutely on 
rebuild, with no alternative. But making it a bit more 
alternative-friendly hasn't been high on my priority list ^^

  - Gregor Richards

PS: Are you mocking my common misuse of the phrase "REAL men do 
<something real men don't do>"? :-P
Apr 18 2007
prev sibling parent Gregor Richards <Richards codu.org> writes:
Derek Parnell wrote:

 On Wed, 18 Apr 2007 21:06:09 +0200, Frank Benoit (keinfarbton) wrote:
 

 Why not help DSSS instead of compete?
 I really see no advantage in competition in a little community like this.


 
 I have no opinion about DSSS yet. I was talking specifically about Rebuild
 only. 
 
 But why compete, well why have GDC then? And in any case, Bud existed prior
 to Rebuild so I guess it would be unusual for me to say "Somebody has
 created another application that does the same task as mine so I better
 stop working on mine now."
 
 As Gregor has said, he started Rebuild because he, and others, were unhappy
 that I couldn't meet their needs in the timeframe that was acceptable. I
 believe this is reasonble justification for starting up a competitive
 application.
 
 A little healthly competition can, and probably will, provide the D
 community with two or more excellent choices, each with a particular
 feature set more suitable to one situation over another situation.
 
 Bud is fairly mature and stable and Rebuild is getting that way quickly.
 The D community will benefit from this. At the moment, Bud supports DMD
 better than GDC and Rebuild is the other way round (I think). Bud is
 written in D and Rebuild in C++, and that might be a relevent point of
 differentiation for some users. Bud does not yet support Tango and Rebuild
 does. etc ...
 
 Should I stop working on Bud and begin helping Gregor improve Rebuild? I
 don't think so. Not yet anyway.
 



Hear, hear!

  - Gregor Richards
Apr 18 2007
prev sibling parent dickl <dick221z yahoo.com> writes:
Derek Parnell wrote:

 On Mon, 16 Apr 2007 12:51:24 -0700, Gregor Richards wrote:
 

 Why use rebuild and not DSSS?


 
 Actually, there is (at least) one person that uses neither <G>
 


Add another person to the Bud/Build list.

I don't need anything more than a replacement for make. Bud plays nicely 
with the IDE's so I'm happy.

I look at the DSSS/Rebuild site now and again but I don't see anything 
that makes me what to change.

I'm glad to see Bud isn't dead.
Apr 18 2007
prev sibling next sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Gregor Richards wrote:
...

   - Gregor Richards


As others have said documentation is a bit lacking so I don't know what dsss
is capable of. 
Secondly (maybe as a result of the previous) I don't know the advantages of
dsss over make, particularly I'm not sure how to know what dsss actually
does when building and how to run custom shell code. (If there is
documentation I have not found pleas give a link)

ps. if my above concerns can be addressed I think the net install feature
can be a real boon in avoiding dependency hell. (ohh and does it suport
amd64?)
Apr 16 2007
prev sibling next sibling parent kenny <funisher gmail.com> writes:
Gregor Richards wrote:

 Judging by the amount of feedback I receive on rebuild, vs the amount of
 feedback I receive on DSSS, I'd say that 95% of rebuild users are not
 DSSS users. That is, there are more users who use rebuild alone than in
 tandem with DSSS. I could be wrong - maybe DSSS just has no bugs :).
 
 Rebuild was designed primarily to complement DSSS, and DSSS was designed
 to be the ideal replacement for 'make' and pals for D, so I find it a
 bit disconcerting that a tool I designed primarily to be a background
 tool is being used as a primary development tool by so many.
 
 So, the obvious question is: Why? Why use rebuild and not DSSS? I
 imagine there must be some misconceptions about DSSS, what it is, what
 it's for, et cetera.
 
 I imagine some common misconceptions are:
 
  * DSSS is intended solely to be D's answer to CPAN - that is, a network
 installation tool. This just isn't true, the net portion is only a small
 chunk of what DSSS can do.
 
  * DSSS provides no advantages over using just a build tool. Also not
 true - even if DSSS provided /only/ a convenient build configuration
 file format (dsss.conf), that would be a sizable advantage of rebuild.
 DSSS provides much more, however, including easy generation of libraries
 with associated .di files, installation, documentation, etc, etc. If you
 really want your rebuild profile for an application or library be
 portable, you would need to either have several Makefiles or response
 files wrapped around rebuild (nasty), or use DSSS (nice).
 
  * DSSS is not portable to Windows. I think most people know that I'm
 not a Windows user, and Windows is mostly a foreign environment to me.
 However, this is not true. I've done my best, and am very responsive to
 bug reports, and DSSS does indeed work on Windows just as well as it
 does on Posix systems.
 
  * `dsss` is hard to type. Well, I've typed it more than a dozen times
 in this post, and my left ring finger is in no particular pain :)
 
 If your concern or concept isn't noted here, please tell me / ask me! If
 DSSS /isn't/ everything you need it to be, help me /make/ it what you
 need it to be :).
 
  - Gregor Richards


I'll be honest. Your message suggested to me that I try dsss/rebuild again
cause it's never worked for me. I have been using a very old version of build
for a long time (like 6-9 months old). Today was the first day that
dsss/rebuild actually compiled for me. So, really I couldn't try it. I will try
it now though. If it can replace my seriously aging version of build, I'm
probably converted :)

Kenny
Apr 16 2007
prev sibling next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Today, after your posting i tried again to understand what is dsss. And
wow, it's cool. :)

But... please make more docu.

Some thoughts
* more Examples
* How platform independent is a dsss.conf (slash handling?)
* How can a package be combined from two source folders?
* Are there internal tools for platform independent cp/mv/find/..?
* Examples for extending the functionality with d progs using the dsss api.
* a tango version, that net installs only tango progs
* how to handle package deps and versions?
* is it possible to build file rules for non D files?

Is the focus of dsss really to be also a competitor to general build
tools like gnu-make or rake?
Apr 16 2007
parent reply Gregor Richards <Richards codu.org> writes:
Frank Benoit (keinfarbton) wrote:

 Today, after your posting i tried again to understand what is dsss. And
 wow, it's cool. :)
 
 But... please make more docu.
 
 Some thoughts
 * more Examples


Noted. Admittedly, the documentation is lacking of anything that I'd 
call an "example."


 * How platform independent is a dsss.conf (slash handling?)


I believe this is covered in README.software_engineers. dsss.conf 
includes the capability to use version statements.


 * How can a package be combined from two source folders?


Also in README.software_engineers, 'type = subdir'


 * Are there internal tools for platform independent cp/mv/find/..?


(Also in README.software_engineers) Just 'install', nothing equiv. of 
find. I'm not sure how that would help for compilation, but Idonno ...


 * Examples for extending the functionality with d progs using the dsss api.


Noted. Definitely lacking here.


 * a tango version, that net installs only tango progs


Well, this is on the docket ... it's a bit more difficult than I 
anticipated.


 * how to handle package deps and versions?


I suppose this isn't documented very well. For reference here, the 
central repository keeps track of what packages are assigned to what 
tools, so all you need to do is import.


 * is it possible to build file rules for non D files?


Also in README.software_engineers (sort of). This is accomplished by 
{pre,post}{build,install} commands calling make or equivalent.


 
 Is the focus of dsss really to be also a competitor to general build
 tools like gnu-make or rake?


No, DSSS is D-specific.

  - Gregor Richards
Apr 16 2007
next sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
 * How can a package be combined from two source folders?


 
 Also in README.software_engineers, 'type = subdir'
 


If I have a directory "gen" which contains generated source, and a
package "src" with manually written sources. Both contain the package
a.b, how can I use dsss to build the lib for "a.b" ?
Apr 17 2007
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Gregor Richards wrote:

 Frank Benoit (keinfarbton) wrote:

 Today, after your posting i tried again to understand what is dsss. And
 wow, it's cool. :)

 But... please make more docu.

 Some thoughts
 * more Examples


 
 Noted. Admittedly, the documentation is lacking of anything that I'd 
 call an "example."
 

 * How platform independent is a dsss.conf (slash handling?)


 
 I believe this is covered in README.software_engineers. dsss.conf 
 includes the capability to use version statements.
 

 * How can a package be combined from two source folders?


 
 Also in README.software_engineers, 'type = subdir'
 

 * Are there internal tools for platform independent cp/mv/find/..?


 
 (Also in README.software_engineers) Just 'install', nothing equiv. of 
 find. I'm not sure how that would help for compilation, but Idonno ...
 

 * Examples for extending the functionality with d progs using the dsss 
 api.


 
 Noted. Definitely lacking here.
 

 * a tango version, that net installs only tango progs


 
 Well, this is on the docket ... it's a bit more difficult than I 
 anticipated.
 

 * how to handle package deps and versions?


 
 I suppose this isn't documented very well. For reference here, the 
 central repository keeps track of what packages are assigned to what 
 tools, so all you need to do is import.
 

 * is it possible to build file rules for non D files?


 
 Also in README.software_engineers (sort of). This is accomplished by 
 {pre,post}{build,install} commands calling make or equivalent.
 

 Is the focus of dsss really to be also a competitor to general build
 tools like gnu-make or rake?


 
 No, DSSS is D-specific.
 
  - Gregor Richards


I'd suggest starting up an FAQ page based off of these questions and 
others that you get in response.

PS: I second the request for enhanced documentation/examples.
Apr 17 2007
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
I'm using Rebuild as I needed a Bud replacement as the latter is borked on
amd64. I've failed to compile dsss last time I tried and not really knowing
what I could actually use it for, I haven't spent any time getting it to
work.
Apr 16 2007
parent Gregor Richards <Richards codu.org> writes:
Tomas Lindquist Olsen wrote:

 I'm using Rebuild as I needed a Bud replacement as the latter is borked on
 amd64. I've failed to compile dsss last time I tried and not really knowing
 what I could actually use it for, I haven't spent any time getting it to
 work.


The DSSS fix for x86_64 was fairly recent ... if you have problems, 
please post bug reports :)

  - Gregor Richards
Apr 16 2007
prev sibling next sibling parent Dan <murpsoft hotmail.com> writes:
- not a user

I thought using a makefile was excessive until I started writing programs over
8,000 lines of code.
Apr 16 2007
prev sibling next sibling parent Gregor Richards <Richards codu.org> writes:
Wowsa! I wasn't expecting such exuberant reponse!

The primary complaint of everyone is lack of documentation. DSSS' 
documentation is admittedly sparse, but far from non-existent. I realize 
now that the documentation is not in the installation binaries, which 
was a bit of a mistake on my part, so for reference: What documentation 
I've written is at 
http://www.dsource.org/projects/dsss/browser/trunk/docs . I will try to 
get that linked in more visibly. Since most of the complaints about 
documentation were that it was completely non-existent, I can't really 
expand on the documentation there is very much. If you tell me specific 
weak points, overly-sparse areas or just plain confusing wording, I can 
improve upon it.

I will further reply in individual subthreads.

  - Gregor Richards
Apr 16 2007
prev sibling next sibling parent Olli Aalto <oaalto gmail.com> writes:
I use DSSS primarily and only fallback to Rebuild if there's a problem 
with DSSS.

O.
Apr 17 2007
prev sibling next sibling parent reply David Ferenczi <raggae ferenczi.net> writes:
I started to use rebuild as a bud replacement, and I didn't even considered
using dsss, since rebuild fully satisfied my needs.

It's just a lightweight tool for playing around with D, and combining it
with GNU make gave me quick results for compiling different configurations.

But maybe it's high-time to give dsss a try. :-)

Many thanks for the great tools!

Regards,
David
Apr 17 2007
parent Dan <murpsoft hotmail.com> writes:
David Ferenczi Wrote:

 It's just a lightweight tool for playing around with D, and combining it
 with GNU make gave me quick results for compiling different configurations.


Indeed; my philosophy with software is that, given choice of several packages
that perform much the same function, the simplest package is my first pick.

I would much rather simply perform a dmd -release -O [files] than anything
else, unless I *need* a build/make file; and then I want the simplest of them.
Apr 17 2007
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
I use neither successfully yet.

Where does rebuild look for files?  I'm getting errors to the effect of 
"can't find std/XXXX.d".  I tried copying dmd/src/phobos to /include/d, 
but that didn't work.  I've tried looking at the config files and didn't 
find an obvious place to change.
Apr 17 2007
next sibling parent David Ferenczi <raggae ferenczi.net> writes:
Jason House wrote:


 I use neither successfully yet.
 
 Where does rebuild look for files?  I'm getting errors to the effect of
 "can't find std/XXXX.d".  I tried copying dmd/src/phobos to /include/d,
 but that didn't work.  I've tried looking at the config files and didn't
 find an obvious place to change.


Something like this might help:

-I/opt/dmd/1.005/src/phobos
Apr 17 2007
prev sibling parent Gregor Richards <Richards codu.org> writes:
Jason House wrote:

 I use neither successfully yet.
 
 Where does rebuild look for files?  I'm getting errors to the effect of 
 "can't find std/XXXX.d".  I tried copying dmd/src/phobos to /include/d, 
 but that didn't work.  I've tried looking at the config files and didn't 
 find an obvious place to change.


It checks your dmd.conf or gdc configuration as appropriate. If it's not 
getting the proper values, it's either not finding dmd/gdc or not 
finding the right one. If none of the above applies, there's always a 
ticket system :)

  - Gregor Richards
Apr 18 2007
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
For me, I use neither.

Mainly because I don't understand what's the purpose of DSSS.
I read the feature list .. and it still doesn't answer my question.

What problem is it trying to solve? In other words: why do I need to use it?

The original build satisfied my needs pretty well, honestly all I ever 
do with my small programs is "build main.d -full -clean"

Plus, I haven't been using D very much lately ...
Apr 17 2007
parent Jesse Phillips <Jesse.K.Phillips+Digitalmars gmail.com> writes:
On Tue, 17 Apr 2007 23:26:15 -0600, Hasan Aljudy wrote:


 For me, I use neither.
 
 Mainly because I don't understand what's the purpose of DSSS.
 I read the feature list .. and it still doesn't answer my question.
 
 What problem is it trying to solve? In other words: why do I need to use it?
 
 The original build satisfied my needs pretty well, honestly all I ever 
 do with my small programs is "build main.d -full -clean"
 
 Plus, I haven't been using D very much lately ...


I'd say that DSSS is trying to be a software distribution manager.
Allowing developers to set up installation of programs written for D to be
compiled and installed using a simple call to DSSS. I will admit that it
is still not as straight forward as most desktop user are use to, but for
those used to the Linux way of things, its simple.

I do have yet to have a flawless net install though. Once I have a better
idea what is causing the problem I'll look into reporting it, but my guess
it that it's not on DSSS's end.
Apr 18 2007
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Since many of the responses to this thread suggested that people don't 
understand why DSSS is useful above just a build tool like bud or 
rebuild. I've created a basic DSSS-by-example page, to describe why DSSS 
is useful, and what advantages it gives the user. It needs more work, 
but is a good start.

http://www.dsource.org/projects/dsss/wiki/DSSSByExample

  - Gregor Richards
Apr 19 2007
next sibling parent "Anders Bergh" <anders1 gmail.com> writes:
Thanks, I've been looking for something like that. I didn't quite
'get' DSSS, but I do use rebuild as a bud replacement. I should
probably use DSSS for my new Lua bindings, so they are net
installable.

On 4/19/07, Gregor Richards <Richards codu.org> wrote:

 Since many of the responses to this thread suggested that people don't
 understand why DSSS is useful above just a build tool like bud or
 rebuild. I've created a basic DSSS-by-example page, to describe why DSSS
 is useful, and what advantages it gives the user. It needs more work,
 but is a good start.

 http://www.dsource.org/projects/dsss/wiki/DSSSByExample

   - Gregor Richards



-- 
Anders
Apr 19 2007
prev sibling next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Gregor Richards wrote:


 Since many of the responses to this thread suggested that people don't
 understand why DSSS is useful above just a build tool like bud or
 rebuild. I've created a basic DSSS-by-example page, to describe why DSSS
 is useful, and what advantages it gives the user. It needs more work,
 but is a good start.
 
 http://www.dsource.org/projects/dsss/wiki/DSSSByExample
 
   - Gregor Richards


Thanks this documentation cleared up a lot of things.

I have a few questions thou, either this was not documented or I could not
find it. Overall dsss was much more compleat than I thought.

1.
how is libs with subdirs handled?

//example directory structure
mylib/
        lib.d
        file.d
        subdir/
                somefile.d
                someother.d
        anotherdir/
                anotherfile.d

If building a .a library will the files in the subdirs be compiled, and if
so when are they included?
(if I don't import them with a version flag?)

2.
Where does dsss net deps install the deps, 
current dir or globally, (configurable)?

3.
The pre/post instal/uninstal/clean are they target specific or common to the
entire file.

4.
Is it possible to build a specific target from a file instead of all of them
(as if specifying make targetname).

5.
How is library dependencies specified in the dsss file.

Thanks in advance.
Apr 19 2007
parent reply Gregor Richards <Richards codu.org> writes:
Answers posted inline. I will use some of these questions for a FAQ when 
I make one.

Johan Granberg wrote:

 Gregor Richards wrote:
 

 Since many of the responses to this thread suggested that people don't
 understand why DSSS is useful above just a build tool like bud or
 rebuild. I've created a basic DSSS-by-example page, to describe why DSSS
 is useful, and what advantages it gives the user. It needs more work,
 but is a good start.

 http://www.dsource.org/projects/dsss/wiki/DSSSByExample

   - Gregor Richards


 
 Thanks this documentation cleared up a lot of things.
 
 I have a few questions thou, either this was not documented or I could not
 find it. Overall dsss was much more compleat than I thought.
 
 1.
 how is libs with subdirs handled?
 
 //example directory structure
 mylib/
         lib.d
         file.d
         subdir/
                 somefile.d
                 someother.d
         anotherdir/
                 anotherfile.d
 
 If building a .a library will the files in the subdirs be compiled, and if
 so when are they included?
 (if I don't import them with a version flag?)


I've improved README.software_engineers to answer this question:

Sections creating libraries from directories will normally include all 
the .d
files in that directory or any subdirectory of it. You may also specify
subdirectories explicitly in dsss.conf, which will cause some .d files to be
reassigned. For example, if you have these files:
dzip/algorithm.d, foo/compression/zip.d
and a section:
[dzip]
then the produced library will include algorithm.d and zip.d.
If you have two sections:
[dzip]
[dzip/compression]
then two libraries will be produced: The library from 'dzip' will contain
algorithm.d, and the library from [dzip/compression] will contain zip.d.


 
 2.
 Where does dsss net deps install the deps, 
 current dir or globally, (configurable)?


 From README.use:

Some software can be used directly after building, but most software, 
libraries
in particular, expect to be installed somewhere. DSSS can install 
software to
any directory you choose, but will default to its own directory.



 
 3.
 The pre/post instal/uninstal/clean are they target specific or common to the
 entire file.


I've made this a bit more explicit in README.software_engineers (I hope 
:) ):

* prebuild, preinstall, preclean, postbuild, postinstall, postclean
   * Commands to be run before/after building/installing/cleaning the 
current
     section.


 
 4.
 Is it possible to build a specific target from a file instead of all of them
 (as if specifying make targetname).


I had neglected to mention this in README.use. It is now present:

You can build only a specified target by simply adding it to the command 
line:
$ dsss build dzipper



 
 5.
 How is library dependencies specified in the dsss file.


In general, they're not. Every package installable via DSSS-net has its 
list of modules well-defined, so `dsss net deps` merely needs to trace 
dependencies. I've made this explicit in README.software_engineers:

There is also a global setting, "requires", which may be used to explicitly
list dependencies:
requires = bintod
In general, it is NOT necessary to use this setting, as DSSS will detect
dependencies based on what is imported from the D source.

  - Gregor Richards
Apr 19 2007
parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Gregor Richards wrote:

 
 5.
 How is library dependencies specified in the dsss file.


 
 In general, they're not. Every package installable via DSSS-net has its
 list of modules well-defined, so `dsss net deps` merely needs to trace
 dependencies. I've made this explicit in README.software_engineers:
 
 There is also a global setting, "requires", which may be used to
 explicitly list dependencies:
 requires = bintod
 In general, it is NOT necessary to use this setting, as DSSS will detect
 dependencies based on what is imported from the D source.
 
   - Gregor Richards


I'm still not clear on how does this work with external c libraries?

Otherwise your answers made it a lot clearer. If it continues like this dsss
will have great documentation in no time :)
Apr 19 2007
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Gregor Richards wrote:

 Since many of the responses to this thread suggested that people don't
 understand why DSSS is useful above just a build tool like bud or
 rebuild. I've created a basic DSSS-by-example page, to describe why DSSS
 is useful, and what advantages it gives the user. It needs more work,
 but is a good start.
 
 http://www.dsource.org/projects/dsss/wiki/DSSSByExample
 
  - Gregor Richards


OK, I think I've got a clearer idea of what DSSS is for now, although I
have a few questions:

1. What exactly does 'dsss install' do on Windows?  I mean, I realise
that linux has standard directories for libraries and binaries, but
where does it stick these things for Windows?

2. In addition, does 'dsss build' build everything all at once?  If so,
is there any way to specify that you only want a particular target built?

3. I use an awful lot of version statements to control tracing code,
experimental code, etc.  Can I pass version flags to the compiler from
the command line (I know about buildflags in the dsss.conf file, but I
don't want to have to edit that just to add some tracing code for a
quick run).

4. I also noticed the bit on special build steps prefixed by a '+': do
you trigger these from the command line like so: 'dsss build +foo'?

5. Related to the above, is there any way to add one of these special
build steps from another one (ie: chain them together)?

6. I realise this isn't in DSSS' job description, but do you have any
plans to add support for transforming files?  The major part of my work
at the moment deals with source files that need to be pre-processed
before being fed to the D compiler.  Having a build tool able to call
the processor on-demand only when it's needed would be a *massive*
help--about 80-90% of the current build time is just my crummy shell
script checking to make sure no source files need to be processed...

7. Can we Windows users get a list of what command-line programs DSSS
depends on?  I don't think I ever finished tracking down all the
utilities DSSS kept trying to call last time I tried to use it...

DSSS is actually looking pretty close to what I'm rigging up with bud at
the moment.  Plus, the whole net install thing is cool :P

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Apr 19 2007
parent Gregor Richards <Richards codu.org> writes:
Answers posted inline. I will use some of these questions for a FAQ when 
I make one.

These questions are bizarrely similar to Johan's ... :)

Daniel Keep wrote:

 Gregor Richards wrote:

 Since many of the responses to this thread suggested that people don't
 understand why DSSS is useful above just a build tool like bud or
 rebuild. I've created a basic DSSS-by-example page, to describe why DSSS
 is useful, and what advantages it gives the user. It needs more work,
 but is a good start.

 http://www.dsource.org/projects/dsss/wiki/DSSSByExample

  - Gregor Richards


 
 OK, I think I've got a clearer idea of what DSSS is for now, although I
 have a few questions:
 
 1. What exactly does 'dsss install' do on Windows?  I mean, I realise
 that linux has standard directories for libraries and binaries, but
 where does it stick these things for Windows?


 From README.use:

Some software can be used directly after building, but most software, 
libraries
in particular, expect to be installed somewhere. DSSS can install 
software to
any directory you choose, but will default to its own directory.



 
 2. In addition, does 'dsss build' build everything all at once?  If so,
 is there any way to specify that you only want a particular target built?


Added to README.use:

You can build only a specified target by simply adding it to the command 
line:
$ dsss build dzipper



 
 3. I use an awful lot of version statements to control tracing code,
 experimental code, etc.  Can I pass version flags to the compiler from
 the command line (I know about buildflags in the dsss.conf file, but I
 don't want to have to edit that just to add some tracing code for a
 quick run).


 From `dsss --help` (admittedly not the best place for it :) ):

All other options are passed through to rebuild and ultimately the compiler.

So just adding -version=Foo is sufficient.


 
 4. I also noticed the bit on special build steps prefixed by a '+': do
 you trigger these from the command line like so: 'dsss build +foo'?


Yes.



 
 5. Related to the above, is there any way to add one of these special
 build steps from another one (ie: chain them together)?


There is not at present any way of specifying such a dependency, no. 
Perhaps I should add that...



 
 6. I realise this isn't in DSSS' job description, but do you have any
 plans to add support for transforming files?  The major part of my work
 at the moment deals with source files that need to be pre-processed
 before being fed to the D compiler.  Having a build tool able to call
 the processor on-demand only when it's needed would be a *massive*
 help--about 80-90% of the current build time is just my crummy shell
 script checking to make sure no source files need to be processed...


I'm a bit loathe to add anything like this ... I'd recommend setting it 
up something like this:

A non-preprocessed source directory, which creates a preprocessed source 
directory. The preprocessed source directory will have an appropriate 
dsss.conf added to it. In the base dsss.conf:

[+preprocess]
prebuild = preprocess.d

[preprocessed]
type = subdir



 
 7. Can we Windows users get a list of what command-line programs DSSS
 depends on?  I don't think I ever finished tracking down all the
 utilities DSSS kept trying to call last time I tried to use it...


All the software DSSS depends on come in the DSSS binary tarball (I 
missed this in one release, but it should be in all the current ones), 
and are retrievable by running getwinbins.d (which is run automatically 
if you build dsss with itself).


 
 DSSS is actually looking pretty close to what I'm rigging up with bud at
 the moment.  Plus, the whole net install thing is cool :P
 
 	-- Daniel
 


  - Gregor Richards
Apr 19 2007