-
Notifications
You must be signed in to change notification settings - Fork 354
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
Unify Mac and Linux tests #4925
base: master
Are you sure you want to change the base?
Unify Mac and Linux tests #4925
Conversation
Currently seeing errors from:
|
701e8b5
to
d928731
Compare
Ok, now I see the following issues. First, on Linux, BBHx fails to build again with this old error:
Apparently the workaround I had put in Second, lalsuite does not have wheels for macOS 13 and 14 on PyPI, so we cannot use the target |
@titodalcanton The linux failure is only happening in this PR, right? It looks like |
@spxiwh correct, but the PR is moving the lapack installation from |
I think it would be fine if you installed it systemwide (using |
Also |
Right, the point of the PR (originally #4723) is to unify Linux and Mac, thus removing OS-specific installs. I would expect tox to find LAPACK if I told it explicitly where it is… Which apparently is not working yet. |
LALSuite uploads wheels that should work for macOS 11+ (x86_64) and 12+ (ARM), please see
@titodalcanton are you seeing build failures as a direct result of LALSuite compatibility issues? |
@duncanmmacleod no, it was my mistake, sorry. Disregard. |
I made some progress squashing the various build errors. One difficulty I had to realize and work around is the fact that we create a Conda env, but then tox wants to create a new Conda env, and the original env carries a bunch of libraries and header files which things in the new env must be able to find. The only way I found to do this is explicitly set env variables in the YAML. The limiting factor now is a failure to build mpi4py due to unresolved symbols. I do not understand why that happens, I guess there may be more env vars to set. |
@titodalcanton Given that tox will make it's own conda env, why the desire to move things from tox's conda env to the higher-level one? If tox is finding it hard to find those locations, why not keep them in tox's env (also note there's an additional layer of abstraction when building anything from source, as wheel will also construct a build env). |
Looks like #4946 might make this easier. Will try again after that is merged. |
This is a new attempt at #4723, essentially just a rebase of that off current master.