This fleshes out the io::file module a fair bit more, adding all of the functionality that I can think of that we would want. Some questions about the representation which I'm curious about: * I modified `FileStat` to be a little less platform-agnostic, but it's still fairly platform-specific. I don't want to hide information that we have, but I don't want to depend on this information being available. One possible route is to have an `extra` field which has all this os-dependent stuff which is clearly documented as it should be avoided. * Does it make sense for directory functions to be top-level functions instead of static methods? It seems silly to import `std::rt::io::file` and `std::rt::io::File` at the top of files that need to deal with directories and files. |
||
|---|---|---|
| .. | ||
| testsuite | ||
| api.rs | ||
| conditions.rs | ||
| context.rs | ||
| crate.rs | ||
| exit_codes.rs | ||
| installed_packages.rs | ||
| lib.rs | ||
| messages.rs | ||
| package_id.rs | ||
| package_source.rs | ||
| path_util.rs | ||
| README.txt | ||
| search.rs | ||
| sha1.rs | ||
| source_control.rs | ||
| target.rs | ||
| tests.rs | ||
| usage.rs | ||
| util.rs | ||
| version.rs | ||
| workcache_support.rs | ||
| workspace.rs | ||
Right now, commands that work are "build" and "clean".
`rustpkg build` and `rustpkg clean` should work
for example:
$ cd ~/rust/src/librustpkg/testsuite/pass
$ rustpkg build hello-world
... some output ...
$ rustpkg clean hello-world
-------------
the following test packages in librustpkg/testsuite/pass:
* hello-world
* install-paths
* simple-lib
* deeply/nested/path
* fancy-lib
It fails on the following test packages:
* external-crate (no support for `extern mod` inference yet)
and should fail with proper error messages
on all of the test packages in librustpkg/testsuite/fail
* no-inferred-crates