Closed notgull closed 1 year ago
It appears that the main obstacle to this is that the QT-related dependencies are hardcoded into the qt_ritual
and qt_ritual_common
crates. In addition, it also appears that installation data is checked, which assumes that the crate in question is a main QT lib. It would be nice if either qt_ritual
or qt_ritual_common
exported a way to retrieve data for the QT compiler without needing to check if the installation was present. Again, I can add this functionality to the code, if it is desired.
I think the plan here is:
qt_ritual
so that it can return a Config
for a library that depends on specified Qt crates.target_include_paths
logic to allow processing libraries that consist of only extra C++ code. Right now, if you don't specify it, the parser will parse all available symbols, which is not what we need in this case.qt_ritual_build
so that it can be used for the produced crate. It's necessary to reuse its Qt detection logic so that the user's crate links to the same Qt as the main Qt crates.I'm currently working on the next release of Qt crates, so some relevant changes to the generator are not yet finished. After I finish that, I'll look into this issue.
Not interested in this anymore.
It would be nice to create a custom widget (derived from
QWidget
) in C++ code, then use it in Rust code. If this isn't possible already, I would be willing to add this functionality to the code.