• BenjiSmith (13/13) Jul 09 2003 This is a questions pointed mostly to Burton, but I'll provide some back...
• Ilya Minkov (16/32) Jul 10 2003 digc is *not* a preprocessor. It simply searches and selects module
• BenjiSmith (8/40) Jul 10 2003 Gotcha.

BenjiSmith <BenjiSmith_member pathlink.com> writes:

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?

Ilya Minkov <midiclub 8ung.at> writes:

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?

BenjiSmith <BenjiSmith_member pathlink.com> writes:

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?