Prototype buildsystem "Drake"

Nick Sabalausky a at a.a
Wed Jul 13 11:31:33 PDT 2011


"Chris Molozian" <chris at cmoz.me> wrote in message 
news:mailman.1595.1310554903.14074.digitalmars-d at 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 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 .
>

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.





More information about the Digitalmars-d mailing list