DIP11

[Jacob Carlborg]

On 2011-08-11 17:45, Steven Schveighoffer wrote:
> 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...)

In that case that needs to be said in the DIP.

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

Yes, exactly.

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

It sounds pretty cool but the question is how well it would work and if 
the right thing to do.

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

Assuming that, you would still need to link with the libraries. I don't 
know if pragma(lib, ""); could work but I don't like that pragma in 
general. It's platform dependent and I'm not sure if it works for 
dynamic libraries. I don't think GDC implements it.

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

I guess we just have to see what happens. I will at lease continue 
working on Orbit.

-- 
/Jacob Carlborg