On 06/01/2013 2:57 PM, Tim Chevalier wrote: >> Personally, I think our time would be better spent making it easy to break >> large projects up into multiple finer-grained crates. We should be able to >> tell cargo and/or the work-in-progress `fbuild` workalike to compile a crate >> and rebuild all of its dependent crates (if they were modified) in one >> command. >> >> This strikes me as more reliable than incremental compilation, because crate >> structure enforces a DAG. What worries me with incremental compilation is >> that we'll do a lot of work to make it work, then we'll discover that in >> practice intra-crate dependencies are so intertwined that most changes >> result in a full rebuild anyway. > > I think that it would be good to do an experiment to see whether or > not that worry is justified, which is to say, printing out what the > dependency graph is and seeing how modular is for rustc and perhaps > other Rust crates.
In terms of immediate project scheduling, getting the build / package system under control is higher priority as it's the main gate on community involvement / growing the library ecosystem / scaling up servo work. It'll also make it easier to develop patches to (say) libstd without always cycling through a triple-rustc-bootstrap. And easier to get started by just downloading a prebuilt librustllvm. &c &c. In the longer term of parallelizing rustc as much as possible, you're right that formalizing intra-crate item dependency is an essential first step. It's just a matter of priority-making. -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
