On Apr 7, 2013, at 3:30 AM, Patrick Walton wrote: > On 4/6/13 8:14 PM, Ben Kelly wrote: >> One of my motivations for looking at this was the long build times > required to compile larger crates. For example, if you touch a single > file in libstd then rustc currently has to rebuild the entire crate > which takes 45 seconds on my laptop: > > Unfortunately, this isn't so straightforward. Crates can have mutually > recursive definitions, so compiling one module requires at least scanning all > the other modules for type and function definitions. Because of this, > creating the dependency graph within a crate is rather difficult...
So I guess this is where I was hoping tup might help a bit since it will automatically determine dependencies by monitoring file system reads and writes. And it seems while circular dependencies may exist in source files, the actual build graph could still be acyclic: foo.rs references bar.rs bar.rs references foo.rs foo.o depends on foo.rs and bar.rs bar.o depends on foo.rs and bar.rs This would result in the source files being scanned multiple times, of course. I guess its unclear to me if the penalty for this outweighs recompiling everything whenever there is a change. With javac the jvm startup speed tilts things towards just recompiling everything, but with a compiled binary like rustc it seems it might make sense to go the other direction. Of course, its likely I'm very confused here. :-) > I would recommend trying to break your crates up into smaller crates. > Eventually it may be possible to recompile individual modules separately, but > it will not be trivial. > > The good news is that we're focusing on improving raw compiler > performance—the work that Graydon and I are doing should help with this. Awesome. Thanks! Ben _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
