DIP11

[Steven Schveighoffer]

On Thu, 11 Aug 2011 10:47:36 -0400, Jacob Carlborg <doob at me.com> wrote:

> On 2011-08-11 14:52, Steven Schveighoffer wrote:
>> Given that the implementation would be a compiler-used tool, and the
>> tool can implement any protocol it wants, I think it has very few
>> limitations. I envision the tool being able to handle any network
>> protocol or packaging system we want it to.
>
> That might be the case. Since it's arbitrary URLs that represents D  
> modules and packages, to me it seems that there needs to be a lot of  
> conventions:
>
> * Where to put the packages
> * How to name them
> * How to indicate a specific version

These are implementation details.  The compiler just knows "hm.. there's  
some external file, I don't know how to get it, tool, can you help me out?"

The tool could potentially download the files and build them, or download  
a pre-compiled package.  Or it could add files to the compiler's todo list  
somehow (having recursive compiler invocations might be bad...)

>> 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.
>>
>> -Steve
>
> Until the compiler can automatically compile dependencies we need build  
> tools.

I agree it would be advantageous to have the build tool add files to the  
compiler's todo list.  As of now, just downloading source for import does  
not help because you still need to compile the file, not just import it.

But you have to admit, just having the source file or include path include  
parts of the internet would be pretty cool.  I really like that approach.   
Its sort of like how dsss used to work, except dsss contained a huge  
portion of the compiler in it.  At least with DIP11, the compiler is the  
driver, no need to maintain a separate "compiler".  It could be that DIP11  
needs more work to get a technically useful and implementable feature.

> What about linking with pre-compiled libraries, how would that work?  
> Currently the linking paths needs to be known before the compiler is  
> invoked. You would first need to compile without linking and then link,  
> or something like that. Assuming the compiler isn't changed to be able  
> to receive linker options form the external tool.

I'm assuming the linker path in dmd.conf would include some global or  
user-specific cache directory where pre-compiled libraries are  
downloaded.  Then the download tool puts the libraries in the right spot,  
so the path does not need adjusting.

> Note that I'm basing all this on what's written in the DIP (and what  
> you've said), as far as I know that's the current suggestion. But the  
> DIP can of course be enhanced and updated.

Yes, and much better than a DIP is a working solution, so it might very  
well be that Orbit wins :)  I certainly don't have the time or expertise  
to implement it...

-Steve