DIP11: Automatic downloading of libraries

[Andrei Alexandrescu]

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