-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use cbindgen
via Rust API
#14013
base: main
Are you sure you want to change the base?
Use cbindgen
via Rust API
#14013
Conversation
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 13854764156Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the concept of this integrating the header generation into the build process, it makes a lot of sense, especially when building the standalone c dynamic library.
My concern is for the case where people are trying to get the header file without building the library. For example, if a user of the precompiled wheels is trying to generate the header and build a custom python extension the normal workflow is to run cbindgen manually or run make cheader
. So I'm wondering what the workflow is for that use case here because you removed the cbindgen.toml so the standalone header generation doesn't work anymore does it?
config.parse = parse; | ||
|
||
// Ensure the include directory exists, and then set the full header path. | ||
let mut path = "../../dist/c/include".to_string(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this is always what we want. Like I get that's what we had in the makefile, but it seems overly prescriptive on the use case. Like when I'm working on the C API I tend to have a cwd of crates/cext
and just call cargo build
and cbindgen
directly.
I'm thinking that we might want the build file to only save it to the cwd and rely on the makefile to move it to the final destination.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that sounds more stable 👍🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I'll revise: this path seems to be relative to the cext
crate -- whether running
cd $QISKIT_ROOT
cargo build -p qiskit-cext
or
cd crates/cext
cargo build
The header file is correctly placed in $QISKIT_ROOT/dist/c/include
🙂 In this case this is more elegant than having an additional Makefile move the file, since we just need to cargo, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was actually arguing that this was not desireable behavior. If you do:
cd crates/cext
cargo build
(or now cargo rustc --crate-type cdylib -p qiskit-cext
)
I would expect the header to be in the CWD rather than ../../dist/c/include
.
Yes that's a good point. It seems we can actually have both (until we would need features only exposed in the Rust API): we can have the settings in a |
Summary
We currently generate the header using
cbindgen
as command line tool. This works, butcbindgen
has (ok almost all)This PR moves to using the Rust API of
cbindgen
and builds the header as part of theqiskit-cext
compilation process. This fixes all the above points. The one down side is that thecbindgen.toml
was a bit nicer to read IMO, but that's a small price to pay.It would be nice to backport this to
stable/2.0
for a smoother build process for users.Details
Makefile
is slightly simpler now since we don't need to separately call the command line tool to generate the header file.