On 8/11/11 1:09 PM, Nick Sabalausky wrote:
"Steven Schveighoffer"<schvei...@yahoo.com> wrote in message
news:op.vz166yaieav7ka@localhost.localdomain...
On Thu, 11 Aug 2011 12:24:48 -0400, Andrew Wiley
<wiley.andre...@gmail.com> wrote:
On Thu, Aug 11, 2011 at 5:52 AM, Steven Schveighoffer
<schvei...@yahoo.com>wrote:
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.
This last bit doesn't really come into play here because you can already
ask
the compiler to output all that information. and easily use it in a
separate
program. That much is already done.
Yes, but then you have to restart the compiler to figure out what's next.
Let's say a source file needs a.d, and a.d needs b.d, and both a.d and b.d
are on the network. You potentially need to run the compiler 3 times just
to make sure you have all the files, then run it a fourth time to compile.
That's *only* true if you go along with DIP11's misguided file-oriented
approach. With a real package manager, none of that is needed. Your app just
says "I need packages X, Y and Z."
And X, Y and Z do the same for their requirements. This is all trivial
metadata. Emphasis on *trivial*. So, before DMD is ever invoked at all,
before one line of the source is ever even read, the package manager has
make sure that *everything* is *already* right there. No need to go off on
some goofy half-cocked "compile/download/complile/download" dance.
So DMD *never* needs to be invoked more than twice. Once to get the deps,
once to compile. Better yet, if DMD gets the
switch
--compile-everything-dammit-not-just-the-explicit-files-from-the-command-line,
then DMD never needs to be invoked more than *once*: Once to figure out the
deps *while* being intelligent enough to actually compile all of them.
It's difficult to get all dependencies when not all sources have been
yet downloaded.
Andrei
