-
Notifications
You must be signed in to change notification settings - Fork 1
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
update: flux-sched to build with cmake #118
Conversation
This looks really good, as long as it's behaving itself I don't see anything we need to change. Might be nice to set the build directory for both builders so we always build out of tree, but that would be a bonus. One question, do we need the RelWithDebInfo option? I think I remember hearing that's no longer the default, so it's a good thing to have, but made me wonder. |
@trws yay you are around! So I don’t think we need it - I only added it so we would have an example of one option. Would you like me to remove? And if you want me to add the out of build directory can you show me how to do that with spack? |
@trws I think we have this?
is that what you mean? I can move it down into each respective builder class in case that doesn't take. |
@alalazo could you take a look here and let us know if we did anything wrong? I just tried a few derivatives of moving some of the logic down into the build system and it broke things, so I think we might be at a good spot here. |
Testing again with a cleared cache - the error was something about a missing key |
501979f
to
e56a04e
Compare
That looks like there's some kind of dependency on this specific system between libarchive and iconv, but that spack isn't providing iconv. When I look at spack develop, libarchive explicitly has a +iconv variant on it, and it should get built, same here. What's the base image here? Something strange seems to be going on with pkg-config and I'm curious what's causing it. |
@trws I fixed the bug in spack, and I'm not sure why it's not taking up here (I cleared the cache). I'm chocking it up (for now) to just one more day needed to sync everything. But the bug is fixed. |
Let's watch the build tonight and if it's still wonky follow up here! |
okay we are still failing tonight: https://github.com/flux-framework/spack/actions/runs/6541718560/job/17763633255. The first thing I checked is that we aren't using libarchive as an external dependency (no): ==> The following specs have been detected on this system and added to /home/runner/.spack/packages.yaml
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected] The only thing I can see about libarchive is the version:
We have the update here: spack/packages/flux-core/package.py Line 128 in f621212
So what I can try (assuming a hypothesis is something is being cached) is to add a variable that disables it. Aside from that I think I'm out of ideas at the moment. Update: running now, will report back. |
okay absolutely no cache used - can confirm that in logs! But still failed with this error: https://github.com/flux-framework/spack/actions/runs/6542060275/job/17764502643 Let me know if you see something or have an idea of what to try. I'll keep thinking too. |
I'm trying a local build now, with the latest of spack and the package.py file as it is here. If that works then I'm going to step back and try with pakages, which (should) just run the same command but we will see. If that doesn't work, great, I know what to debug! But if it does work I think I need to look at every step here, because there is a cache hidden somewhere I'm not finding. I'll update here with my progress. And sorry for the trouble, this workflow / set of actions has been working really well (and eliminate a lot of manual labor to update things with spack) so I'm curious what is going on here. |
okay both worked. So hmm, I think there is a cache hiding somewhere. |
e56a04e
to
70e48c1
Compare
fingers and toes are crossed.... ! 🤞 |
0dde06d
to
bfc3292
Compare
okay removing pakages didn't have any change - so it's not a nested cache. I'm next trying to remove |
okay that still didn't work. I'm going to now try removing the explicit install of clingo, the assumption being that it is somehow bringing something in to bork the subsequent build. |
oh maaaah goosh!! It was CLINGO that monster!!! okay to step back - the actions here were created before clingo (and the cache) was a thing. We installed it explicitly and created our own cache. This seems to have resulted in some dependency being installed that later borked the build. What I'm going to do now is slowly add back the functionality from the actions that is good (e.g, spack external find and caches) but just not the install of clingo. Will report when it is ready for another look! |
okay - first re-run is adding back spack external find, so we don't need to install like, cmake. |
Problem: flux-sched 0.29.0 after builds with smake Solution: add a dual package build for Autotools and Cmake Signed-off-by: vsoch <[email protected]>
bfc3292
to
88f7b5a
Compare
okay just pushed (hopefully) a final check. I've removed a lot of the caching for now - this means the builds will be longer, but probably we want to be testing that. If it becomes an issue with build time I can add them back. Certainly they were okay to have for a long while! |
okay estimating this will take a little over 30 minutes -when this is green I'm going to test adding just the package build cache back. |
okay 40 minutes! Cache is added back, trying again. |
@trws after an epic journey through the land of caches and spack updates passed, this is ready for you to review again! Turtles all the way down... 🐢 🐢 🐢 ... no no, caches all the way down... 📦 📦 📦 mumbles off into the distance |
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.
Looks great, thanks for tracking down that amazingly tricky cache issue!
Problem: flux-sched 0.29.0 and after builds with cmake
Solution: add a dual package build for Autotools and CMake
This is a WIP pending: