Re Build tools for D [ was Re: Prototype buildsystem "Drake"]

[James Fisher]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110718/f2343c87/attachment.html>