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