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 Molozian"<ch...@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 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.
