On Thu, 11 Aug 2011 10:47:36 -0400, Jacob Carlborg <d...@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
