John Reimer wrote: > Hello tim, > >> On Sun, 04 Jan 2009 01:40:03 +1300, John Reimer >> <terminal.n...@gmail.com> wrote: >> >>> Hello Don, >>> >>>> Tim M wrote: >>>> >>>>> On Sat, 03 Jan 2009 08:17:17 +1300, Michael P. >>>>> <baseball....@gmail.com> wrote: >>>>>> Okay, so right now, I'm making a small game(Mario) using DAllegro. >>>>>> I >>>>>> use build, and every time, I have to type this in to compile my >>>>>> progress: >>>>>> build mario alleg.lib >>>>>> Now, I know it's not a lot of typing. But considering I type mario >>>>>> wrong every so often, and I generally want to execute it after, >>>>>> assuming there is not compiler errors, it takes time. >>>>>> In a .bat file right now, I have this: >>>>>> build mario alleg.lib >>>>>> mario >>>>>> But, mario will execute even if there are errors found by dmd. >>>>>> Is there anything that I can use to see if errors were found, and >>>>>> if >>>>>> there isn't, execute it, and if there is, don't execute it? >>>>>> DMD1.036, Windows XP, Build/Bud 3.04 >>>>> I thought everyone used dsss with d now. >>>>> http://dsource.org/projects/dsss. >>>> No way! On Windows, bud is much better. dsss can't build dlls, for >>>> example, which is a blocker for me. It also seems to be based around >>>> the flawed concept that you have a small number of build >>>> configurations. >>>> >>> Yes, I think bud is still quite good on windows (and faster than >>> dsss), even though I don't use it. But there's no replacing dsss on >>> linux at the moment. It's nice to have the cross-platform option of >>> dsss on win32 too. >>> >>> That said, if bud worked (easily) on linux, I might actually go back >>> to using it again, since dsss doesn't seem to be going anywhere and >>> recent releases have been getting slower and bulkier (possibly due >>> to the combined effect of recent dmd releases). :-( >>> >>> -JJR >>> >> Could you both explain a bit more about this as dsss says it is based >> on rebuild and rebuild is based on bud. So I though that dsss > >> rebuild > bud. >> > > > Here's a little history: > > Bud (aka build) is a utility originally developed and still (I think) > maintained > by Derek Parnell. Derek developed it (now probably beyond original > recognition) > from a tiny tool called dmake (see > http://prowiki.org/wiki4d/wiki.cgi?Dmake) that was offered to the > community around 2004 by Helmut Leitner (who doesn't appear to hang around > D much anymore even though he seems to still maintain the wiki4d site). > > dmake, in turn, borrowed significantly from Burton Radons' D tool called > 'digc,' which was originally part of the very first significant D GUI > project > called dig (see http://www.opend.org/dig/index.html). This was way back > circa 2003, I think. Burton, a prolific and guru-class D programmer (who > has had a fair bit of influence on the D language itself), still pops in > here now and again just to unsettle things with his clever D creations > that he apparently still works on in secret. :) > > Bud expanded the original dmake with many more options. A port to linux > was also created, but it never caught on very well, I think partly because > Derek was not keen on Linux development. Anyway, build was always > problematic on linux, such that it is now mostly recoginized for its very > good win32 platform capabilites. > > DSSS appeared when Gregor Richards came into the D scene. Basically, when > Gregor came here, he brought with him experience developing a universal > package system for linux distributions (among other things) see > http://oblisk.codu.org. > Gregor was (and is) another one of those gifted and prolific development > gurus that D tends to attract. Many of us had been discussing how much D > needed improved build facilities for multiple platforms. Something seemed > to click and in 2006, Gregor had released an early version of dsss which > was basically a somewhat independent perspective on a "build/bud" tool but > with a much broader purpose than just building software. It was a net > installer, > a source builder, and a package manager (almost) all in one. The only > major > thing lacking was package version control. But he added some very simple > but ingenious naming conventions for D object files and libraries that now > should be considered mandatory for all D development. > > The major difference with dsss that made it such a contrast from Derek's > build was that the underlying "rebuild" tool made use of the whole Dmd > frontend > in order to parse source files accurately for dependencies. Despite the > double overhead, dsss still managed to be fast (at least during the early > versions), but obviously not as fast as "build" which resorted to very > simple > parsing techniques for import statements. There certainly were advantages > and disadvanatages to this approach. However, build's simplicity has > actually caused it's attraction to grow again, as the contrast of dsss's > complexity > begins to show the benefits of a lighter design. Future versions of dsss, > I think, were going to adopt a different design approach as a result of > this. > > Later revisions added more and more great features (nothing that > particularly weighed down it's rebuild component), including excellent > support for both windows and linux, multiple compiler configurations, > multiple "standard" > library configurations (basically extreme customizability). It pretty > much > became the defacto standard build tool for D. Since then, the project has > began to languish for various reasons, some related to the author's > business with school and others relating to interaction difficulties with > the dmd > compiler technology. There were problems with the dmd compile system that > forced Gregor to make the dsss build process much slower (see oneatatime > compile option) in the interest of stability. Nonetheless, version 0.75 > still > seems to be the best version to use as of now. More recent versions seem > to be unbearably slow due to the effect of recent frontend dmd code. > > There is still tremendous potential to improve these tools, but I think > we're just waiting for the next wave of inspiration to fall on someone > here. :) > > Probably more history here than you, but it was kind of fun looking back > on it. If anyone sees some inaccurancies, be sure to correct. > > -JJR
Sometimes people post interesting tidbits fit for the wiki in here ;)