.bat file to help compile easier - dmd/build

[Lutger]

John Reimer wrote:

> Hello tim,
> 
>> On Sun, 04 Jan 2009 01:40:03 +1300, John Reimer
>> <terminal.node at gmail.com>  wrote:
>> 
>>> Hello Don,
>>> 
>>>> Tim M wrote:
>>>> 
>>>>> On Sat, 03 Jan 2009 08:17:17 +1300, Michael P.
>>>>> <baseball.mjp at 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 ;)