lewton icon indicating copy to clipboard operation
lewton copied to clipboard

Breaks cargo doc with sccache

Open purpleposeidon opened this issue 5 years ago • 8 comments

$ cargo new weirddocs
     Created binary (application) `weirddocs` package
$ cd weirddocs/
$ echo 'lewton = "0.10.1"' >> Cargo.toml 
$ echo $RUSTC_WRAPPER 
sccache
$ cargo build
    Updating crates.io index
   Compiling byteorder v1.3.4
   Compiling tinyvec v0.3.3
   Compiling ogg v0.7.0
   Compiling lewton v0.10.1
   Compiling weirddocs v0.1.0 (/media/media/tmp/weirddocs)
    Finished dev [unoptimized + debuginfo] target(s) in 1.95s
$ cargo doc
    Checking tinyvec v0.3.3
 Documenting tinyvec v0.3.3
    Checking byteorder v1.3.4
 Documenting byteorder v1.3.4
    Checking ogg v0.7.0
    Checking lewton v0.10.1
 Documenting ogg v0.7.0
sccache: encountered fatal error
sccache: error : failed to store `lewton` to cache
sccache:  cause: failed to store `lewton` to cache
sccache:  cause: failed to zip up compiler outputs
sccache:  cause: No such file or directory (os error 2)
error: could not compile `lewton`.

Caused by:
  process didn't exit successfully: `sccache rustc --crate-name lewton /home/poseidon/.cargo/registry/src/github.com-1ecc6299db9ec823/lewton-0.10.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --crate-type staticlib --emit=dep-info,metadata -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="ogg"' […]` (exit code: 254)
warning: build failed, waiting for other jobs to finish...
error: build failed
$ export RUSTC_WRAPPER=""
$ cargo doc
 Documenting lewton v0.10.1
    Checking lewton v0.10.1
 Documenting weirddocs v0.1.0 (/media/media/tmp/weirddocs)
    Finished dev [unoptimized + debuginfo] target(s) in 1.39s
$ rustc --version
rustc 1.43.1 (8d69840ab 2020-05-04)

I suspect it is caused by crate-type = ["lib", "staticlib"], but I have not tested this.

purpleposeidon avatar May 30 '20 01:05 purpleposeidon

rust-lang issue: https://github.com/rust-lang/rust/issues/72765

purpleposeidon avatar May 30 '20 01:05 purpleposeidon

Don't have much experience with sccache. No idea what might be going on.

est31 avatar May 30 '20 01:05 est31

*edited: I suspect it is caused by crate-type = ["lib", "staticlib"], but I have not tested this.

purpleposeidon avatar May 30 '20 01:05 purpleposeidon

Hmmm that exists for the C API. If that's indeed the reason (could you check somehow?), maybe we can put the C API into a different crate.

est31 avatar May 30 '20 01:05 est31

Huh, specifying lewton as lewton = { path = "../lewton/" } doesn't reproduce it. That's interesting.

But I can simply edit ~/.cargo/registry/src/github.com-1ecc6299db9ec823/lewton-0.10.1/Cargo.toml, removing/adding the "staticlib" turns the crash off/on.

purpleposeidon avatar May 30 '20 01:05 purpleposeidon

Given that users have to run a separate command to get the c library anyways, just having an alternate Cargo.toml would be simpler than creating a new crate.

purpleposeidon avatar May 30 '20 02:05 purpleposeidon

(The staticlib thing also seems to cause problems with dylibs (that use rodio) but getting a proper minimized reproduction of that sounds exhausting.)

purpleposeidon avatar May 30 '20 02:05 purpleposeidon

Have you considered filing an issue for sccache? https://github.com/mozilla/sccache

It might be interesting what they have to say.

est31 avatar Jun 09 '20 08:06 est31