Andrei Alexandrescu Wrote:

> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
> 
> Destroy.
> 
> 
> Andrei

I'm in agreement with those saying it doesn't belong in the compiler/language. 
In order for it to make sense in this location it would need to take on of a 
build tool role, which has already be stated to add cause more confusion when 
something goes wrong. 

How confusing is it to say, DMD downloads required modules for you, but will 
fail to build an executable because you must tell it to use those files. Sure 
using rdmd is to provide a seamless experience, but this results in more back 
and forth between compiler and build tool.

Then there is the caching issue. The proposal has no solution on this, and for 
good reason. The goal isn't to cache it is to install the library, meaning it 
is persistent and usable by other projects.

Installing a library can involve many things, and especially for D can mean 
compiling C or installing libraries. This solution is looking at a smaller 
scope, but I don't think it really saves on a "configuration" file.

On a note about build tools. I'm like you and Walter in that they always seem 
so complicated and very fragile. And personally go with simple Makefiles. I'm 
not really familiar with the problems many of these tools are trying to solve.

I was reading up on redo, and whether it was intended or not, I found one idea 
that really stuck with me. File transformation operations. Make does a really 
nice job of dependency resolution and I think this idea of taking a list of 
dependencies and transforming them into another file makes simple files. So to 
do an incremental build for D:

.o: .d
    dmd -c $2

: .o
    dmd -of$3 $2

mytarget: target.d depended.d on.d files.d

Ok, I haven't gone into depth with what build tools should also be solving, or 
how to get it working. but this is just my initial "hey I want that."

Reply via email to