This commit won't be quite as useful until I implement RUST_PATH and
until we change `extern mod` to take a general string instead of
an identifier (#5682 and #6407).
With that said, now if you're using rustpkg and a program contains:
extern mod foo;
rustpkg will attempt to search for `foo`, so that you don't have to
provide a -L directory explicitly. In addition, rustpkg will
actually try to build and install `foo`, unless it's already
installed (specifically, I tested that `extern mod extra;` would
not cause it to try to find source for `extra` and compile it
again).
This is as per #5681.
Incidentally, I changed some driver code to infer the link name
from the crate link_meta attributes. If that change isn't ok, say
something. Also, I changed the addl_lib_search_paths field in the
session options to be an @mut ~[Path] so that it can be modified
after expansion but before later phases.
Most of the relevant information can be found in the commit messages.
r? @brson - I just wanted to make sure the make changes aren't completely bogus
This would close#2400, #6517, and #6489 (although a run through incoming-full on linux would have to confirm the latter two)
mentioned in #2625.
This change makes the module more oriented around
Process values instead of having to deal with process ids
directly.
Apart from issues mentioned in #2625, other changes include:
- Changing the naming to be more consistent - Process/process
is now used instead of a mixture of Program/program and
Process/process.
- More docs/tests.
Some io/scheduler related issues remain (mentioned in #2625).
...and cleanup, making how we handle version numbers more rational
(specifically, not passing in a versioned name to rustc
with the -o flag), and removing unused code.
This patch implements package IDs like
github.com/catamorphism/test-pkg.
To support such package IDs, I changed the PkgId struct to contain
a LocalPath and a RemotePath field, where the RemotePath reflects
the actual URL and the LocalPath reflects the file name of the cached
copy. Right now, the only difference is that the local path doesn't
contain dashes, but this will change when we implement #6407.
Also, PkgIds now have a short_name field -- though the short name
can be derived from the LocalPath, I thought it was cleaner not to
call option::get() wantonly.
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
I just had `git apply` fix most of them and then did a quick skim over the diff to fix a few cases where it did the wrong thing (mostly replacing tabs with 4 spaces, when someone's editor had them at 8 spaces).
In rustpkg, pass around sysroot; in rustpkg tests, set the sysroot
manually so that tests can find libcore and such.
With bonus metadata::filesearch refactoring to avoid copies.
The install command should work now, though it only installs
in-place (anything else has to wait until I implement RUST_PATH).
Also including:
core: Add remove_directory_recursive, change copy_file
Make copy_file preserve permissions, and add a remove_directory_recursive
function.
rustpkg now searches for package directories in ./src rather than
in . . I also added a rudimentary RUST_PATH that's currently
hard-wired to the current directory. rustpkg now uses src/, lib/,
and build/ directories as described in the manual.
Most of the existing test scenarios build now; the README file
(in a separate commit) explains which ones.
This moves all the basic random value generation into the Rand instances for
each type and then removes the `gen_int`, `gen_char` (etc) methods on RngUtil,
leaving only the generic `gen` and the more specialised methods.
Also, removes some imports that are redundant due to a `use core::prelude::*`
statement.
This is a test file containing examples of commands that should
succeed. When we write the test runner, we will have to figure
out how to automate them.
1. Implemented the `clean` command
2. The methods implementing rustpkg commands all returned `bool`.
Since most of not all of the error situations seem unrecoverable,
I changed the methods to return unit (and also stubbed out several
more methods that were assuming a package script existed, to be
re-implemented in the future)
There's no test runner for rustpkg yet; just sketching out a few
basic test scenarios. pass/ contains packages that should compile
successfully, whereas fail/ contains packages that should fail
to build.
1. Fail when there's no package script and no crates named
main.rs, lib.rs, bench.rs, or test.rs.
2. Inject the crate link_meta "name" and "vers" attributes, so
that the output file gets named correctly in the library case.
3. Normalize '-' to '_' in package names.
r? @graydon
Pulled out tests into their own modules inside the files they test,
as per the draft style guidelines.
Started a new module, path_util, for utility functions to do with
paths and directories.
Changed default_dest_dir to use a condition and return Path
instead of Option<Path>.
Pulled out tests into their own modules inside the files they test,
as per the draft style guidelines.
Started a new module, path_util, for utility functions to do with
paths and directories.
Changed default_dest_dir to use a condition and return Path
instead of Option<Path>.
r? @graydon This is preliminary work on bringing rustpkg up to conformance with #5679
and related issues.
This change makes rustpkg infer a package ID from its containing directory,
instead of requiring name and vers attributes in the code. Many aspects of it
are incomplete; I've only tested one package (see README.txt) and one command,
"build". So far it only works for local packages.
I also removed code for several of the package commands other than "build",
replacing them with stubs that fail, since they used package IDs in ways that
didn't jibe well with the new scheme. I will re-implement the commands one
at a time.
This is preliminary work on bringing rustpkg up to conformance with #5679
and related issues.
This change makes rustpkg infer a package ID from its containing directory,
instead of requiring name and vers attributes in the code. Many aspects of it
are incomplete; I've only tested one package (see README.txt) and one command,
"build". So far it only works for local packages.
I also removed code for several of the package commands other than "build",
replacing them with stubs that fail, since they used package IDs in ways that
didn't jibe well with the new scheme. I will re-implement the commands one
at a time.
I believe this patch incorporates all expected syntax changes from extern
function reform (#3678). You can now write things like:
extern "<abi>" fn foo(s: S) -> T { ... }
extern "<abi>" mod { ... }
extern "<abi>" fn(S) -> T
The ABI for foreign functions is taken from this syntax (rather than from an
annotation). We support the full ABI specification I described on the mailing
list. The correct ABI is chosen based on the target architecture.
Calls by pointer to C functions are not yet supported, and the Rust type of
crust fns is still *u8.
Two changes:
- The first fixes an inconsistency in coherence whereby extension methods were added to the inherent methods table, but only in cross-crate scenarios. This causes some minor fallout in tests and so forth. In one case (comm) I added inherent and trait methods so as to avoid the need to import traits like `GenericPort` just to use a port.
- The second makes objects not implement the associated trait, as discussed in #5087.
r? @pcwalton
