Relax insistence that cargo project is mounted read-only

[dimbleby]

I'm having a go at cross-compiling rust-c-ares.

To build the underlying C library, the first step is to run buildconf which:

• must be run from the root of the c-ares checkout
• does stuff in that checkout eg creating a configure script

... which is unfortunate for trying to get it to work with cross, because the file system is mounted read-only.

Any chance of relaxing that, perhaps via some opt-in option if you want to maintain current behaviour as default?

(Also: it would be nice if the Docker images would apt-get install automake libtool m4 so that I didn't have to make my own docker image, but this is not a big deal).

[zzeroo]

I have a similar problem with a Project which uses bindgen. The build.rs needs to compile the C lib within a subdir of the repo.

[gnzlbg]

I've submitted a PR that might fix this. Hard to tell without any kind of testing harness. Might want to check that PR out and see if it fixes it for you.

[dimbleby]

Yes, that's the change that I made locally when I was doing this.

[gnzlbg]

@dimbleby Couldn't you just copy the C library to the OUT_DIR, and run buildconf there ?

[gnzlbg]

Or in other words, I pretty much have ended up agreeing with the defaults that the project directory should be immutable. If you need to do "mutating" work, copying/linking stuff into the OUT_DIR, and doing all the work there, seems like a more reasonable approach to me.

[dimbleby]

I think what we have in my example is an awkward collision between Rust and not-Rust cultures:

• cargo expects that you won't modify anything in your source directory while compiling code
• c-ares completely deliberately modifies code in the source directory during the build

Your suggested workaround of copying c-ares source into OUT_DIR would work I think. but it's at least rather awkward.

It makes perfect sense to me that cross's default behaviour is to go with Rust-y defaults. But it would be nice to be able to relax that for these unusual cases where it makes sense to do so - perhaps, per my original proposal, an opt-in configuration option would be a sensible way to go.

I had forgotten all about this issue until your comment yesterday, so this certainly isn't important to me. Feel free to declare that I am wrong and just ought to be using OUT_DIR - I shan't mind in the least!

[gnzlbg]

I think what we have in my example is an awkward collision between Rust and not-Rust cultures:

I clashed with this yesterday as well. I tried to do the work in place, and crashed against Rust/cargo/cross defaults. After finding a work around for this issue, the "copy to OUT_DIR and modify there" approach, I had a deja-vu. This is also how it is done in C++ with CMake as well, where the project directory is immutable, and everything happens in the "build" directory.

But it would be nice to be able to relax that for these unusual cases where it makes sense to do so - perhaps, per my original proposal, an opt-in configuration option would be a sensible way to go.

I wasn't suggesting to close this issue or anything, just sharing a potential workaround that I thought might work for you (and others) for the time being. My build.rs script had all paths "parametrized", so moving the stuff to the OUT_DIR was a ~5 LOC change (basically just run cp on the stuff I needed, and update one path, and that was it).

IIRC CMake doesn't have a way to enforce that the project directory is read only, so you can actually modify it but if you do so "some things might not work", so in the past I have actively tried to avoid that there, and yet I was, trying to do the opposite here 😆

[dimbleby]

Looks like cargo has decided to play hardball on this one - rust-lang/cargo#5584.

So I guess we all are going to have to go along with Rust conventions, like it or not - and cross has, at the very least, become the wrong place to argue about this.

Therefore suggest close this one out.

[gnzlbg]

People from the future: no matter what you want to do/change in your source / cross-root directory during your build, the path of least resistance is to just copy / set up whatever you need into the target directory.

The target directory can be accessed as:

• std::env::var("OUT_DIR") from your build.rs files
• env!("OUT_DIR") from your source code files, so you can do include_bytes!(concat!(env!("OUT_DIR"), "/stuff.rs"))

If you want to:

• compile C libraries that you download / fetch from git / have installed as a submodule, just download / fetch / copy them to the target directory, configure and build them there
• compile or run-tests in sub crates that are not part of your workspace, either run cargo lock to generate the lockfiles before you call cross for the first time, or just copy them to the target directory and run them there
• generate files in your build.rs that then get included into your build, put them in the target directory and then include_bytes!(concat!(env!("OUT_DIR"), "/stuff.rs"))