<div>When writing Haskell and compiling with GHC, the compiler automatically finds the module dependencies and compiles them in the correct order.  If I touch a few modules and recompile, GHC will only recompile the touched modules as appropriate, then re-link.  In other words, GHC is the build tool as well as the compiler.  The advantages of this approach over having a separate build tool are:</div>
<div><br class="Apple-interchange-newline">- the compiler already knows how to parse module files, so it's in the perfect position to know what the dependencies are.  We don't have some hacky extra tool sniffing out lines that look like "import X;".  This alone seems error-prone, but more importantly, D modules can have arbitrary compile-time logic executed before importing something, so the build tool essentially either has to give up or reimplement the compiler to cover all cases.  (This is the primary reason I advocate this approach -- I don't see how a generic build tool can automatically detect dependencies without the participation of a D compiler.)</div>
<div>- the steps to compile a one-file program are exactly the same as compiling a complex multi-module program: "ghc Main".  If I split out one file into several, I don't have to immediately switch to using Make/waf/etc; it will Just Work.  There's one less tool to remember, and once you've got your D compiler, you're all set.</div>
<div><div><div><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 7:28 PM, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com">doob@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 2011-07-13 19:27, Jonathan M Davis wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 2011-07-13 08:36, Jacob Carlborg wrote:<br>
</div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2011-07-13 07:28, Jonathan M Davis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wednesday 13 July 2011 06:12:58 Russel Winder wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And, of course, I should have mentioned CMake and CMakeD.<br>
<br>
The fact that I forgot, shows my prejudice against Makefile-based<br>
systems and for direct DAG-based systems such as Gradle, SCons and Waf.<br>
This though should not stop CMakeD being a part of this debate.<br>
<br>
 From previous discussions, it seems that one of the primary reasons for<br>
having<br>
</blockquote>
<br>
a D build tool in many people's minds is to also handle package<br>
management of D libraries (like Haskell's cabal or rubygems for ruby).<br>
And as great as cmaked, scons, gradle, waf, and other such tools may be,<br>
they don't do that.<br>
<br>
- Jonathan M Davis<br>
</blockquote>
<br>
I don't agree with that. I think a build tool should deal with single<br>
files and building. A package manager should deal with packages (of<br>
files). In Ruby, RubyGems is the package manager and Rake is the build<br>
tool.<br>
</blockquote>
<br></div></div><div class="im">
Well, I'm not advocating anything in particular. I was just pointing out that<br>
a big part of the discussions on build tools has been package management of<br>
libraries, and any build tool solution which doesn't at least integrate with<br>
some sort of package management solution is likely to not be what at least<br>
some people are looking for.<br>
</div></blockquote>
<br>
Ok, I see. I think as well that the build tool and package manager should interact with each other. For example, specifying package dependencies in the build script. But, I think they need to be separate and be usable on their own.<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Personally, I don't generally use package management tools for handling<br>
libraries even with languages that have such tools, and I don't generally use<br>
much in the way of build tools either beyond simple scripts (primarily because<br>
I don't generally have projects large enough for it to be an issue). As it<br>
stands, if I were to choose a build tool for a larger project, I'd probably<br>
choose CmakeD, but I'm not super-familiar with all of the tools out there and<br>
haven't generally found much use for them.<br>
<br>
I was just trying to point out that a fair bit of the discussion for such<br>
tools in this list has related to package management, and Nick's solution<br>
doesn't address that at all AFAIK.<br>
<br></div>
- Jonathan m Davis<br>
</blockquote>
<br>
Ok, I see.<br>
<br>
-- <br><font color="#888888">
/Jacob Carlborg<br>
</font></blockquote></div><br></div></div></div>