"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:it9dt7$16fs$1...@digitalmars.com... > On 06/14/2011 09:29 PM, Nick Sabalausky wrote: >> "Adam D. Ruppe"<destructiona...@gmail.com> wrote in message >> news:it93ah$ekb$1...@digitalmars.com... >>>> After the initial "gather everything and >>>> build" build, all it would ever have to do is exactly what RDMD >>>> already does right now: Run DMD once to find the deps, check them >>>> to see if anything needs rebuilt, and if so, run DMD the second >>>> time to build. >>> >>> Does rdmd handle cases where the dependencies have dependencies? >>> >>> Suppose app.d imports foo.d which imports bar.d >>> >>> dmd app.d >>> can't find module in foo.d >>> >>> retry: >>> >>> dmd app.d foo.d >>> can't find module bar.d >>> >>> try again: >>> >>> dmd app.d foo.d bar.d >>> >>> success. >>> >>> >>> Is it possible to cut out any one of those steps without caching >>> that third dmd line? Until you try to compile foo.d, it can't >>> know bar.d is required... >> >> RDMD never needs to invoke DMD more than twice. Once to find "all" the >> dependencies, and once to do the actual compile. When DMD is run to find >> a >> file's dependencies, it finds the *entire* dependency graph, not just one >> step of it. > > It can do so because all files are present. The remote tool can't do that. >
Right. All I'm saying is: 1. The remote tool *can* do that **after** the first build. 2. On the first build, the number of times DMD needs to be invoked is fairly limited. As far as finding deps goes (and not counting any special lib-specific setup steps), the upper bound is 1+(number of libs needed). Of course, that's if you do things one-library-at-a-time. If you try to do things one-file-at-a-time (which is of dubious benefit), *then* the number of DMD invocations would explode.
