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

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 ...

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.

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

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.

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

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

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.

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

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. :)