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
