After cloning the repository, one should write the following commands:

git submodule init
git submodule update
make

Is that correct? (I don't know because there are no instructions)

cargo build -u --verbose results in this error on the following step:

   Compiling graphics v0.0.0 (https://github.com/pistondevelopers/rust-graphics)
Executing `git rev-parse master` failed

Caused by:
  Executing `git rev-parse master` failed

Caused by:
  Could not execute process `git rev-parse master` (status=never executed)

Caused by:
  no such file or directory

I have also opened an issue for rust-graphics: PistonDevelopers/graphics#553

Maybe add a [[test]] to the Cargo manifest format?

Otherwise provide some way for [[bin]] to flag itself as a test and parse the --test flag to rustc.

The first option would seem nicer imho.

Cargo breaks when trying to build it.

I would like to test it and give feedback.

The dependency:

[dependencies.iui]

path = "../"

causes cargo to fail and print the error An unknown error occurred.

From https://news.ycombinator.com/item?id=7938488

It'd be nice if we could make sure that TOML will be actually stable, rather than semi-abandonware-stable.

@mojombo, what are your thoughts here?

If .cargo/config is missing, or if the dependency has an ill-formatted Cargo.toml, one is met with this error message:

task '<main>' failed at 'invalid num of results 0', src/cargo/core/resolver.rs:31

A simple Cargo.toml with one dependency is enough to trigger the error. If the dependency is added via .cargo/config's path option, then if the dependency's Cargo.toml project name and lib name are not equal you are met with the same error.

The following code https://github.com/carlhuda/cargo/blob/master/src/bin/cargo-read-manifest.rs#L47-L49 can be re-written as:

for err in decoder.error.iter() {
    fail!("Error: {}", err);
}

or

decoder.error.map(|err| fail!("Error: {}", err));

From http://www.reddit.com/r/rust/comments/28xyrc/cargo_alpha_is_here/cifnlkg

Would be nice to be consistent with make, and while I prefer Cargo.toml, apparently a bunch of people feel the other way.

[package]

name = "test"
version = "0.0.0"
authors = []

[[lib]]

name = "test"

with src/test.rs empty.

If this is in a valid UTF-8 directory, then cargo build works flawlessly. If this is in an invalid UTF-8 directory (creatable by, e.g., mkdir $(echo -e '\xff') in Bash), then cargo build is rather upset:

  Compiling test v0.0.0 (file:/home/huon/projects/test-rust/�)
error: could not write output: Error opening output file '/home/huon/projects/test-rust/�/target/test.o': No such file or directory
Could not execute process `rustc src/test.rs --crate-type lib --out-dir /home/huon/projects/test-rust/�/target -L /home/huon/projects/test-rust/�/target -L /home/huon/projects/test-rust/�/target/deps` (status=101)

Due to the \ character, windows paths are both invalid URLs as well as causing all the tests to fail on windows. This can be closed when we no longer jankily replace \ with / and also when the tests pass on windows.

Marked in the code with a fixme.

I believe this would either require replacing some of the #[deriving(Decodable)] instances in util::toml with manual ones, or fixing rust-lang/rust#15036.

This is probably a no brainer, but I thought I'd drop it in here as a yes-please feature request.

I just discovered that with bower and npm if you install a package into a local directory scope (eg. bower install moment) with a particular flag (in this case bower install moment -S) it not only installs the moment recent version of the package into the local folder; it updates the manifest file automatically:

{
  "name": "configtool",
  "version": "0.1.0",
  "dependencies": {
    "underscore": "1.5.2",
    "angular": "1.2.3",
    "angular-resource": "1.2.3",
    "angular-sanitize": "~1.2.3",
    "momentjs": "~2.5.1" // <---- This gets automatically added 
  }
}

This is a really lovely workflow to use, I thought I'd drop it in here as a feature request.

Following the install instructions on mac I get the following error on latest rust build:

rustc  -L libs/hammer.rs/target -L libs/rust-toml/lib --out-dir target src/cargo/lib.rs
src/cargo/core/version_req.rs:289:53: 289:63 error: cannot use `self.state` because it was mutably borrowed
src/cargo/core/version_req.rs:289                     _ => return self.flush(idx + 1, self.state)
                                                                                      ^~~~~~~~~~
src/cargo/core/version_req.rs:282:9: 293:20 note: in expansion of next!
src/cargo/core/version_req.rs:303:13: 303:21 note: expansion site
src/cargo/core/version_req.rs:289:33: 289:37 note: borrow of `*self` occurs here
src/cargo/core/version_req.rs:289                     _ => return self.flush(idx + 1, self.state)

These commands all have no output

• ./target/cargo --help
• ./target/cargo help
• ./target/cargo foobar
• ./target/cargo-compile --help

As it is the website gives a small tutorial but doesn't say where and how to get cargo, I think it should at least have a link to this github prominently somewhere.

It should also give simple build instructions (as long as binary versions are not available), say which versions of rust are needed etc...

[project]

name = "glfw-rs"
version = "0.0.1"

[[lib]]

build = "build.sh"
name = "foo"

for example, will silently ignore the unused build key.

In Piston, we have a pattern where in order to decouple dependencies and achieve maximum independence, we split up a interface and it's implementation(s) into multiple projects.

The interface does not depend on the implementations, but the opposite is true. For example:

• My App
  • piston
  • some_piston_backend
    • piston

What we would really like is a way to make sure that the two piston repositories in the tree are the exact same version. A user could theoretically pick piston-3.0 and some_piston_backend-1.0 (that depends on piston-1.0).

I'm not sure what resolution strategy Cargo is planning on using for this, but I would like the option as a maintainer of piston to be able to say "THERE CAN ONLY BE ONE" and fail at the cargo package fetching stage. Anything else would either run (and have terrible bugs) or fail at compile time with confusing error messages.

Edit: A more detailed example of what could go wrong: PistonDevelopers/piston#430

May be premature, but it would be useful to have a few example Cargo.tomls lying around. Or perhaps one full one with documentation as to what's going on.

For now, this can be found through tests/test_cargo_compile.rs

On Linux, the state-of-the-art mechanism for linking to native libraries is pkg-config, replacing decades of hard-coding. On other platforms, there is no solution easier than using pkg-config, although it is most likely not installed by default there.

pkg-config supports both static and dynamic linking, although there are a lot of in-the-wild .pc files that don't support static linking properly.

Here's an example of using pkg-config in a (currently non-Cargo) Rust project, including the "rpath" step for libraries installed in non-system directories: https://github.com/o11c/termkey-rs/blob/master/Makefile

Updated description

Arbitrary flags cannot be passed through to the compiler.

Original Description

-O has to be the default.

https://github.com/carlhuda/cargo/blob/master/DESIGN/MANIFEST.md

It says the default library file will be src/<package-name>.rs

In README it says src/lib.rs

I was trying to port https://github.com/csherratt/ovr-rs over to cargo, but I didn't want to break the current build as there are a bunch of dependencies. So I tried using this Cargo.toml script:

[package]

name = "ovr-rs"
version = "0.1.0"
authors = [
        "Colin Sherratt",
        "Erick Tryzelaar"
]

build = "sh -c './configure && make lib/libovr.a && mkdir target && cp lib/libovr.a target/'"

[[lib]]

name = "ovr-rs"
path = "src/oculus-vr/lib.rs"

[[bin]]
name = "oculus-info"
path = "src/oculus-info/main.rs"

[dependencies.cgmath-rs]

git = "https://github.com/bjz/cgmath-rs.git"

Unfortunately it didn't work. The reason is that ops::cargo_rustc::compile_custom is trying to split the string on spaces and pass them to the first argument, but this doesn't play well with sh -c. Instead, I'd suggest changing build from being a String to being a Vec<Vec<String>>. The outer vec allows you to run multiple commands, and the inner vec would allow you to have precise control over the arguments. So the prior example would be instead written as:

...
build = [
    ["./configure"],
    ["make", "lib/libovr.a"],
    ["/bin/mkdir", "target"],
    ["/bin/cp", "lib/libovr.a", "target/"]
]
...

The alternative would be to just have compile_custom shell out to /bin/sh, but the downside with that is then you have to deal with shell escaping, which can become a mess.

cc @csherratt.

Updated description

make test should ensure no binaries are checked in.

Original Description

repo contains a 4MB binary

https://github.com/rust-lang/cargo/blob/master/tests/tests

cargo is still young enough that this could possibly be rebased out, to keep the repository slim. (Just removing it in a normal commit will not remove it from the history, meaning it will hang around in .git forever: this would need some pickaxing/history modification.)

[package]

name = "test"
version = "0.0.0"
authors = []

[dependencies.test]

path = "."

[[lib]]

name = "test"

with src/test.rs:

task '<main>' has overflowed its stack

(This fails with a nonrelative path too.)

Please don't use the TOML format, it was designed by @mojombo, the GitHub co-founder responsible for the recent sexism and harassment scandal.

[project]                        

name = "jba"                     
version = "0.0.1"                
authors = ["[email protected]"]   

[[bin]]                          

name = "jba"                     

If the file src/jba.rs doesn't exist, the error message emitted doesn't have a newline at the end.

After updating rust, building cargo by running make fails due to not rebuilding dependencies:

mkdir -p target
rustc  -L libs/hammer.rs/target -L libs/toml-rs/build --out-dir target src/cargo/lib.rs
src/cargo/lib.rs:14:1: 14:21 error: found possibly newer version of crate `std` which `hammer` depends on
src/cargo/lib.rs:14 extern crate hammer;
                    ^~~~~~~~~~~~~~~~~~~~
src/cargo/lib.rs:14:1: 14:21 note: perhaps this crate needs to be recompiled?
src/cargo/lib.rs:14 extern crate hammer;
                    ^~~~~~~~~~~~~~~~~~~~

This seems like a job for cargo!

We're trying to build a project with the following Cargo.toml: https://gist.github.com/Denommus/a6d5be6e28ac29546b9e

But it fails with 'Temporarily, Cargo only supports a single result for a dependency'.

We think it's an issue with multiple repositories of the same user, because if we use from other users it compiles fine.

Is cargo parsing the URL wrongly and thinking that the same user is the same repo?

This is needed for packaging on some platforms, since MIT has a custom copyright line.

At the moment it only says make.

I had [email protected]:Foo/bar.git as a git dependency and Cargo crashed with this error:

task '<main>' failed at 'called `Result::unwrap()` on an `Err` value: url: Invalid character in scheme.', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libcore/result.rs:545

Obviously it should reject the url, but not in this manner.

Feature request/idea. Implement:

 $ cargo cult

Which would create a new project/module from a template.

when writing version = "x.y" in stead of version = "x.y.z" in the toml file,cargo crashed with message:
task '<main>' failed at 'called``Option::unwrap()``on a``None``value', /build/rust-git/src/rust/src/libcore/option.rs:265

Right now, if you make a Cargo.toml, and you mkdir src, and then you cargo build:

$ cargo build
  Compiling guessing_game v0.1.0 (file:/home/steve/tmp/guessing_game)
error: couldn't read src/guessing_game.rs: couldn't open file (no such file or directory (No such file or directory); path=src/guessing_game.rs; mode=open; access=read)

@wycats would like this to improve. 😄

This is kinda out there, but: https://news.ycombinator.com/item?id=7938551

Hello, I am new to Rust and was looking around for the rustpkg but found it was deprecated. Although the reason I looked around was unrelated to rustpkg/carge and dependency manager, I am working on a dependency manager called Adept you see so I posted on the rust-dev mailing list and got redirected to this project on Github.

I would love to learn more about your design, but I think you might be interested in Adept's design as well. :)

I was wondering if you had a mailing list where things like this could be discussed?

Best regards,
Fredrik

Hi,

I use Maven every day, and one command I use a lot is mvn clean to do a general cleanup of my project, and remove the generated "binaries" and code in some cases, or any other specific cleanup that the current project needs.

I think it will be very useful to have one for cargo (for example, to use in CI) and for now it can just be rm -rf target as (AFAIK) cargo just deals with a single target directory.

I have a top level depencency on https://github.com/PistonDevelopers/rust-graphics.git and a transitive dependency on https://github.com/pistondevelopers/rust-graphics.

Note the different capitalization and lack of .git.

I get the error

An unknown error occurred                                            

Caused by:                                                           
  Temporarily, Cargo only supports a single result for a dependency  

This error had me scratching my head for a while, but I eventually managed to locate what was actually happening.

A better error message in this case would have helped me out a bunch. Something like:

For the crate rust-graphics there are two listed dependencies:
    https://github.com/PistonDevelopers/rust-graphics.git
    https://github.com/pistondevelopers/rust-graphics

Consider https://github.com/cmr/hgl-rs/blob/master/.travis.yml. It installs glfw-rs manually just so it can be available when building the examples, but otherwise nothing depends on them.

This is a concern due to the lack of signaling reoccurring breaking phases after 1.0.0. Modern open source is done in continuous releases, while semantic versioning was designed for another use case. I suggest the rules should be modified in order to allow reoccurring breaking phases.

For example, a single change of an argument from &T to &mut T will require incrementing the major version after 1.0.0. This will not work well with Github where any commit might break the API.

One solution, which is mostly compatible, is to change the minor version to Angular Versioning.

This allows minor versions from [0, 360) to have breaking changes. For example 1.0.0 will be considered Alpha and 1.360.0 will be the release. In the range 1.360.0 and above the rules can be enforced.

As I'm writing this, the latest version of cgmath-rs compiles without errors for me when built manually (git clone https://github.com/bjz/cgmath-rs.git etc.). Cargo however seems to download an older version that fails to compile. Since I have not specified a version of cgmath-rs in my project, I'm assuming this is a bug. A minimal Cargo.toml which replicates this bug:

[package]

name = "testproject"
version = "0.0.0"
authors = [ "bachm" ]

[[lib]]

name = "testproject"

[dependencies.cgmath-rs]

git = "https://github.com/bjz/cgmath-rs.git"

Consider https://github.com/sfackler/rust-phf/. It ships two crates: the compiler plugin, and the runtime support. It needs to supply two libraries to projects that depend on it.

Consider https://github.com/bjz/gl-rs/. It has two components, the binding generator, and the generated bindings. It needs to supply a library and a binary to projects that depend on it.

cargo-lite solved all of these usecases with the concept of "subpackages". You gave it a list of directories, and it would look in those for a manifest, execute them, and then procede to finish executing the top-level manifest. It still didn't offer any way to depend on a sub-package directly; it's just a way of organizing a repo.

For cargo, I think it is more appropriate to specify multiple [[lib]] or [[bin]] sections. One useful extension might be:

[[lib.phf_mac]]
[[lib.phf]]

Another possibility:

[[lib]]
path = "src/phf.rs"
[[lib]]
path = "src/phf_mac.rs"

Add .vagrant to .gitignore as these files shouldn't be part of repository and remove unnecessary files

Updated Description

The path field should be documented for [[lib]] and [[bin]]

Original Description

Allow specifying the source file that should be built

Requiring a given source layout isn't the best, IMO. Rather than:

[[lib]]

name = "foo"

which would look in src/foo.rs, also allow:

[[lib]]

src = "src/foo/lib.rs"

Which can make sense when a repo is large or complex.

Hi,
I'm having trouble building Cargo:

λ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C libs/hammer.rs
rustc src/hammer.rs --out-dir target --crate-type=rlib
src/usage.rs:7:12: 7:21 error: unknown `deriving` trait: `PartialEq`
src/usage.rs:7 #[deriving(PartialEq, Clone, Show)]
                          ^~~~~~~~~
src/hammer.rs:85:18: 85:27 error: unknown `deriving` trait: `PartialEq`
src/hammer.rs:85 #[deriving(Show, PartialEq)]
                                  ^~~~~~~~~
src/hammer.rs:125:18: 125:27 error: unknown `deriving` trait: `PartialEq`
src/hammer.rs:125 #[deriving(Show, PartialEq)]
                                   ^~~~~~~~~
src/hammer.rs:131:18: 131:27 error: unknown `deriving` trait: `PartialEq`
src/hammer.rs:131 #[deriving(Show, PartialEq)]
                                   ^~~~~~~~~
src/hammer.rs:196:30: 196:40 error: unknown `deriving` trait: `PartialOrd`
src/hammer.rs:196 #[deriving(Clone, PartialEq, PartialOrd, Hash, Show)]
                                               ^~~~~~~~~~
src/hammer.rs:196:19: 196:28 error: unknown `deriving` trait: `PartialEq`
src/hammer.rs:196 #[deriving(Clone, PartialEq, PartialOrd, Hash, Show)]
                                    ^~~~~~~~~
error: aborting due to 6 previous errors
make[1]: *** [target/libhammer-e1cb8171-0.0.rlib] Error 101
make: *** [libs/hammer.rs/target/libhammer-e1cb8171-0.0.rlib] Error 2

Rust is version 0.10 installed with home-brew on OSX 10.9.

Something like cargo-init to bootstrap a new project would be very nice (mainly creating the toml file if it does not exist and maybe other flags in the future)

I think it should not create the hello world example when you specify a library.

We use Rust-Empty to generate the Cargo.toml and need to delete the 'main.rs' file each time.

https://github.com/carlhuda/cargo/blob/master/DESIGN/MANIFEST.md

It says bin/*.rs should contain the source code of the executable.

Normally, a bin/ folder contains the executable and the required files to run.
The content of the bin/ folder is copyable to any other folder on the same machine.
It may be target specific and only work for that machine.

Example:

1. Cloning repository.
2. ./configure
3. make
4. Copying the content of the bin/ folder.

When I see bin/ I read 'binaries' and believes it will contain the binaries required to run the application.

http://crates.io/ should include a link to https://github.com/rust-lang/cargo/ , and/or instructions on how to obtain and build cargo itself. If this link exists already, I missed it.