I agree with pretty much everything you've said. The bin.rs/lib.rs thing sounds good to me - would it walk into all sub directories to find crates, with inner crates being built first? Also IMO, as the person that chose the name pkg.rs for the build script file, I think you should change it to something like build.rs. I chose pkg.rs because it would always be required to define a package - this new scheme will not require a central metadata file.
The awesome thing about the new scheme is it still works as a purely functional package manager - library crates already work like that and we can continue to use the same logic that the current rustpkg scheme does to create a unique hash for binaries - just parse their link attribute and generate a unique name in the exact same fashion as libraries. This new scheme will simplify things greatly, which is awesome. For example, packages will be a word we never need to say again (sans the title "package manager" of course) as this will just make installing from a location just install a set of crates. Preferring and other functionality will now act on the installed crates themselves rather than the packages as a unit. I think we should try and figure out a way to remove the declarative API from the pkg.rs file. If we can just make the pkg.rs have the imperative API, that would simplify things even further. All that we need to move in that direction is a way to declare configuration to both about-to-be-built crates, and dependencies of crates. Currently (N.B. you can't actually do this yet, it was a planned patch) you declare configuration of dependencies like `#[pkg_dep(url = "git://github.com/brson/rust-sdl", cfg = "image mixer")];`. However, that only declares configuration to the pkg.rs script and not the crate files themselves. I think if we make `rustpkg build --cfg hello` pass the config flag to all crates being built (excluding their dependencies), `extern mod sdl(id = "github.com/brson/rust-sdl", cfg = "image mixer");` pass config flags to the dependency (N.B. the preferred way to do this would of course have a separate image and mixer crates in the same repo - a cool new capability - but it's just for example purposes) then we can make pkg.rs (or build.rs) only be needed for imperative things, such as compiling C code. The closer we can get to the build.rs being a real source file that can be compiled and run straight using rustc the better - that'll make Brian happy. Also, I'd like to start working on this. Is that OK or are you already looking into this?
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
