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 and so on.
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.
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.
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.
-- /Jacob Carlborg
