On 2011-07-18 19:37, James Fisher wrote:
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.
With DMD you can use the -deps flag to get all the dependencies of all
specified files. No reason to try to parse import statements.
Can GHC compiler other types than executables, i.e. libraries?
--
/Jacob Carlborg
