Switch to workspace dir as the include path

[tylerhawkes]

This commit reworks how files are placed so that anyone who overrides
CARGO_TARGET_DIR or the associated cargo config setting will be able
to use the crate. It is a breaking change because the cargo manifest
directory is now included by default, not the directory that is the
parent of the target directory. It also places the rust/cxx.h file in
$OUT_DIR/cxxbridge instead of inside of $TARGET_DIR/cxxbridge.
This also removes the need to symlink it.

[tylerhawkes]

@dtolnay I'd appreciate you looking at this. We use a docker container with the target directory set to /target which is mapped to the host, so it isn't where the current cxx crate can use it and run successfully. It can't even get the demo to build. This makes it so that anyway a target directory is set will work. It also makes it so that includes can be relative to the workspace or to the manifest directory, which may be too permissive, but feels a lot more intuitive to me (I have no c++ experience) especially for crates that have all the c++ code embedded in them that is being used to interface with a library.

[chachi]

+1 on this - I have a local hack to do the same thing for integration with another C++ build system in a totally separate build directory tree.

[dtolnay]

I published cxx and cxx-build 0.4, which hopefully fixes all of the brittleness in the Cargo-based workflow, including #88. @tylerhawkes or @chachi would one of you be able to give it a try with your codebase and report whether it works now?

We no longer rely on the target dir or workspace dir being findable at all. The generated code is written to the OUT_DIR provided by Cargo, and import paths are always crate name + local path within crate, e.g. #include "my-crate/src/lib.rs.h" where my-crate is the crate name and "src/lib.rs" was the path passed to the cxx_build::bridge code generator.

[tylerhawkes]

After a little bit of testing, this works with cargo run, however when I run cargo test it complains that the cxx functions aren't being provided. (The project I'm using this on is cross-compiling, but it was working fine with my branch.)

As a side note, the generated code still has #ifndef CXXBRIDGE03_TYPE_CxxType

[dtolnay]

cxx-build 0.4.0 definitely shouldn't be writing output containing CXXBRIDGE03_TYPE_{Type}. That was changed to CXXBRIDGE03_STRUCT_{Type} in 57003b0, and then CXXBRIDGE04_STRUCT_{Type} in 591dcb6#diff-9b5e6af74d9c67d96e5c6429528e3233L316-L322, which are both in 0.4.0 (https://github.com/dtolnay/cxx/blob/0.4.0/gen/src/write.rs#L319).

Could you try cargo clean followed by cargo test?

[dtolnay]

If that doesn't fix it: when you say "cxx functions aren't being provided", can you be more specific about which ones? Is it functions and types defined by the rust/cxx.h header, or is it ones related to the functions in your cxx::bridge module? Are they missing when the C++ compiler runs or when the linker runs?

[dtolnay]

I was able to reproduce the issue and I see what's failing, stay tuned for 0.4.1.

[tylerhawkes]

I didn't run cargo clean, but I have removed all generated code several times and I'm guessing you found that rust is expecting cxxbridge04$func and it is being defined as cxxbridge03$func in the <crate>/src/lib.rs.cc file?

[dtolnay]

That's still old generated code if it contains cxxbridge03. I think the problem was something different (fixed by a55c394). I published cxx-build 0.4.1 -- could you check whether things work following a cargo update?

If not, would you be able to share:

• What target you are building on and cross compiling for?
• As much of the error message as you are able to share?

[tylerhawkes]

It works on 0.4.1 and probably did on 0.4.0 since I forgot to update the build dependency which explains what I was seeing, however I'm glad you found the other bug.