DIP11

[Steven Schveighoffer]

On Thu, 11 Aug 2011 15:09:15 -0400, Nick Sabalausky <a at a.a> wrote:

> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
> news:op.vz166yaieav7ka at localhost.localdomain...
>> On Thu, 11 Aug 2011 12:24:48 -0400, Andrew Wiley
>> <wiley.andrew.j at gmail.com> wrote:
>>
>>> On Thu, Aug 11, 2011 at 5:52 AM, Steven Schveighoffer
>>> <schveiguy at yahoo.com>wrote:
>>>> I think the benefit of this approach over a build tool which wraps the
>>>> compiler is, the compiler already has the information needed for
>>>> dependencies, etc.  To a certain extent, the wrapping build tool has  
>>>> to
>>>> re-implement some of the compiler pieces.
>>>>
>>>
>>> This last bit doesn't really come into play here because you can  
>>> already
>>> ask
>>> the compiler to output all that information. and easily use it in a
>>> separate
>>> program. That much is already done.
>>
>> Yes, but then you have to restart the compiler to figure out what's  
>> next.
>> Let's say a source file needs a.d, and a.d needs b.d, and both a.d and  
>> b.d
>> are on the network. You potentially need to run the compiler 3 times  
>> just
>> to make sure you have all the files, then run it a fourth time to  
>> compile.
>>
>
> That's *only* true if you go along with DIP11's misguided file-oriented
> approach. With a real package manager, none of that is needed. Your app  
> just
> says "I need packages X, Y and Z."

It already does this:

import std.stdio;

says "I need the package std"

The purpose of the DIP is to try and reuse this information without having  
to have an extraneous file that says "I depend on package std."

> And X, Y and Z do the same for their requirements. This is all trivial
> metadata. Emphasis on *trivial*. So, before DMD is ever invoked at all,
> before one line of the source is ever even read, the package manager has
> make sure that *everything* is *already* right there. No need to go off  
> on
> some goofy half-cocked "compile/download/complile/download" dance.

With the DIP, I envision encoding the package in the URL.  For example,  
you do:

-Ispiffy=dpm://spiffy.com/latest.dpm

And then blah.d imports spiffy.neat.  The download tool is given the url  
dpm://spiffy.com/latest.dpm/neat.d and understanding the d package module  
(dpm) protocol, downloads the package that contains neat.d, (along with  
compiled lib) and then pipes the contents of neat.d to the compiler, which  
treats it just like a file it just read from the filesystem.  Then any  
other file needed from that package is simply piped from the  
already-downloaded package.

It doesn't have to be one-file based, you just need to have a way to map  
physical packages to module packages.

The DIP doesn't explain all this except for the sections titled  
"Packaging" and "protocols"

> So DMD *never* needs to be invoked more than twice. Once to get the deps,
> once to compile. Better yet, if DMD gets the
> switch  
> --compile-everything-dammit-not-just-the-explicit-files-from-the-command-line,
> then DMD never needs to be invoked more than *once*: Once to figure out  
> the
> deps *while* being intelligent enough to actually compile all of them.

This would be beneficial to DIP11 as well, since downloading and importing  
the file is only half the battle.

-Steve