[dev-servo] Submodule split
Just FYI, I've split out GFX and all its dependencies (image, resource, text, most of util) into the servo-gfx crate as a submodule. This means that if you're just modifying layout you can avoid rebuilding some ~5000 lines of code of the graphics module. The resource crate and util should further be split out; clearly the resource manager does not belong in the graphics crate. Possibly we should split out layout as well. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Submodule split
In what sense are any of these things (outside of utility-like data structures) reusable? Or, is it possible to swap out one implementation for another? Is this just a workaround for lacking incremental compilation? Do we want to encourage modularity at the task or functionality boundaries? Almost any new layout features in the near future will require changes to the display list machinery, in addition to changes in other submodules such as css and platform APi bindings. As submodules stand now, it's getting quite hard to understand the project history, as it's scattered across 30 git logs. On Nov 11, 2012, at 19:47 , Patrick Walton wrote: > Just FYI, I've split out GFX and all its dependencies (image, resource, text, > most of util) into the servo-gfx crate as a submodule. This means that if > you're just modifying layout you can avoid rebuilding some ~5000 lines of > code of the graphics module. > > The resource crate and util should further be split out; clearly the resource > manager does not belong in the graphics crate. Possibly we should split out > layout as well. > > Patrick > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Submodule split
On 11/11/12 8:25 PM, Brian Burg wrote: In what sense are any of these things (outside of utility-like data structures) reusable? Or, is it possible to swap out one implementation for another? Is this just a workaround for lacking incremental compilation? Do we want to encourage modularity at the task or functionality boundaries? I'm not sure how reusable they will be in practice; the probability of reuse drops as you go up toward the root from the leaves of the dependency tree (for example, servo- modules will probably realistically never be used outside Servo). The crate division instead serves two purposes: (1) It encourages modularity within the codebase to keep things clean and understandable. It's easier to understand portions of the code in isolation when the codebase is split out into large chunks lacking cyclic dependencies. I don't want the dependency graph of the codebase to approach the complete graph over time the way Gecko (and as I understand it WebKit) did. (2) It allows incremental recompilation. To be honest, I don't know if incremental recompilation in Rust below the crate level is ever going to be feasible. It's a very tricky problem because of cyclic dependencies, monomorphization, inlining, structural types, and so forth. Most ahead-of-time statically-compiled languages either (a) don't allow mutually recursive modules at all (ML); (b) greatly restrict their use (Haskell compilers, Go); or (c) don't even try to support incremental recompilation (C++). I'm not confident that we're going to be able to do any better than these languages did, especially since our name resolution semantics are extremely expressive. It's really not so bad though; large projects just need to be vigilant about breaking themselves up into crates to achieve good compilation times. This really isn't any different of a story than that of most other languages; it's just that modules in Rust are so expressive that going back to DAG semantics feels like a bummer. That said, you do have a good point about the project history; perhaps it isn't worth it to make the Servo modules into submodules if we don't think they have any use to the rest of the Rust community. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Submodule split
On Sun, Nov 11, 2012 at 8:25 PM, Brian Burg wrote: > As submodules stand now, it's getting quite hard to understand the project > history, as it's scattered across 30 git logs. > Perhaps I am missing something here but is it necessary to have only one rust create per git repository? Must they be split into multiple repositories? If the goal is to reduce build time and prevent accidental dependencies then why must git be involved? -Rob > (accidentally forgot to reply-all, sorry Brian!) ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
