-
Notifications
You must be signed in to change notification settings - Fork 47
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
Add new conan remote and use pre-built symengine package #217
Conversation
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.
Have you thought about making the build symengine workflow required on the ci?
Have you run the symengine workflow somewhere?
README.md
Outdated
@@ -135,7 +147,9 @@ The `symengine` dependency is built from a local conan recipe. Run: | |||
conan create --profile=tket recipes/symengine | |||
``` | |||
|
|||
to build it. | |||
to build it. If you are using a conan configuration supported by the CI, this is |
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.
From my understanding this only works for specific compiler versions? If that is a case should we add them here?
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.
Yes that's right. There is a list above under "Build tools". Do you think that is enough? Maybe we should add a reference to that section here.
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 have seen you added that, thank you!
Yes, I have: here and (after fixing an error in the Windows section) here. If you add the new conan remote to your local setup you can then do:
to see the list of packages there. |
Yes, I will probably do that. |
I forgot that conan data is cached on MacOS builds.
Thank you, that was helpful in the understanding. |
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.
A few more comments, and one questions:
At which point are you making sure that the symengine compilation is run before the tket compilation in case of changes to symengine?
@@ -54,10 +55,10 @@ jobs: | |||
${conan_cmd} profile update settings.compiler.libcxx=libstdc++11 tket | |||
${conan_cmd} profile update options.tket:shared=True tket | |||
echo "CONAN_CMD=${conan_cmd}" >> $GITHUB_ENV | |||
- name: add remote | |||
run: ${CONAN_CMD} remote add tket-conan https://tket.jfrog.io/artifactory/api/conan/tket-conan |
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.
why is this not forced?
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.
It is only on the MacOS platforms that we cache the conan data. (On macos by explicitly caching it, on macos-m1 just by not clearing it since it's the same machine each time.) This is because they need to rebuild (some of) boost so it saves a significant amount to time. On the other platforms there is no point.
@@ -366,14 +370,14 @@ jobs: | |||
conan profile update options.tket:shared=True tket | |||
$conan_cmd = (gcm conan).Path | |||
echo "CONAN_CMD=${conan_cmd}" >> $GITHUB_ENV | |||
- name: add remote | |||
run: conan remote add tket-conan https://tket.jfrog.io/artifactory/api/conan/tket-conan |
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.
see above
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.
See above.
on: | ||
push: | ||
branches: | ||
- develop |
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 am not sure how this interacts with the possibilities to do hot fixes to only have this run on develop. If there is no different version for the master branch this could create dependencies after changes in symengine that we are not able to handle with this setup. Considering that it is quiet unlikely that this will happen at all, I would be fine with merging this as it is, but I wanted to mention it.
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.
Yes that is a fair point, we could run this on PRs and pushes to main
in exactly the same way. The downside is that then for a normal release when we do a PR or push to main
it would build the package unnecessarily (this won't cause the build to fail, however, it just won't upload anything).
Given that we do hotfixes for pytket very rarely, I think I'm happy to keep develop
as the single place where this is tracked. If we do need to do a hotfix that changes the symengine recipe, we can do a PR to develop with the new recipe (and new version number -- builds of tket on develop will continue to use the old version), followed by the hotfix.
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.
Okay, I agree.
- name: Build symengine | ||
run: conan create --profile=tket recipes/symengine | ||
- name: add remote | ||
run: conan remote add tket-conan https://tket.jfrog.io/artifactory/api/conan/tket-conan |
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.
see above
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.
See above.
@@ -160,14 +166,14 @@ jobs: | |||
conan profile update options.tket:shared=True tket | |||
$conan_cmd = (gcm conan).Path | |||
echo "CONAN_CMD=${conan_cmd}" >> $GITHUB_ENV | |||
- name: add remote | |||
run: conan remote add tket-conan https://tket.jfrog.io/artifactory/api/conan/tket-conan |
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.
see above
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.
See above.
Sorry I missed this. We are not -- so we would have to first update the symengine recipe in a PR, and then do tket updates that depend on it another PR. |
Oh, that sounds a little bit complicated. Is that documented somewhere? |
In practice I don't think this will be an issue. It's good practice to separate the PRs anyway, and as long as we remember that tket must use a version of symengine that exists on the repo it shouldn't cause confusion. But I will add a comment in the tket conanfile to make this clear. |
The plan is to have tket components individually versioned, packaged and hosted on tket.jfrog.io in a new
tket-conan
repository. This should help make tket more modular and extensible, as well as reducing build times.As a "warm-up", and to save having to build symengine on the CI, I have:
tket-conan
, in several configurations (4 platforms x Release/Debug x shared/static);The
build_symengine
workflow is run only for PRs and pushes todevelop
that change the symengine recipe. In the PR workflow the artefacts are not actually uploaded; in the push workflow they are.