On 6/14/11 1:58 PM, Steven Schveighoffer wrote:
I think it should be split as follows:
dmd: determine *what* to download (i.e. I need to import module x.y.z)
It can't (unless it does the download too) due to transitive dependencies.
external tool: determine *where* and *how* to download it. (i.e. module
x.y.z lives on http://somerepository.org/x, go get it and save it)
The advantages being:
1. there exists umpteen billion already-existing tools that fetch and
install data over the network
2. dmd does not contain parts that have nothing to do with compiling,
which could potentially screw up the compiling part.
3. Depending on the tool language, the barrier to development of it
would be significantly reduced. Most people feel quite uncomfortable
messing with compiler source code, but have no problems editing
something like a shell script, or even a simple d-based tool.
4. The compiler is written in C++, and hence so would the part that does
this have to be... yuck!
Not sure I grok 3 and 4, but as far as I can tell the crux of the matter
is that dependencies are already embedded in .d files. That's why I
think it's simpler to just let dmd take care of them all instead of
maintaining dependency description files in separation from the .d files.
The umpteen billion tools don't know what it takes to download and build
everything starting from one or a few root modules. They could execute
the download, yes (and of course we'll use such a library for that), but
we need a means to drive them.
I think Adam's tool is a good identification and alternative solution
for the problem that the pragma solves.
Andrei
