I am using the include_bytes! macro to compile a GLSL shader into a rust program. It seems that Cargo is unaware of this however: when I modify just the shader file and test it with cargo run the updated file is not compiled in. Manually touching the .rs file that includes the shader does work.
Do I need to add something to my Cargo.toml to explictly state this dependency?
Version info:
$ rustc --version && cargo --version
rustc 1.0.0-nightly (ecf8c64e1 2015-03-21) (built 2015-03-22)
cargo 0.0.1-pre-nightly (e689383 2015-03-16) (built 2015-03-16)
This has been fixed in rustc: https://github.com/rust-lang/rust/pull/24423
Cargo has no way currently to add a file to the list of 'watched' files for changes. It won't know about files included with include_bytes! because that would involve special-casing that macro specifically.
Related
I have installed both nightly and stable rust toolchains and make some -Z ... compile flags for nightly, but the stable rust can't recognize it and stops compiling; is there a way or a cargo directive to conditionally switch between nightly/stable rust compiler.
In .cargo/config.toml file
[build]
rustflags = [
"-C...",
"-Z...",
]
For nightly rust read -Z and -C flags, for stable rust only read -C or ignore -Z completely. So that, we can use cargo +stable/+nightly build without modify config.toml file every time.
Thanks Ruster ~
I don't think it's possible to specify rustc unstable feature inside config.toml but you can specify cargo unstable feature. It could be nice to have.
You could create a "nightly" directory:
cd my_rust_project
mkdir my_nightly_project
cd my_nightly_project
rustup override set nightly
Then using merge feature of config file of cargo you create you can override the global config using a my_nightly_project/.cargo/config.toml file.
Consider using alias instead.
What is the difference between cargo new <project_name> --bin and cargo new <project_name>?
It seems both commands make exactly the same project; all components are consistent.
I think --bin stands for "binary", but I don't know when to use this option or not.
There is no difference between cargo new and cargo new --bin. From First Steps with Cargo, emphasis mine:
To start a new package with Cargo, use cargo new:
$ cargo new hello_world
Cargo defaults to --bin to make a binary program. To make a library, we would pass --lib, instead.
Likewise, Cargo's command line help tells you the same thing. From cargo new --help, with some irrelevant lines removed:
% cargo new --help
OPTIONS:
--bin Use a binary (application) template [default]
--lib Use a library template
See also
Why does `cargo new` create a binary instead of a library?
What is the difference between library crates and normal crates in Rust?
I have a basic rust/cargo project with a single main file and some basic dependencies. The cargo build command works fine when the target is not specified (I am using windows so it builds to windows), but when I try to cross compile the program to linux using cargo build --target=x86_64-unknown-linux-gnu or cargo build --target=x86_64-unknown-linux-musl, the process fails with the following error: linker 'cc' not found.
Does anyone have an idea how to get around this? Is there a specific linker I need to install?
Thanks.
I've just figured it out.
It turns out you need to tell cargo to use the LLVM linker instead. You do this by creating a new directory called .cargo in your base directory, and then a new file called config.toml in this directory. Here you can add the lines:
[target.x86_64-unknown-linux-musl]
rustflags = ["-C", "linker-flavor=ld.lld"]
Then building with the command cargo build --target=x86_64-unknown-linux-musl should work!
When using serde in stable as recommended by the respective blog post, one will have to use the built-in include! macro to pull in a file generated by serde-codegen.
The file linked here shows this in a more complex example which can use rustc nightly as well as rustc stable.
However, as the docs of include! suggest, it does not behave hygienically.
What this means was unclear to me until I ran into the issue that macros defined in an external crate, yup-hyper-mock, were not defined at include-time. Some tests showed that even something like extern crate foo-bar-snoo-snoo; will not trigger an error at include-time, showing that it was not yet evaluated at all.
The problem arises from include! trying to expand macros, and failing if these are coming from external crates which haven't been evaluated yet.
An attempt of mine to define empty macros with the correct signature cause the include! macro to work, but the compile would fail later as include! would actually expand the macro right away, which was empty at the time of the include.
Is there a way to make include! work with macros defined in external crates? Alternatively, can you imagine a workaround to make my particular case work?
Personally I think include! should not expand macros at all, but leave that to the next compile step which should bring in external crates - maybe we are looking at a bug in rustc, but I am not sure about that.
How to reproduce
Please note that both stable and nightly compilers show the same issues.
git clone --branch syntex https://github.com/Byron/yup-oauth2
cd yup-oauth2
git reset --hard f59d97d
# build and test fail because 'include!' runs before crates are pulled
# in, but still expands macros
cargo build
cargo test
Meta
stable
➜ yup-oauth2 git:(syntex) rustc --version --verbose
rustc 1.0.0 (a59de37e9 2015-05-13) (built 2015-05-14)
binary: rustc
commit-hash: a59de37e99060162a2674e3ff45409ac73595c0e
commit-date: 2015-05-13
build-date: 2015-05-14
host: x86_64-apple-darwin
release: 1.0.0
nightly
➜ yup-oauth2 git:(syntex) rustc --version --verbose
rustc 1.2.0-nightly (2228ce10c 2015-06-09)
binary: rustc
commit-hash: 2228ce10c6d83c17b6346396aa7c7ef9082f1c04
commit-date: 2015-06-09
host: x86_64-apple-darwin
release: 1.2.0-nightly
I am trying to make Travis CI build and test the contents of my GitHub repository, which is compatible with Rust 0.12.0 and an older Cargo:
rustc 0.12.0 (ba4081a5a 2014-10-07 13:44:41 -0700)
cargo 0.0.1-pre-nightly (861c07f 2014-10-07 23:29:57 +0000)
I have specified Rust 0.12.0 in the .travis.yml:
language: rust
rust: 0.12.0
script:
- cargo build --verbose
- cargo test --verbose
- rustdoc --test README.md -L target
- cargo doc
The issue I seem to be hitting is that Travis will pick the latest Cargo nightly:
cargo 0.0.1-pre-nightly (fd5d7a9 2014-12-25 04:28:40 +0000)
But this newer version is incompatible with Rust 0.12.0, as it is now using --emit=dep-info where it used to use --dep-info:
--dep-info [FILENAME]
Output dependency info to <filename> after compiling,
in a format suitable for use by Makefiles
This gives rustc invocation errors, as the value for is --emit is invalid:
Running `rustc src/sqlite3.rs --crate-name sqlite3 --crate-type lib -g -C metadata=1c7080eec8c6f90d -C extra-filename=-1c7080eec8c6f90d --out-dir target/deps --emit=dep-info,link -L target/deps -L target/deps -Awarnings`
...
error: unknown emission type: `dep-info`
...
Could not compile `sqlite3`.
I have been looking at other repositories for how to get around this, but it seems they either do not use Cargo with 0.12.0 (which works with Travis) or hit the same issue, like here: https://travis-ci.org/eliovir/rust-ini
I have failed to find any repository that works with Travis, rust 0.12.0 and Cargo. If I can specify the version of Cargo somewhere, I would be able to get around this, but I have failed to find a way to do so in the .travis.yml file.
Of course, with Rust 1.0 coming up, I will just wait for it, if there is no obvious solution that I have overlooked :-)
I agree that tracking nightly is probably the best bet. If there are dependencies you rely on that aren't being updated, then maybe that's a sign that they wont be updated come 1.0 time, either!
All that being said, Travis does allow you to install things before your build. This is completely untested, but you might be able to do something like
before_script:
- wget https://static.rust-lang.org/dist/rust-0.12.0-x86_64-unknown-linux-gnu.tar.gz
- tar -xvf rust-0.12.0-x86_64-unknown-linux-gnu.tar.gz
- ./rust-0.12.0-x86_64-unknown-linux-gnu/install.sh --prefix /tmp/rust-0.12/
- export PATH=$PATH:$PWD/tmp/rust-0.12/bin
- export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PWD/tmp/rust-0.12/lib
This would download Rust 0.12, unpack and install it somewhere writable (doesn't really matter where). Then you setup env vars to point out where Rust is. Do the same to download a compatible version of Cargo.
If Travis has a "bare" language pack, that would be the best. Otherwise you could try using the Rust buildpack, or maybe just anything else (to avoid dealing with multiple rustc versions).