"Nick Sabalausky" <a@a.a> wrote in message news:j219ck$3i0$1...@digitalmars.com... > "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. > >> And there is no parsing of the output data, > > Parsing the .deps file is extremely simple. RDMD does it with one regex. > Personally, I think even that is overkill. > > Better yet, with a switch to make DMD incorporate RDMD's --build-only > functionality, there is *still* no parsing of output data. > > So all in all, there is *nothing* that DIP11 does that can't be done > *better* by other (more typical) means. >
In other words, DIP11 just reinvents the wheel, poorly.