This is a questions pointed mostly to Burton, but I'll provide some background info for everyone else. Dig is a module used for building GUIs in D (among other things). digc is a build tool used for pre-compiling (?) code that uses the dig module.

Now for the question: Why did you choose to implement digc (the build tool for dig) rather than just relying on the capabilities built into the compiler? What special features did you need in your libraries that you couldn't support without creating a specialized build tool.

Admittedly, I haven't done any tinkering with dig (though I'm very interested in getting a set standard for D GUI development). Frankly, the idea of a separate build tool has been somewhat of a turn-off for me. If everybody's libraries had a special build tool, we'd be back in pre-processor land (with a vengeance).

So, what's the scoop? Why do we need digc?

digc is *not* a preprocessor. It simply searches and selects module files automatically, also making sure everything is "new enough". So, working through this is more like Delphi, while invoking the original compiler appeares more C-like -- you must explicitly state every module file or library used. digc does the recursive dependancy tracking for you, which the compiler itself as of yet doesn't.

All the code which can be compiled with digc, could also be directly compiled with some makefile work. On the other hand, after you det used to digc, you don't want to miss it for any more-than-1-file project..

I believe i was one of the people who voted for such a feature in compiler, but as Walter has better things to do, Burton implemented this build tool. It can be viewed as a proposeal to extend the compiler, and may become absolete as D's modules model becomes solid: it needs some tinkering about namespace pollution anyway.

-i.


BenjiSmith wrote:
> This is a questions pointed mostly to Burton, but I'll provide some background
> info for everyone else. Dig is a module used for building GUIs in D (among other
> things). digc is a build tool used for pre-compiling (?) code that uses the dig
> module.
> 
> Now for the question: Why did you choose to implement digc (the build tool for
> dig) rather than just relying on the capabilities built into the compiler? What
> special features did you need in your libraries that you couldn't support
> without creating a specialized build tool.
> 
> Admittedly, I haven't done any tinkering with dig (though I'm very interested in
> getting a set standard for D GUI development). Frankly, the idea of a separate
> build tool has been somewhat of a turn-off for me. If everybody's libraries had
> a special build tool, we'd be back in pre-processor land (with a vengeance).
> 
> So, what's the scoop? Why do we need digc?

Gotcha.

So, when the Burton says that digc is required to compile the http/ftp module, it really isn't true. It's not technically required, but you'd be insane not to use it. You'd have to write a makefile to build your dependencies in the right order, but life is better because digc does it for you.

But you _could_ use dig without digc, if you wanted to (and if you thought it was fun to write makefiles), right?


In article <beklqn$2r0o$1@digitaldaemon.com>, Ilya Minkov says...
>
>digc is *not* a preprocessor. It simply searches and selects module files automatically, also making sure everything is "new enough". So, working through this is more like Delphi, while invoking the original compiler appeares more C-like -- you must explicitly state every module file or library used. digc does the recursive dependancy tracking for you, which the compiler itself as of yet doesn't.
>
>All the code which can be compiled with digc, could also be directly compiled with some makefile work. On the other hand, after you det used to digc, you don't want to miss it for any more-than-1-file project..
>
>I believe i was one of the people who voted for such a feature in compiler, but as Walter has better things to do, Burton implemented this build tool. It can be viewed as a proposeal to extend the compiler, and may become absolete as D's modules model becomes solid: it needs some tinkering about namespace pollution anyway.
>
>-i.
>
>
>BenjiSmith wrote:
>> This is a questions pointed mostly to Burton, but I'll provide some background info for everyone else. Dig is a module used for building GUIs in D (among other things). digc is a build tool used for pre-compiling (?) code that uses the dig module.
>> 
>> Now for the question: Why did you choose to implement digc (the build tool for dig) rather than just relying on the capabilities built into the compiler? What special features did you need in your libraries that you couldn't support without creating a specialized build tool.
>> 
>> Admittedly, I haven't done any tinkering with dig (though I'm very interested in getting a set standard for D GUI development). Frankly, the idea of a separate build tool has been somewhat of a turn-off for me. If everybody's libraries had a special build tool, we'd be back in pre-processor land (with a vengeance).
>> 
>> So, what's the scoop? Why do we need digc?
>