.bat file to help compile easier - dmd/build

John Reimer terminal.node at gmail.com
Sat Jan 3 19:47:31 PST 2009


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




More information about the Digitalmars-d-learn mailing list