On Tue, 14 Jun 2011 15:14:28 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
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.
dmd: I need module foo.awesome. Where is it?
filesystem: nope, don't have it
dmd: damn, I guess I'll need to check with the downloader, hey downloader
you have that?
downloader: hm... oh, yeah! I'll get it for you
filesystem: got it
dmd: ok, now what's in foo.awesome? Oh, hm... foo.awesome needs
bar.gnarly. Let me guess filesystem...
filesystem: yeah, I suck today, go ask downloader
...
How hard is that? I mean the actual downloading of files is pretty
straightforward, at some point the problem reduces to "download a file".
Why do we have to reinvent *that* wheel.
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.
And it would, why wouldn't it? I think you may not be getting something
here...
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.
dmd would drive them.
I think Adam's tool is a good identification and alternative solution
for the problem that the pragma solves.
I haven't seen it. Just thinking out loud...
-Steve
