DIP11: Automatic downloading of libraries

[Andrei Alexandrescu]

On 6/14/11 2:25 PM, Steven Schveighoffer wrote:
> On Tue, 14 Jun 2011 15:14:28 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at 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.

It's not hard, in fact that's almost how we want to implement it: a 
straight function that wraps a call to wget. The difference is that 
you'd migrate the function into a separate utility, and I think that's a 
good idea. (Walter prefers it inside the compiler.)

>> 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...

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=138556


Andrei