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:
- 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.)
- 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.
On Wed, Jul 13, 2011 at 7:28 PM, Jacob Carlborg
<doob@me.com> wrote:
On 2011-07-13 19:27, Jonathan M Davis wrote:
On 2011-07-13 08:36, Jacob Carlborg wrote:
On 2011-07-13 07:28, Jonathan M Davis wrote:
On Wednesday 13 July 2011 06:12:58 Russel Winder wrote:
And, of course, I should have mentioned CMake and CMakeD.
The fact that I forgot, shows my prejudice against Makefile-based
systems and for direct DAG-based systems such as Gradle, SCons and Waf.
This though should not stop CMakeD being a part of this debate.
From previous discussions, it seems that one of the primary reasons for
having
a D build tool in many people's minds is to also handle package
management of D libraries (like Haskell's cabal or rubygems for ruby).
And as great as cmaked, scons, gradle, waf, and other such tools may be,
they don't do that.
- Jonathan M Davis
I don't agree with that. I think a build tool should deal with single
files and building. A package manager should deal with packages (of
files). In Ruby, RubyGems is the package manager and Rake is the build
tool.
Well, I'm not advocating anything in particular. I was just pointing out that
a big part of the discussions on build tools has been package management of
libraries, and any build tool solution which doesn't at least integrate with
some sort of package management solution is likely to not be what at least
some people are looking for.
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.
Personally, I don't generally use package management tools for handling
libraries even with languages that have such tools, and I don't generally use
much in the way of build tools either beyond simple scripts (primarily because
I don't generally have projects large enough for it to be an issue). As it
stands, if I were to choose a build tool for a larger project, I'd probably
choose CmakeD, but I'm not super-familiar with all of the tools out there and
haven't generally found much use for them.
I was just trying to point out that a fair bit of the discussion for such
tools in this list has related to package management, and Nick's solution
doesn't address that at all AFAIK.
- Jonathan m Davis
Ok, I see.
--
/Jacob Carlborg