Allow building static CQiree #42
Conversation
Passing `MODULE` to `add_library` seems to force a shared library to be built even if `BUILD_SHARED_LIBS=OFF`.
Without this, the C headers are not installed.
`#include <cstdint>` does not compile on a C compiler.
Without this, the C++ compiler on my GNU/Linux system cannot find `std::sort()`.
sethrj
left a comment
sethrj
left a comment
There was a problem hiding this comment.
Thanks for the fixes! (If you move those to a separate PR I can approve and merge them immediately.) The one-line change removing MODULE may have consequences that are untested: I'm actually a little surprised it works as is in all configurations, which might just mean we need a little more testing (e.g. a runner that builds static libs).
Per PR comment.
ausbin
force-pushed
the
feature/cqiree-static-build
branch
3 times, most recently
from
1b75ab3 to
ae86b9d
Compare
Otherwise, when modifying CMakePresets.json and running `git
clang-format`, I get:
Configuration file(s) do(es) not support Json
Also update the pre-commit-hooks configuration to allow the second YAML
document that this commit adds in .clang-format.
ausbin
force-pushed
the
feature/cqiree-static-build
branch
from
ae86b9d to
f43ef9c
Compare
ausbin
force-pushed
the
feature/cqiree-static-build
branch
from
f43ef9c to
ef6d847
Compare
|
Please avoid force pushing! 🙂 |
|
Why? |
|
@ausbin It interferes with the review process. When you force push:
|
|
Thanks for sharing your perspective. It sounds like we have different styles of using git — agree to disagree. In this case, I was constructing a readable commit history while also fighting with CI. When you have time, please feel free to check out the four new commits added today. I did not modify previous commits. |
|
@ausbin I use force push all the time and am a huge supporter of rebasing, but only before a review has started. I personally do prefer readable commit histories, but after a review starts the review process needs to become part of the history. Because we use the "squash" method, the changes and merges and so forth done during review are silently flattened into a single clean commit which is the only history most people see. The iterations made during review are saved in this pull request's commit history which is also very useful. You can disagree with style and policies, but part of working in an open source collaboration is agreeing to follow the development practices required by the project. |
| set(_LIB_TYPE) | ||
| endif() | ||
|
|
||
| qiree_add_library(cqiree ${_LIB_TYPE} |
There was a problem hiding this comment.
Another alternative to this is to use an object library that allows us to build a dlopen-compatible module and a linkable (shared or static) library... @miniskar thoughts?
There was a problem hiding this comment.
Let me know if you want me to attempt this
2 participants
With these changes, the compilation flow I need in the Qwerty compiler works. That is, I can create a
qiree_syscrate that builds a static QIR-EE and provides Rust bindings, call QIR-EE from Rust code, and link the whole thing into a Python extension module (a self-contained shared library).I think this PR is easiest reviewed commit-by-commit. I tried to leave an explanation of each change in each commit.
Testing
The unit tests pass and
bin/qir-qsim ../examples/bv11010.llruns successfully. (Note that I built only with-DQIREE_USE_QSIM=ON -DQIREE_USE_XACC=OFF, though.)I can also call
qiree_create()andqiree_destroy()from inside the Qwerty runtime without any obvious explosions.