Is it supported to have a cxx-qt-based crate as a Cargo dependency?

[SanderVocke]

In my project structure, I have a crate crate_a that has some QML types defined through cxx-qt.

There is also a top-level crate crate_b, which depends on crate_a by path in the Cargo manifest.

It could be I'm doing something wrong, but for me this does not work out of the box:

• First of all, crate_b is unaware of library search paths needed to find Qt. I have to add my own "cargo:rustc-link-search=native" entries to crate_b's build script for Qt to be found and linked.
• Even then I get some linkage troubles. Example:

  = note: /usr/bin/ld: /tmp/rustcQgp1jl/libqt-static-initializers.a(d0262991ff60e674-shoopdaloop_plugin_init.o): in function `Staticshoopdaloop_pluginPluginInstance::Staticshoopdaloop_pluginPluginInstance()':
          /home/sander/dev/shoopdaloop_rust/target/debug/build/shoop_rs_frontend-de5b9b49872c31b6/out/shoopdaloop_plugin_init.cpp:3: undefined reference to `qt_static_plugin_shoopdaloop_plugin()'
          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

The only workaround I can think of at the moment is to build crate_a to a "good old" shared or static library. But then I lose a lot of the convenience of inter-crate dependency management by Cargo. Am I missing something?

As usual, thanks!

[SanderVocke]

I should add that crate_b does not have a direct dependency on cxx-qt. Maybe this can be fixed by adding one and somehow invoking another CxxQtBuilder in crate_a's build.rs? Then again, I wouldn't know how to configure that builder, since crate_a's internals are not known to crate_b.

[LeonMatthesKDAB]

Hi, first off: I assume we're talking about the current main branch in the cxx-qt repo, not Cxx-Qt 0.6 :)
Our build system has changed a lot in the last two months.

Initial thoughts:
You mention that crate_b doesn't link to Qt. Why is that an issue? If crate_b doesn't use CXX-Qt, why does it need to link to Qt? I thought it would use Qt through crate_a types, which in turn should take care of linking to Qt 🤔

Regarding the "canonical" solution to this problem:
Recently we added CxxQtBuilder::library, which you should use in crate_a.
Instead of compiling everything into the executable, this will export certain bits of data&code through the DEP_ system, so that downstream dependencies can take care of including them in the final build.
This is especially important if you're using CMake for the final build, but may also solve the issue you're experiencing.

crate_b then needs to use CxxQtBuild::new().build() in its build script.
This should include all the initializers from crate_a in the final linker step.

Please let me know whether this works.
I'm wondering whether we could make this specific use-case of crate_b not using CXX-Qt work without requiring a build-script for crate_b, but I'm not sure 🤔

[SanderVocke]

It sounds like indeed a lot has improved, and indeed I was still stuck on cxx-qt 0.6. So first I will just upgrade and see if CxxQtBuilder::library already solves this. Thanks for chiming in!
I don't mind much if I need to create a CxxQtBuild builder in crate_b, but it would definitely be an improvement if it doesn't. Otherwise I would probably at some point draw the line between cxx-qt code and the rest by means of a shared library crate.

It does sound like these kind of problems deserve a spot in the documentation or "book".

[LeonMatthesKDAB]

Ah, right, things should indeed be much improved in main, so if you're on 0.6, giving that a try is definitely worth it.
With 0.6, you may even be able to use new instead of library in crate_a and not add a build script to crate_b, though I'm unsure about this.

Regarding documentation: These changes have been documented in the book, which you can take a look at locally by running mdbook serve --open in the book folder on the cloned cxx-qt repo.
This will be published with the 0.7 release :)

[SanderVocke]

Turns out that with the latest main version of cxx-qt, this just works. I didn't use library() as I don't intend to create additional cxx-qt-based functionality in crate_b. I just used CxxQtBuilder::new() and crate_b was able to compile with crate_a as a dependency, without using a build script.