Running unittests in a D library
Hey all,
I'm sure that this is a rather daft question but I've tried to
search the d.learn mailing list and must have missed a question
about it.
I've read the unit testing documentation on dlang.org and I know
that `unittest { /* some code */ }` blocks are compiled into the
executable and executed after static initialization and before
the main() function is called. This makes sense in an application
but how does this apply to a library?
For example, writing a D library using DMD's `-lib` compiler
flag, how do I run the unit tests in the generated library?
Cheers,
Chris
Re: Running unittests in a D library
Actually after more digging it seems that unit testing libraries
in D doesn't work.
It seems pretty bad that in 2012 with unit testing a huge part of
the software development process and D describing itself as a
language with unit testing built in, this bug report / feature
request hasn't been addressed:
http://d.puremagic.com/issues/show_bug.cgi?id=4669
Is there any update on the status of this enhancement? Is there a
recommended workaround to unit test a D library?
Cheers,
Chris
On Wednesday, 19 September 2012 at 18:49:12 UTC, Chris Molozian
wrote:
Hey all,
I'm sure that this is a rather daft question but I've tried to
search the d.learn mailing list and must have missed a question
about it.
I've read the unit testing documentation on dlang.org and I
know that `unittest { /* some code */ }` blocks are compiled
into the executable and executed after static initialization
and before the main() function is called. This makes sense in
an application but how does this apply to a library?
For example, writing a D library using DMD's `-lib` compiler
flag, how do I run the unit tests in the generated library?
Cheers,
Chris
Re: Auto tools and D
Perhaps give Jam (http://www.freetype.org/jam/index.html) a try, it's
got builds for almost every platform and works well for me. I use this
Jamfile for most D projects:
# Requires the Jam (ftjam) build tool (http://www.freetype.org/jam/)
ALL_LOCATE_TARGET = build ;
SubDir TOP ;
# auxiliary rules to support building D code with perforce Jam
rule UserObject {
switch $(:S) {
case .d : Dc $() : $() ;
case * :
Exit Unknown suffix on $() - see UserObject rule in
Jambase. ;
}
}
rule Dc {
Depends $() : $() ;
DCFLAGS on $() += $(DCFLAGS) $(SUBDIRDCFLAGS) ;
}
actions Dc {
$(DC) -c -of$() $(DCFLAGS) $(DOPTIM) $()
}
# override the Link action to correct for the dmd compiler -o flag
actions Link bind NEEDLIBS {
$(LINK) $(LINKFLAGS) -of$() $(UNDEFS) $() $(NEEDLIBS) $(LINKLIBS)
}
DC = dmd ;
DCFLAGS = -fPIC -O -inline -release -w -wi -I./src/ ;
LINK = $(DC) ;
DFILES = [ GLOB src : *.d ] ;
MainFromObjects myprogam : $(DFILES:S=.o) ;
Objects $(DFILES) ;
Hope this helps,
Chris
On 09/11/11 17:28, Russel Winder wrote:
Steve,
On Sun, 2011-09-11 at 12:37 +, Steve Teale wrote:
Russel,
Thanks for the tips - I shall try SCons.
Steve
SCons 2.1.0 just came out, though I have to admit I use Mercurial tip.
The DMD tool that comes as standard with SCons is not really sufficient
to the task. I have a friendly fork of this at
https://bitbucket.org/russel/scons_dmd_new. The idea had been to create
a patch to merge into SCons core just before each release, but I failed
this time :-(
If you find any issues feel free to hassle me and or email the folk on
the SCons user list.
Re: Article about problems suggestions for D 2.0
Hope this works. Just click this link: Ingrater%u2019s 3D Blog ï¿1/2 Suggestions for the D 2.0 Programming Language http://3d.benjamin-thaut.de/?p=18 Sent from Readability http://lab.arc90.com/experiments/readability/ | An Arc90 http://www.arc90.com lab experiment On 08/27/11 18:39, Walter Bright wrote: On 8/27/2011 10:16 AM, Benjamin Thaut wrote: After having used the D 2.0 programming language for a year now and having completed 3 projects with it, I wrote a small article about the problems I had with the D 2.0 programming language and what suggestions I have to improve it. http://3d.benjamin-thaut.de/?p=18 Comments and criticism welcome I find it very hard to read. Can you boost the font size, please? Have pity on us old guys!
Re: event based timer
As you're creating a Gtk app, have you considered using glib.Timer http://gtkd.mikewey.eu/src/glib/Timer.html or glib.Timeout http://gtkd.mikewey.eu/src/glib/Timeout.html (depending on your needs)? I do almost all my Gtk development in Vala these days, so I haven't used them from D (so not sure if you've encountered problems with them). Cheers, Chris On 07/20/11 10:20, maarten van damme wrote: Thanks a lot, now those errors are gone. Still it refuses to work properly... I have a method clockTick in Main.d and that should be called every 0.1 seconds, when I place a call to that method in a onmousenotify event(when the mouse moves) It runs correctly apart from the odd fact I need to move my mouse to play the game. When I use that method in the timerclass it reaches only the lines where I print something in the console but doesn't go any further without giving any errors. The complete code can be seen at: http://dl.dropbox.com/u/15024434/d/Main.d http://dl.dropbox.com/u/15024434/d/Timer.d http://dl.dropbox.com/u/15024434/d/Sprite.d http://dl.dropbox.com/u/15024434/d/Bain.d http://dl.dropbox.com/u/15024434/d/PingPongBox.d The code for the timer in Main.d is at line 63 clockTick method in Main.d is at line 93 2011/7/20 Daniel Murphy yebbl...@nospamgmail.com mailto:yebbl...@nospamgmail.com private void function() * callBack; should be private void function() callBack; void function() is a function pointer, void function()* is a pointer to a function pointer. On lines 23 and 41, you shouldn't be dereferencing callBack. Just use callBack() to call the function and 'this.callBack = callBack' to set it.
Re: event based timer
Yes, Gtk is built using GLib and so depends on it. Here's some example
code I'm using in a Vala project (sorry) that uses GLib.Timeout:
public class TimeoutEntry : Granite.Entry, Gtk.Buildable {
private static const uint DEFAULT_TIMEOUT = 300; // in ms
/**
* The timeout length in milliseconds before {@see #timed_out} signal
* is called. The value defaults to 300.
*/
public uint timeout { get; set; default = DEFAULT_TIMEOUT; }
/**
* A callback fired after {@see timeout} length of time has expired in the
* non-empty entry field.
*/
public signal void timed_out();
private bool timeout_changed = false;
construct {
// add signals and callbacks
notify[timeout].connect(() = { timeout_changed = false; });
realize.connect(() = { GLib.Timeout.add(timeout, emit_timed_out); });
changed.connect(() = { timeout_changed = true; }); // reset timeout
}
private bool emit_timed_out() {
if (timeout_changed) {
GLib.Timeout.add(timeout, emit_timed_out);
return (timeout_changed = false);
}
if (text != ) { timed_out(); }
return !timeout_changed;
}
}
Here I'm calling the timed_out signal which will execute an associated
callback. I'm not sure what you mean by trigger a gtk event on a
timer, if I understand it correctly this should be helpful
gobject.Signals.emitv http://gtkd.mikewey.eu/src/gobject/Signals.html
and have a look here:
http://stackoverflow.com/questions/1557025/create-and-emit-gtk-signal
Hope this helps,
Chris
PS: the problems you're encountering seem less and less like problems
with D (unless they're compiler bugs)... and more like issues with
Gtk/GLib. The GTK IRC channel can be very (very) quiet but it might help.
On 07/20/11 14:34, maarten van damme wrote:
It turned out there was a Timer in glib and glib is a part of gtk(I
think). When you use gtkd you have acces to glib and that worked but
it takes 50 procent of my cpu. (this was actually pretty strange. It
worked fast and good untill I rebooted. Now it runs prety slow)
and I don't think you can trigger a gtk event on a timer.
2011/7/20 Sean Kelly s...@invisibleduck.org
mailto:s...@invisibleduck.org
Is there a timer function built into gtk? Or can you have a
separate thread trigger a gtk event on a timer?
On Jul 20, 2011, at 5:00 AM, maarten van damme wrote:
The problem with Sean Kelly's and the message sending approach
is that when using gtk I have to call Main.run(); and it pauses
then untill the windows are all closed. when I place a loop before
Main.run() I never get a window so If I want to use some kind of
timer using threads I need to use shared? (correct me if I'm wrong)
The glib.Timeout works like a charm, Thank you chris
2011/7/20 Sean Kelly s...@invisibleduck.org
mailto:s...@invisibleduck.org
On Jul 19, 2011, at 3:19 AM, maarten van damme wrote:
Hi everyone,
for getting to know d a little bit I'm writing a simple
pingpong game using gtk.
for it to work I need to be able to do something every 0.1
seconds so I was wondering if there was some kind of timer in the
phobos library.
I've looked everywhere but couldn't find one. Is it missing
and do i have to write my own or have I overlooked it?
void loop() {
while( true ) {
doWhatever();
Thread.sleep(dur!msecs(100));
}
}
spawn(loop);
Or you could have the spawned thread send a message every 100
milliseconds, etc.
Re: Prototype buildsystem Drake
I asked about build tools for D on the mailing list a while ago. I
needed a solution that allowed me to mix C++ and D builds in a
cross-platform way with minimum fuss. You can find the discussion about
it here
http://www.digitalmars.com/d/archives/digitalmars/D/Best_build_tool_for_D_projects_136103.html
(you were also a part of it IIRC). My biggest requirement at the time was:
* Keeping platform checks e.g. IF (MAC) {} ELSE IF(LINUX) {} ... etc.
to an absolute minimum. What's the point in a cross-platform
language if when you build projects in it you need to write a short
essay for the build system...
* Pre-built binaries available to all platforms (or as many as possible).
In the end I settled for Jam (ftjam)
http://www.freetype.org/jam/index.html, it works tremendously well.
It's easy to get binaries for almost any operating system (especially
with projects like homebrew http://mxcl.github.com/homebrew/ for Mac).
I have very few gripes with it:
* The build description language is very simple (once you fully grok
it), but could have done with a lot more example-based documentation.
* It's missing a few features like recursive-directory scanning (for
source files), and the ability to pipe the output from a program
into a variable in the build script (e.g. C++FLAGS = `llvm-config
--cxxflags`).
* A convenient way to force all generated object and library files
into a dedicated build folder. It's possible but not very easy to do.
* I'm a big fan of convention over configuration, I know it's a very
subjective topic but I like the way Maven3 and Gradle assume a
project structure (that you can deviate from if you need to). This
usually requires very good supporting documentation.
The build script I put together for my project looked like this,
http://mysticpaste.com/private/TCcTE6KGxn .
Hope this helps,
Chris
On 07/13/11 02:02, Nick Sabalausky wrote:
The recent discussions about package managers and buildsystems has prompted
me to get off my ass (or rather, *on* my ass as per how programming is
usually performed...) and start on the D-based rake-inspired buildtool I've
been meaning to make for awhile now. It's not actually usable yet, but
there's a sample drakefile demonstrating everything, and it does actually
compile and run (but just doesn't build the dependency tree or actually run
any of the build steps). *Should* work on Posix, but I only tested on
Windows, so I may have fucked up the Posix version...
Apologies to Jacob Carlborg for the name being so close to dake. Didn't
really know what else to call it (Duck, maybe?) Like dake, it's inspired
by Ruby's Rake. But unlike dake, the buildscript is written in D instead of
Ruby, which was my #1 reason for making a Rake alternative.
Before I go implemeting everything, I'd like to get input on it. Is it
something that could be a major D tool?
Overview of Drake and links to all the code are here:
https://bitbucket.org/Abscissa256/drake/wiki/Home
Re: Prototype buildsystem Drake
I'm glad the feedback helped, this may be of use to help in abstracting
away platform specific configuration:
http://public.perforce.com/public/jam/src/Jambase
Cheers,
Chris
On 07/13/11 19:31, Nick Sabalausky wrote:
Chris Molozianch...@cmoz.me wrote in message
news:mailman.1595.1310554903.14074.digitalmar...@puremagic.com...
I asked about build tools for D on the mailing list a while ago. I
needed a solution that allowed me to mix C++ and D builds in a
cross-platform way with minimum fuss. You can find the discussion about
it here
http://www.digitalmars.com/d/archives/digitalmars/D/Best_build_tool_for_D_projects_136103.html
(you were also a part of it IIRC). My biggest requirement at the time was:
* Keeping platform checks e.g. IF (MAC) {} ELSE IF(LINUX) {} ... etc.
to an absolute minimum. What's the point in a cross-platform
language if when you build projects in it you need to write a short
essay for the build system...
FWIW, my Drake system takes that as a high priority, too. For example, if
you have project foo, then you can get the cross-platform binary filename,
object filename, shared lib filename, static lib filename, etc like this:
foo.exe // foo.exe or foo
foo.obj // foo.obj or foo.o
foo.lib // foo.lib or foo.a
foo.slib // foo.dll or foo.so
foo.bat // foo.bat or foo
foo.sh // foo.bat or foo.sh
And new ones are easy to define:
I also intend to make sure that invoking ./blah works on Windows.
* Pre-built binaries available to all platforms (or as many as possible).
With Drake, the only pre-built binaries that are needed are DMD. The drake
command itself is a trivial one-line shell/batch script that invokes RDMD to
build+run the drakefile (which imports the rest of drake).
Of course, something still needs to be done to set up the DRAKE env var to
point to the Drake directory (or at least do something to get the path to
Drake into the -I arg sent to RDMD...) Not entirely sure how I want to do
that, although I think I have one idea.
In the end I settled for Jam (ftjam)
http://www.freetype.org/jam/index.html, it works tremendously well.
It's easy to get binaries for almost any operating system (especially
with projects like homebrewhttp://mxcl.github.com/homebrew/ for Mac).
I have very few gripes with it:
* The build description language is very simple (once you fully grok
it), but could have done with a lot more example-based documentation.
* It's missing a few features like recursive-directory scanning (for
source files), and the ability to pipe the output from a program
into a variable in the build script (e.g. C++FLAGS = `llvm-config
--cxxflags`).
* A convenient way to force all generated object and library files
into a dedicated build folder. It's possible but not very easy to do.
* I'm a big fan of convention over configuration, I know it's a very
subjective topic but I like the way Maven3 and Gradle assume a
project structure (that you can deviate from if you need to). This
usually requires very good supporting documentation.
The build script I put together for my project looked like this,
http://mysticpaste.com/private/TCcTE6KGxn .
Interesting points to keep in mind, thanks. After recently looking at Waf, I
do agree with you that it'd be nice to, as you say, assume a project
structure (that you can deviate from if you need to). Definitely some
benefits to be gained from that.
Re: Prototype buildsystem Drake
I completely agree. I definitely believe that work on a new build tool is worthwhile especially if it has built in support for D. It's a shame that so many build tools at the moment are being developed using interpreted languages, it's obviously for the benefits of creating DSLs that extend the base language itself. They tend to suffer from slowness though (my subjective opinion ;-) ). I don't think building the tool in D is a good idea either for reasons mentioned by Ulrik. It's worth considering using Lua http://www.lua.org/ or Io http://iolanguage.com/ for the build description language but writing the tool in C (or other). Cheers, Chris On 07/13/11 23:32, Ulrik Mikaelsson wrote: 2011/7/13 Nick Sabalauskya@a.a: Jacob Carlborgd...@me.com wrote in message news:ivke5k$2m78$1...@digitalmars.com... First I have to say that I know you are doing this because you want to use D as the language for the build scripts. The reason I did choose Ruby because I think D will be too verbose and when I'm looking at drakefile.d I do think it's too verbose. Yea, D is likely to be a little more verbose than what could be done in Ruby (or Python). Personally, I think that's well worth it, though. I don't know how many others would agree or not. Not trying to be argumentative, but what exactly do you see as the gains in having a D-buildtool built in D (or D-specific build-tool in any language, for that matter)? Seriously, I'm really asking, since I'm having a hard time seeing it? Personally, I can only see the drawbacks; * Building druntime and phobos might be difficult with a d-based buildtool * The build-tool itself will need bootstrapping. A user that wants to test some D-project, will first have to aquire (build) and install some D-compiler with custom tools. Then install druntime with another custom build-system. Then Phobos. Then drake. And THEN, the application/library he/she was interested in. Shortening this path is IMHO REALLY important to see more D adoption. From my personal experience, convincing developers and testers to fight through this path is HARD. * Cross-language builds (project with bindings), and builds with external targets might be more difficult than need be, if the 2nd language is not supported by drake. * Verbose build-script is IMHO a _really_ undesireable trait. * How soon will I as a developer be able to just build a D-binding to a C++-app (with needed C-glue-code) in Drake? Will a user of, say Gentoo, be able to count on this working in his/her envrironment too? * Non-compilation actions will have to be reimplemented; document generation, test execution, install-tasks following OS-specific install procedures (XDG-guidelines etc.), ... IMHO, it sounds like a case of the NIH-syndrome, but I might be missing something obvious?
Re: Complete floating point literals
Maybe they want to write an API with a Web 2.0 style
http://documentcloud.github.com/underscore/? :-P
Chris
On 07/11/11 00:49, Caligo wrote:
while we are at it, let's get rid of this too:
class _{ }
why would anyone want to name a class or a variable _ ??
Re: D brand identity repository
It's a great logo Mafi, is it possible to try it without the italics and see what that looks like? IMHO it's between: https://github.com/eegg/d-brand/raw/master/d-logo-7.png AND https://github.com/eegg/d-brand/raw/master/dlogo-mafi.png Thanks for the hard work guys, beauty surrounding the D language is just as important (arguably more important) as the beauty of the language itself. Chris On 06/30/11 21:58, Mafi wrote: Am 30.06.2011 22:39, schrieb James Fisher: On Thu, Jun 30, 2011 at 9:29 PM, Andrej Mitrovic andrej.mitrov...@gmail.com mailto:andrej.mitrov...@gmail.com wrote: On 6/30/11, James Fisher jameshfis...@gmail.com mailto:jameshfis...@gmail.com wrote: Here's Mafi's suggestion in PNG: https://github.com/eegg/d-brand/raw/master/dlogo-mafi.png Odd, in my browser the D letter looked really thin when I viewed the SVG. Maybe it was a rendering bug. GP -- Mafi left it in Verdana, which I don't have here, so that PNG is actually DejaVu Sans. Heh. Mafi, if you could convert to a path? Sometimes svg behaves odd... I've attached the path-version. I've also uploaded a rendering at http://imgur.com/J1pbr because the above looks a bit different than mine. Mafi PS: I license these images with CC-0.
Re: Why I'm hesitating to switch to D
I very much agree. When it comes to lightweight markup languages for use in web (and more) templating there's: Markdown http://daringfireball.net/projects/markdown/, Markdown Extra http://michelf.com/projects/php-markdown/extra/, Haml http://haml-lang.com/, Textile http://textile.thresholdstate.com/... to name just a few. Is it worth maintaining another tool? When it comes to documentation within source files couldn't D adopt one of the many different http://en.wikipedia.org/wiki/Comparison_of_documentation_generatorsdocumentation generators? Again wouldn't that mean less custom tools to maintain. Unless of course ddoc does something more than these other tools? Cheers, Chris On 06/29/11 09:38, James Fisher wrote: On Wed, Jun 29, 2011 at 7:46 AM, Jacob Carlborg d...@me.com mailto:d...@me.com wrote: On 2011-06-28 23:09, Walter Bright wrote: 5. I know I suck at web site design, which is why David Gileadi helped us out by designing the d-programming-language.org http://d-programming-language.org look feel. I think it makes it hard when most of the pages are written in DDOC. It doesn't help to attract web designers. I'd definitely agree with that. I have no experience with DDOC, but TBH I don't intend to ever have any. As a general criticism of DDOC, it seems like another reinvented wheel. Semi-plaintext formats surround us like the plague, and for every use case for documentation, there's a better option. If you want * simplicity, use Markdown http://daringfireball.net/projects/markdown/. Supported everywhere, like GH. * bulky extensible semantic documentation, use DocBook http://www.docbook.org/. Used by O'Reilly, I'm told. Presumably that's how Real World Haskell http://book.realworldhaskell.org/ is maintained as a slick website and an O'Reilly book. * readability, but power and extensibility if required, use docutils http://docutils.sourceforge.net//Sphinx http://sphinx.pocoo.org/. Used for the Python standard library documentation http://docs.python.org/py3k/, which, as anyone who has used it knows, is The Best Documentation In The World. That said, I suspect DDOC is now entrenched at least in the stdlib documentation, so maybe we'll have to live with it. However, the case for using it for the website https://github.com/D-Programming-Language/d-programming-language.org/blob/master/index.dd is nonexistent (anyone disagree?).
Re: Why I'm hesitating to switch to D
Ok, Ddoc is great at writing D documentation, that's what it was designed for. Why use a tool designed for code documentation as a web templating language? Aren't we (as programmers) always saying use the right tool for the right job... I understand Ddoc's advantages http://www.digitalmars.com/d/2.0/ddoc.html now. No-one is saying Ddoc is hard to learn (at least I'm not saying that) but with so many tools, languages and frameworks to learn these days should it be necessary to know it when you're a D enthusiast that wants to contribute a HTML tutorial on d-programming-language.org. My 2-cents, Chris On 06/29/11 12:25, Walter Bright wrote: On 6/29/2011 1:38 AM, James Fisher wrote: However, the case for using it for the website https://github.com/D-Programming-Language/d-programming-language.org/blob/master/index.dd is nonexistent (anyone disagree?). I do. Ddoc is: 1. Rather trivial to learn use. A website/book/community devoted to how to use it is completely unnecessary. It's fairly obvious how to use it (for someone with a basic familiarity with HTML) by simply looking at a couple examples. 2. It automatically tracks the D language, so D code examples are always properly highlighted. 3. It is always available and installed for anyone who installs D. 4. The D compiler and Ddoc are always in sync. No begging for updates from 3rd parties, no lags even if they get right on incorporating necessary updates. 5. It is not necessary to direct anyone to install some third party system that may not even exist on all the platforms D does. In general, we try to minimize dependency on things that are not default installed across operating systems. 6. And lastly, it works, it delivers, and has for many years. It's proven its worth. If a professional web designer uses famous system X to develop with, and if we used famous system Y, it's just as much a barrier for him to relearn how to do things with Y as it is to learn Ddoc. Please don't be too dismissive of the productivity gains from using Ddoc. At the time we started using it, the website and the Phobos documentation improved by huge leaps and bounds, simply because it was so easy to generate decent documentation with Ddoc.
Re: Why I'm hesitating to switch to D
What a useless comment to a potential contributor... see Walter's earlier comment for a constructive way to reply to someone interested in D. Btw, prefixing your comment with no offense, is like saying with all due respect you're an ass. Chris On 06/29/11 19:19, Dejan Lekic wrote: James, no offense - this is a post made by a person who probably did not look more than 10min for what he needs... #1 Package management - if you were around you would see that it is a hot topic, and will be solved soon. #2 I do not know how you see community fragmentation, really. D community is here on the NG, on IRC ( irc://irc.freenode.org/d ), DSource, GitHub ... #3 Unreachable? How? Do not tell me you type D in Google and You seriously expect it to give you http://www.d-programming-language.org as the first hit!? :) #4 Now I am convinced you actually did not look at the http://www.d-programming-language.org ... Yes, DigitalMars website has kind of old-school HTML, but there are other websites out there. If you discard an excellent programming language like D just because the author's website looks crappy, than I have no further comments, really... Conclusion: -- Get informed.
Re: Naming conventions for functions in similar modules
I'm mostly a listener on the mailing list but I very much agree with Walter. Personally I think arguments about typing length are daft in an age with IDEs and language tooling. The most important aspect of the naming convention IMHO is readability and intuitiveness. I like the idea of naming the functions in different modules with the same pattern if they complete the same task (albeit in different ways or on different types of data... etc). There's a lot of options for disambiguating naming clashes in the language: * aliasing * renamed imports * selective importing from a module * fully qualified names (e.g. std.ascii.toLower() ) That's my two cents, Chris On 06/22/11 17:53, Walter Bright wrote: On 6/22/2011 4:47 AM, Lars T. Kyllingstad wrote: One problem: std.uni only contains functions for dealing with upper/ lower case and for checking whether something is an alpha character. If you want the other functions, such as isDigit(), isPunctuation(), etc. you still have to import std.ascii. And once you have imported both std.uni and std.ascii, you are forced to disambiguate every time you call a function which exists in both. True, but I don't see much of an improvement of: toAsciiLower() over: std.ascii.tolower() at least as far as typing goes.
Re: Best build tool for D projects
Your test was a good one, the build fails on even a simple hello world program. I'm using the dmd2-complete package from the AUR (archlinux user repository). Where should the phobos/druntime libraries be placed on the system? On 18/05/11 18:48, Jesse Phillips wrote: Can you build a simple hello world program with just: dmd hello.d The build can't find the phobos/druntime libraries for linking. Chris Molozian Wrote: [Stuff]
Re: Best build tool for D projects
to `_D4core5bitop3bsrFNaNbmZi' std/numeric.d:(.text._D3std7numeric12isPowerOfTwoFmZb+0x1b): undefined reference to `_D4core5bitop3bsfFNaNbmZi' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib/libphobos2.a(numeric_872_5ab.o): In function `_D3std7numeric14__T6StrideTAfZ6Stride6nStepsMFNdmZm': std/numeric.d:(.text._D3std7numeric14__T6StrideTAfZ6Stride6nStepsMFNdmZm+0x2a): undefined reference to `_D4core5bitop3bsfFNaNbmZi' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib/libphobos2.a(array_162_6f0.o): In function `_D3std5array18__T8AppenderTAAyaZ8Appender11newCapacityFmZm': std/array.d:(.text._D3std5array18__T8AppenderTAAyaZ8Appender11newCapacityFmZm+0x1e): undefined reference to `_D4core5bitop3bsrFNaNbmZi' collect2: ld returned 1 exit status --- errorlevel 1 dmd -L-lstdc++ -L-ldl -ofpuckc src/main.o libllvmd.a ...failed Link puckc ... ...failed updating 1 target(s)... ...updated 4 target(s)... Anyone got any experience using Jam or advice and help on solving the link errors. Cheers, Chris On 13/05/11 18:38, Chris Molozian wrote: Hey All, This is my first post to the mailing list, I'm an avid follower of D's development and am currently using it to develop a compiler for my thesis work. One of the goals of this stage of the development work is to provide a simple build environment to compile the codebase on Linux, Windows and Mac OS X. The only complex aspects of the build process is compiling the LLVM-D bindings and linking to LLVM. I'm evaluating build tools for this purpose and have concluded (correct me if I'm wrong) that the D-orientated build tools: Bud http://www.dsource.org/projects/build and DSSS http://www.dsource.org/projects/dsss are abandoned. I'm not sure whether development on xfBuild https://bitbucket.org/h3r3tic/xfbuild/overview is still going on. I'd like to use a tool that is easy for testers to install on their system (preferably pre-built binaries are available) and use to compile my work. I've been looking at C/C++ build tools and have narrowed it down to these: * Jam (ftjam) http://www.freetype.org/jam/index.html, cross-platform and platform independent build language. Lots of variants with the same name, therefore finding it hard to find good tutorials and documentation. * Boost.Build (bjam) http://www.boost.org/boost-build2/, not sure how it differs to ftjam. * Cook http://miller.emu.id.au/pmiller/software/cook/, can't find whether it can be built for use on Windows. No pre-built Windows binary. Very extensive documentation, although I think the default build file name is silly Howto.cook :-) . After all this preamble I guess what I'm asking is... what (if any) cross-platform build tools does everyone use with their D projects? Any feedback on experiences with any of the build tools I've mentioned is also greatly appreciated. If you can suggest any alternatives, please do. If you've read this far, thanks for taking the time to read it :-) and sorry for the long message. Cheers, Chris PS: I've seen the CMakeD http://www.dsource.org/projects/cmaked module, I know a lot of people recommend CMake for cross-platform builds and that the KDE guys use it. I have tried to like it... but settled on hating it. The procedural language is daft and ugly and I loathe the CMakeLists.txt file that goes in each directory. I've already ruled it out.
Re: Best build tool for D projects
Thanks for the update on xfBuild. On 13/05/11 21:28, Trass3r wrote: Am 13.05.2011, 19:38 Uhr, schrieb Chris Molozian ch...@cmoz.me: I'm not sure whether development on xfBuild https://bitbucket.org/h3r3tic/xfbuild/overview is still going on. Well activity has certainly decreased lately but it still works fine (incremental builds regularly crash though, but according to h3r3tic's blog that's dmd's fault)
Re: Best build tool for D projects
Thanks for the link to the project, I'll try it out. It's a shame there's no documentation for CDC but the Yage project is considerably more complex than my needs from a build tool, it's build script will be useful to read. On 13/05/11 21:11, Eric Poggel (JoeCoder) wrote: On 5/13/2011 1:38 PM, Chris Molozian wrote: After all this preamble I guess what I'm asking is... what (if any) cross-platform build tools does everyone use with their D projects? Any feedback on experiences with any of the build tools I've mentioned is also greatly appreciated. If you can suggest any alternatives, please do. I'm certainly biased because I wrote it, but I use cdc for all of my D building. At one point it was working with dmd1, dmd2, gdc1, and ldc on windows and linux (I don't own a mac) with tango or phobos. But it's been a while since I've tested it. http://dsource.org/projects/cdc It accepts the same arguments and works the same as dmd except it also accepts folder names for arguments, compiling in all .d files it finds there. And it's a single file, making it script friendly. You can do something like this: dmd -run cdc.d project_folder -of../bin/myproject.exe cdc.d also has a nicely organized api for easily creating your own build script. I use this with Yage for building derelict into a lib in order to reduce compilation time. See the main function in this file. The rest is unmodified from the cdc project: http://dsource.org/projects/yage/browser/trunk/build/buildyage.d
Re: Best build tool for D projects
Thanks for recommending Waf, I'll have a look at it. On 14/05/11 08:54, Russel Winder wrote: Chris, On Fri, 2011-05-13 at 18:38 +0100, Chris Molozian wrote: [ . . . ] * Jam (ftjam), cross-platform and platform independent build language. Lots of variants with the same name, therefore finding it hard to find good tutorials and documentation. Everyone I know who has used this either loves it (very few people) or hates it (almost everyone). The claim is the notation is poor, and you have to do lots of tweaking even of stuff that should be out of the box. * Boost.Build (bjam), not sure how it differs to ftjam. See above. From what I can tell an increasing number of Boost projects are moving away from this build framework. Based on the above I have never used it myself. * Cook, can't find whether it can be built for use on Windows. No pre-built Windows binary. Very extensive documentation, although I think the default build file name is silly Howto.cook :-) . I've not come across this one. After all this preamble I guess what I'm asking is... what (if any) cross-platform build tools does everyone use with their D projects? Any feedback on experiences with any of the build tools I've mentioned is also greatly appreciated. If you can suggest any alternatives, please do. If you've read this far, thanks for taking the time to read it :-) and sorry for the long message. No problem. PS: I've seen the CMakeD module, I know a lot of people recommend CMake for cross-platform builds and that the KDE guys use it. I have tried to like it... but settled on hating it. The procedural language is daft and ugly and I loathe the CMakeLists.txt file that goes in each directory. I've already ruled it out. I can't say I blame you, I think there language is outrageously horrible. I am sure others will highlight a few other choices but the mainstream ones remain: Make Autotools CMake SCons Waf Personally I have abandoned Make and Autotools as being out of date and too crufty. Historically they are massively important systems, and so deserve praise and honour. But time has moved on and new lessons learned. CMake is out already. SCons is a Python-based, internal DSL system. I know the D support reasonably well as at some point 18 months ago I found myself deemed the official support for the D tool. SCons is truly great in some build situation -- it's really a Make replacement with some very interesting bells and whistles, and of course all the power of a dynamic language -- but for other situations it can be slow and a bit clunky. My main use is its sweet spot, so I use it a lot. Waf was a system built on SCons, then it was a SCons fork, now it has evolved to be something different in its own right. It is Python based and is intended to be an Autotools replacement. Its real sweet spot is whole-project, ship source, and build locally or some subset thereof. I like Waf.
Best build tool for D projects
Hey All, This is my first post to the mailing list, I'm an avid follower of D's development and am currently using it to develop a compiler for my thesis work. One of the goals of this stage of the development work is to provide a simple build environment to compile the codebase on Linux, Windows and Mac OS X. The only complex aspects of the build process is compiling the LLVM-D bindings and linking to LLVM. I'm evaluating build tools for this purpose and have concluded (correct me if I'm wrong) that the D-orientated build tools: Bud http://www.dsource.org/projects/build and DSSS http://www.dsource.org/projects/dsss are abandoned. I'm not sure whether development on xfBuild https://bitbucket.org/h3r3tic/xfbuild/overview is still going on. I'd like to use a tool that is easy for testers to install on their system (preferably pre-built binaries are available) and use to compile my work. I've been looking at C/C++ build tools and have narrowed it down to these: * Jam (ftjam) http://www.freetype.org/jam/index.html, cross-platform and platform independent build language. Lots of variants with the same name, therefore finding it hard to find good tutorials and documentation. * Boost.Build (bjam) http://www.boost.org/boost-build2/, not sure how it differs to ftjam. * Cook http://miller.emu.id.au/pmiller/software/cook/, can't find whether it can be built for use on Windows. No pre-built Windows binary. Very extensive documentation, although I think the default build file name is silly Howto.cook :-) . After all this preamble I guess what I'm asking is... what (if any) cross-platform build tools does everyone use with their D projects? Any feedback on experiences with any of the build tools I've mentioned is also greatly appreciated. If you can suggest any alternatives, please do. If you've read this far, thanks for taking the time to read it :-) and sorry for the long message. Cheers, Chris PS: I've seen the CMakeD http://www.dsource.org/projects/cmaked module, I know a lot of people recommend CMake for cross-platform builds and that the KDE guys use it. I have tried to like it... but settled on hating it. The procedural language is daft and ugly and I loathe the CMakeLists.txt file that goes in each directory. I've already ruled it out.
