build.rs fails, when the shaderc-rs package from crates.io is used (not a git checkout)

[HellButcher]

build.rs fails with the following error-message, when shaderc-rs is included as a dependency in a project.

   Compiling shaderc v0.3.1
error: failed to run custom build command for `shaderc v0.3.1`
[...]
--- stderr
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
thread 'main' panicked at 'git submodule update --init failed', ~/.cargo/registry/src/github.com-1ecc6299db9ec823/shaderc-0.3.1/build/build.rs:28:8
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:380
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic_new
             at /checkout/src/libstd/panicking.rs:553
   6: build_script_build::git_submodule_update
             at ./build/build.rs:28
   7: build_script_build::main
             at ./build/build.rs:69
   8: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
   9: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:458
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  10: main
  11: __libc_start_main
  12: _start

I guess a solution would be, to call git submodule update only, if there is a .git directory

[HellButcher]

Workaround: tell cargo to checkout the repository like this:

[build-dependencies]
shaderc = { version = "0.3.1", git="https://github.com/google/shaderc-rs", tag="v0.3.1" }

[dylanede]

I think the solution to this is to remove the git submodule updates from the build script. Other crates that use submodules don't do submodule updates in build scripts - they rely on the user to do that as and when necessary (typically doing git clone --recursive when initially checking out the repository then manual submodule updates as and when necessary).

[antiagainst]

Thanks for reporting!

I've noticed the error on docs.rs, and thought it's because not issuing git submodule in the project root directory. So pushed out v0.3.1. It seems the problem persists.

Previously it was OK when using git clone for each project manually. May revert back to that way.

I still like to avoid to require the user to do an additional git clone or git submodule to checkout the projects by themselves and would like to hide everything behind build.rs.

@dylanede: If manual check out is required for a crate, you cannot easily use that crate as an dependency for another project?

[antiagainst]

Oh, wait, it seems cargo will automatically checkout submodules for crates on crates.io having .gitsubmodules?

[antiagainst]

I've #16 up. Hopefully it will solve the problem.

[dylanede]

With crates in the crates.io registry, Cargo doesn't use git at all. The crates are just a collection of source files kept in the registry that match what you tell cargo publish to upload (typically the entire contents of the crate directory excluding target and git-ignored files, but not necessarily). So if you publish shaderc-rs with the git submodules in a checked out, updated state, their contents will be in the published crate.

What is affected by git is when the crate is specified as a dependency using git = in a Cargo.toml. Off the top of my head I can't remember whether cargo does recursive cloning when using a git-specified dependency. I think it does.

[antiagainst]

@dylanede: Ah, that makes sense! Thanks for the explanation!

I checked the .cargo\registry\src\github.com-XXX\shaderc-XXX directory, shaderc and its dependencies are there, and no .git subdirectories in all of them. So that explains the error.

[antiagainst]

@HellButcher: v0.3.2 should have fixed the problem. Thanks! :)