Release system crates with git submodules

[chrsoo]

Hi,

When releasing a sys library with a build script that builds an external vendor repository included in the project as a git submodule, cargo complains that the source directory is dirty:

error: Source directory was modified by build.rs during cargo publish. Build scripts should not modify anything outside of OUT_DIR.

... and suggest using the --no-verify to publish anyway.

Is there a good way to use cargo release with git submodules without the --no-verify flag ?

Note: the files structure would look something like this:

.
├── Cargo.lock
├── Cargo.toml
├── src
├── submodule
└── target

[epage]

That error is actually coming from cargo publish, which cargo-release runs. I'm not seeing any related problems reported so far.

Do you have more precise reproduction steps so I can better understand the problem?

[chrsoo]

Perhaps I should have mentioned that I am trying to use cargo release with FFI bindings and the bindgen tool` where the Git submodule is a C-library that I want to wrap in Rust.

Given that the git submodule is not located in the target dir, all works as expected when verifying the crate before publishing to crates.io; the source code tree (being defined as everything outside target) is indeed dirty as a consequence of building the C library in the git submodule from a build.rs script.

What I am hoping for is a workaround to avoid usng the --no-verify flag.

One idea would be to move the default target output directory to the build directory of the git submodule but this would only work for C libraries that use a build directory. Old style libs that put the object files side-by-side with the source would not work.

[epage]

Where does the C library's build process store intermediate and final artifacts? Can it be overridden to be in $OUT_DIR?

[chrsoo]

Indeed moving it the other direction makes way more sense. Will look into that.

Also, another thing to investigate is to use the rust c-compiler directly instead of running make as a system level command. This makes a lot of sense in this particular case as I am only interested in the core library and not the full distribution binary.

As a side note, I also need to cherrypick what goes into the cargo package when pushing to crates.io as the compressed source code for the C-library weighs 300 MB, far exceeding the 10MB limit...

Anyhow, starting to realise that I am probably just wasting your time here given that it all comes down to the specifics of the C-library submodule.

Thanks for the input, will mark the above as an answer.