| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Previously, any package would match any other package ID when searching
using the rust_path_hack, so long as the directory had one or more crate
files in it. Now, rustpkg checks that the parent directory matches the
package ID.
Closes #9273
|
|
r? @brson
|
|
|
|
They're blocking a new snapshot and @catamorphism is on it.
|
|
as per #9112
Closes #9112
|
|
Treating a package as the thing that can have other packages depend on it,
and depends on other packages, was wrong if a package has more than one
crate. Now, rustpkg knows about dependencies between crates in the same
package. This solves the problem reported in #7879 where rustpkg wrongly
discovered a circular dependency between thhe package and itself, and
recursed infinitely.
Closes #7879
|
|
@catamorphism says he has a fix coming soon, so I didn't allocate an issue for
it. If it festers for more than a few days I'll open something up though.
|
|
|
|
For some reason, I thought it wasn't necessary to write the package_id
attribute (which rustc's filesearch checks when searching for a package)
if the package ID had a single component (like "foo") as opposed to multiple
components (like "foo/bar/quux"). This meant that
`extern mod quux = "an-awesome-library";` didn't work, even if an-awesome-library
existed in the RUST_PATH.
Fixed it.
|
|
While usage of change_dir_locked is synchronized against itself, it's not
synchronized against other relative path usage, so I'm of the opinion that it
just really doesn't help in running tests. In order to prevent the problems that
have been cropping up, this completely removes the function.
All existing tests (except one) using it have been moved to run-pass tests where
they get their own process and don't need to be synchronized with anyone else.
There is one now-ignored rustpkg test because when I moved it to a run-pass test
apparently run-pass isn't set up to have 'extern mod rustc' (it ends up having
linkage failures).
|
|
As per rustpkg.md, rustpkg now builds in a target-specific
subdirectory of build/, and installs libraries into a target-specific
subdirectory of lib.
Closes #8672
|
|
Install to the first directory in the RUST_PATH if the user set a
RUST_PATH. In the case where RUST_PATH isn't set, the behavior
remains unchanged.
Closes #7402
|
|
recursive dependencies
Closes #8524
|
|
Package IDs can now refer to a subdirectory of a particular source
tree, and not just a top-level directory with a src/ directory as its
parent.
For example, referring to the package ID a/b/c/d , in workspace W,
if W/src/a is a package, will build the sources for the package in
a/b/c/d (and not other crates in W/src/a).
Closes #6408
|
|
rustpkg now accepts most of rustc's command-line arguments and passes
them along to rustc when building or installing.
A few rarely-used arguments aren't implemented yet.
rustpkg doesn't support flags that don't make sense with rustpkg
(for example, --bin and --lib, which get inferred from crate file names).
Closes #8522
|
|
|
|
rustpkg now uses the workcache library to avoid recompilation.
Hooray!
|
|
|
|
In most cases this involved removing a ~str allocations or clones
(yay), or coercing a ~str to a slice. In a few places, I had to bind
an intermediate Path (e.g. path.pop() return values), so that it would
live long enough to support the borrowed &str.
And in a few places, where the code was actively using the property
that the old API returned ~str's, I had to put in to_owned() or
clone(); but in those cases, we're trading an allocation within the
path.rs code for one in the client code, so they neutralize each
other.
|
|
This commit adds a rustpkg flag, --rust-path-hack, that allows
rustpkg to *search* inside package directories if they appear in
the RUST_PATH, while *building* libraries and executables into a
different target directory.
This behavior is hidden behind a flag because I believe we only
want to support it temporarily, to make it easier to port servo to
rustpkg.
This commit also includes a fix for how rustpkg fetches sources
from git repositories -- it uses a temporary directory as the target
when invoking `git clone`, then moves that directory into the workspace
if the clone was successful. (The old behavior was that when the
`git clone` failed, the empty target directory would be left lying
around anyway.)
|
|
r=brson"
This reverts commit b8d1fa399402c71331aefd634d710004e00b73a6, reversing
changes made to f22b4b169854c8a4ba86c16ee43327d6bcf94562.
Conflicts:
mk/rt.mk
src/libuv
|
|
This overhauls `std::run` to instead run on top of libuv. This is *not* in a mergeable state, I've been attempting to diagnose failures in the compiletest suite. I've managed to find a fair number of bugs so far, but I still don't seem to be done yet.
Notable changes:
* This requires upgrading libuv. From the discussion on #6567, I took libuv master from a few days ago, applied one patch to fix process spawning with multiple event loops in libuv, and pushed to my own fork
* The build system for libuv has changed since we last used it. There's some extra checkout from a google build system which apparently does all the magic if you don't want to require autotools, and the google system just requires python. I updated the Makefile to get this build system and build libuv with it instead. This is untested on windows and arm, and both will probably need to see some improvement.
* This required adding some pipe bindings to libuv as well. Currently the support is pretty simple and probably completely unsafe for pipes, but you at least get read/write methods. This is necessary for capturing output of processes.
* I didn't redesign `std::run` at all, I simply tried to reimplement all the existing functionality on top of libuv. Some functions ended up dying, but nothing major. All uses of `std::run` in the compiler still work just fine.
I'm not quite sure how the rest of the runtime deals with this, but I marked process structures as `no_send` because the waiting/waking up has to happen in the same event loop right now. If processes start migrating between event loops then very bad things can happen. This may be what threadsafe I/O would fix, and I would be more than willing to rebase on that if it lands first.
Anyway, for now I wanted to put this up for review, I'm still investigating the corruption/deadlock bugs, but this is in an *almost* workable state. Once I find the bugs I'll also rebase on the current master.
|
|
Closes #6436
|
|
`rustpkg build` et al were only checking one directory up to see if it
was in a dir named "src". Ditch that entirely and instead check if the
cwd is descended from any of the workspace paths. Besides being more
intelligent about whether or not something is a workspace, this also
allows for package ids composed of multiple path components.
|
|
`target_library_in_workspace` is imported but unused:
~/rust/src/librustpkg/tests.rs:21:48: 21:75 warning: unused import [-W unused-imports (default)]
|
|
|
|
multiple workspaces
The test checks that rustpkg uses the first one, rather than complaining
about multiple matches.
Closes #7241
|
|
|
|
|
|
|
|
|
|
This necessitated some cleanup to how we parse library filenames
when searching for libraries, since rustpkg may now create filenames
that contain '-' characters. Also cleaned up how rustpkg passes the
sysroot to a custom build script.
|
|
This is a workaround for #8498
|
|
Get rid of special cases for names beginning with "rust-" or
containing hyphens, and just store a Path in a package ID. The Rust-identifier
for the crate is none of rustpkg's business.
|
|
This commit allows you to write:
extern mod x = "a/b/c";
which means rustc will search in the RUST_PATH for a package with
ID a/b/c, and bind it to the name `x` if it's found.
Incidentally, move get_relative_to from back::rpath into std::path
|
|
Seems to not work
|
|
this has been replaced by `for`
|
|
|
|
|
|
r? @graydon Package IDs can now be of the form a/b/c#FOO, where (if a/b/c is
a git repository) FOO is any tag in the repository. Non-numeric
tags only match against package IDs with the same tag, and aren't
compared linearly like numeric versions.
While I was at it, refactored the code that calls `git clone`, and segregated build output properly for different packages.
|
|
|
|
Just pass it directly to git, without prefixing it with tags/
|
|
Package IDs can now be of the form a/b/c#FOO, where (if a/b/c is
a git repository) FOO is any tag in the repository. Non-numeric
tags only match against package IDs with the same tag, and aren't
compared linearly like numeric versions.
While I was at it, refactored the code that calls `git clone`,
and segregated build output properly for different packages.
|
|
|
|
|
|
Re-enabling these when the ephemeral failures are fixed is filed as
issue #7956.
|
|
os::list_dir_path.
|
|
`rustpkg build`, if executed in a package source directory inside
a workspace, will now build that package. By "inside a workspace"
I mean that the parent directory has to be called `src`, and rustpkg
will create a `build` directory in .. if there isn't already one.
Same goes for `rustpkg install` and `rustpkg clean`.
For the time being, `rustpkg build` (etc.) will still error out if
you run it inside a directory whose parent isn't called `src`.
I'm not sure whether or not it's desirable to have it do something
in a non-workspace directory.
|
|
merged.
|
|
|
