-
Notifications
You must be signed in to change notification settings - Fork 37
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 to Omnia Linux anvil #761
Conversation
Initial README update (still WIP)
Actually update README (still WIP)
Unpin conda-build version
This keeps xcode on 6.4, no fix is in place |
…red for channel_priority first
This is temporary and coverage may be removed outright
I have added files to serve as flags for removal, review, and other notes on various packages. Most of these are FLAG_FOR_REMOVAL files to indicate that the package can probably be removed since the package already exists as part of |
Allow openmoltools to build on windows
Attempt to get clang from clangdev of conda-forge for OpenMM TEMPORARY: Made OpenMM build only on Linux and Python 3.5 for rapid testing REMOVE THIS TEMP CHANGE BEFORE MERGE
Good news! The new docker image can successfully build OpenMM. I have also confirmed that it is correctly using This validates the docker image is constructed correctly and packages can be built on it. I think it we are ready to move onto testing other packages, removing my debug lines, start reviewing the packages for removal. Also it would be good if someone else look at least at the docker file to make sure it gets everything we need. |
Yay! |
@peastman is there a particular reason we need to keep OpenMM pinned to clang 3.8.1? They have clang 3.9.1 on conda-forge as well so this may be a decent time to reassess the compiler version if there is not some hard restriction. |
In general I'm fine with using the most recent version, but for releases it's important to know and control what compiler is used. For example, when we release a patch update to fix bugs, it needs to be built with the same compiler version as the release it's a patch to. Compiler updates have been known to introduce bugs. |
Okay. I'll keep it pinned to 3.8.1 in the main omnia channel since we are not actually releasing a new version yet. We can reconsider the version for any planned major releases going forward. Thanks! |
Removed debug lines
Okay, I have updated the README (could use some review @jchodera ), removed the debugging line, and set all the packages I think are ready for removal and review. OpenMM builds on the new image, so I think we are ready to go with the migration to CentOS 6 based and conda-forge. I need to reach out to the CF people yet and figure out how to get things like the AMD SDK and the CUDA tools for actually taking OpenMM to CF, but one step at a time here. When this PR merges:
|
Okay, I fixed the OSX builds by not overwriting OSX OpenMM build appears to complete, but not install correctly so the test fails to find the |
No idea. I don't see any indications in the log of what the problem is. It runs the PythonInstall target, and appears to complete successfully:
When it gets to the test, it claims it's about to install the package it just built:
It doesn't report any errors while installing. Yet it then reports that OpenMM isn't installed:
Possibly that last line is a clue? Should that file have been created? |
Everything I see tells me it installed correctly, but it looks like the files just were not copied correctly.
Sadly no, that is just the generic error that conda-build throws as the last step as it checks for the tarbal as its last action, independent of if something else failed. I think this might be conda problem, I have some things I can test to find out. |
I cannot find a way to build on OSX without conda-build just failing for some unknown reason. Moving the channel priority to later appears to break the |
So the problem I am seeing on the OSX build is exactly the same problem we are seeing on the OpenMM Python 3.6 windows builds here: openmm/openmm#1758 (comment) How to fix it though.... |
Okay, here is what I can tell from digging around on the net..... The problem comes from the fact that python is built against a certain When building new packages, the environment There are some oddities with this though. My local version of Python 3.5.3 from So now the question is, can we set the version to built against from the python compiler, or are we going to have to find that magic python version which is 10.7 compiled for each version of python. On a side note, this is excessively dumb. |
+1000 |
Maybe this is a good time to report it on the |
Maybe, the problem is this does not appear to be a |
It's conda-related insofar as the Are all the
|
I just realized this conversation is happening on the wrong issue, linking back to the comment here |
Hold off on merging this until OpenMM 7.1.1 is published at minimum I think this is otherwise ready to go for the most part (some last builds running) xref: #768 |
Should we at least disable the current failing byulds? I'm a separate pr? |
I can and did for most of them already. The remaining errors being raised are legitimate concerns that I don't want to silence. They are mostly caused by lack of OpenMM on Python 3.6 for Windows that we never fixed. When we cut 7.1.1, we will want to fix that first. |
And to be precise, the remaining errors are all related to missing OpenMM builds. |
Guess what! Its merging day! |
Start the process for updating to the CentOS 6 image.
This is very much a work in progress since we cannot reasonably test all the packages at once. So this initial commit will be to make sure the basics of the new docker image work.
This that need to be done in loose order:
Replaces and closes #667
Tagging @jchodera