Skip to content
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

Remove superbuild #43

Merged
merged 53 commits into from
Jun 2, 2023
Merged

Conversation

robertodr
Copy link
Contributor

@robertodr robertodr commented May 29, 2023

See discussion here conda-forge/cppe-feedstock#22

  • Remove the local copy of Eigen. Dependency can be satisfied very easily through package managers, including conda.
  • Remove the auto-download of pybind11 if not present. Dependency can be satisfied very easily through package managers, including conda. In pyproject.toml it can be in the requires of the build system, so that pip itself figures out how to satisfy the dependency.
  • Reorganize CMake so as to remove the superbuild.
  • Refactor/update GitHub actions set up.
  • Switch setup.py to use scikit-build. git grep returns mentions of scikit-build but I can't see it used.

@robertodr
Copy link
Contributor Author

@maxscheurer current status:

  • I've overhauled CI for Linux and macOS. I had to fork the polarizationsolver package.
  • Need to add Windows in the CI as well.
  • Same for the publish.yml action, I think I can use cibuildwheel there.

Questions:

  • I've had to remove the possibility to build libcppe as static library. Is that strictly necessary to have?
  • Is distribution of a C++ library needed? Or is the project used exclusively as a Python module? If the latter, I can simplify the CMake further.

@maxscheurer
Copy link
Owner

This is a rather enormous change (if I understand correctly pip install . wil be the only way to build the Python module after the change)

I think the enormous change is probably not worth it for now, unless it'll make Win stuff easier?

@loriab any hints on making the tests run on Win? (See comments above)

@robertodr
Copy link
Contributor Author

It might make the windows stuff easier, but I think it's really within reach as things stand right now. Also, the Windows conda package builds, so we can skip running tests here for now, make a new release, and revisit later.

@maxscheurer
Copy link
Owner

What if instead of building w/ CMake, we run pip install . directly? Or adding the cmake install step? Would that maybe fix the Windows problem? 🙈
Thanks already for this enormous amount of very tedious work you put in! 🤩

@loriab
Copy link
Contributor

loriab commented May 31, 2023

On the Windows testing, it doesn't look like you're installing cppe anymore, and I wonder if that might help. There's only one mention of the pycppe*pyd file in the logs, and I'm not sure if it makes it there. Also, https://github.com/maxscheurer/cppe/pull/43/files#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR87 PYTHONPATH adjustment is Unix-like with the version.

@robertodr
Copy link
Contributor Author

Indeed the Python package ends up in Lib\site-packages\cppe on Windows. I changed that, but it didn't help. However, __init__.py is symlinked and I think that's what messes windows up. It's a proper file when installing, so that's what I'll try next Thanks Lori! 👍

@robertodr
Copy link
Contributor Author

OK, now tests run and pass on all 3 platforms. On Windows, the failure was a combination of 4 things:

  1. The location where Python modules are installed is Lib\site-packages without the python<major>.<minor> bit.
  2. The PYTHONPATH is empty and appending to an empty env-var is apparently generating invalid env-vars.
  3. There was another pytest lying around, so simply running pytest didn't honor the PYTHONPATH. python -m pytest fixed it (I make this mistake all the time and still haven't learnt from it 🤦🏻)
  4. Mismatch in linked-in OpenMP library on Windows. This requires setting KMP_DUPLICATE_LIB_OK=TRUE before running the tests.

Now I have to modify the setup.py to finish this up.

Copy link
Contributor

@loriab loriab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing important here -- just thought I'd read through and see what other projects are doing.

environment-file: .github/environment.yml
channel-priority: strict
python-version: ${{ matrix.python-version }}
use-only-tar-bz2: true # IMPORTANT: This needs to be set for caching to work properly!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You risk running out of packages soon and having inexplicable can't-solve environments with this since c-f is only serving up .conda packages now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I've seen that somewhere else. I just wanted to get caching to work and it seems that tar-bz2 option is needed for that.

python -m pytest --capture=no --log-cli-level=INFO --pyargs cppe
else
export PYTHONPATH=$PYTHONPATH:Software/lib/python${{ matrix.python-version }}/site-packages
python -m pytest --capture=no --log-cli-level=INFO --pyargs cppe
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Congratulations on your hard-won pytest line :-)

Adding --color yes makes it prettier.

if(CMAKE_CXX_COMPILER_ID MATCHES Intel)
set(ARCH_FLAG "-xHost")
endif()
endif()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

auto-update-conda: true
auto-activate-base: false
activate-environment: cppe-gha
environment-file: .github/environment.yml
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it ever starts being painful to solve, I'm a fan of mamba in CI: https://github.com/psi4/psi4/blob/master/.github/workflows/ecosystem.yml#L255-L256

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried mamba actually, but for some reason it failed to solve 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

huh, gtk

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But i think it's because of my insistence on tar.bz2. I'll bust the cache and retry without that option. Let's see. Maybe I get the caching cake and I eat it too with mamba

cd

if [ "${{ matrix.os }}" == "windows-latest" ]; then
export KMP_DUPLICATE_LIB_OK=TRUE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If anyone knows or reads a good explanation of the threading situation on Windows, please forward. I've avoided the KMP_DUPLICATE route for psi4 by using Intel OpenMP and the build solution inherited from Raimondas, https://github.com/conda-forge/psi4-feedstock/blob/main/recipe/meta.yaml#L66-L77 . More library and compiler confusion here https://gitlab.kitware.com/cmake/cmake/-/issues/23241#note_1145997 .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went on the (lazy) path of least resistance and used the KMP_DUPLICATE_LIB_OK hack... Maybe the solution by Raimondas is the best thing to do if problems arise?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The principle of what Raimondas did seems sound, but hiding away an old import lib at GH to link against is decidedly weird -- I'm a little shocked it made it through staged-recipes review. My path of least resistance was to take trouble at the build stage and avert showing KMP_DUPLICATE weakness to the user. :-) No idea which is better -- I'm just fishing for guidance. I'll let you know if I hear of any trouble with the Raimondas route.

@maxscheurer
Copy link
Owner

I guess other than that, just the PyPI pipeline needs to be refactored, but I can take care of that in a separate PR.

@robertodr
Copy link
Contributor Author

Yes, you can squash-merge this. If you're willing to wait a couple more days I can do the overhaul of setup.py and the publish.yml workflow.

@robertodr robertodr marked this pull request as ready for review June 1, 2023 16:40
@maxscheurer
Copy link
Owner

Sure, that'd be great 👍🏻

Copy link
Owner

@maxscheurer maxscheurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@maxscheurer maxscheurer merged commit 37d49bb into maxscheurer:master Jun 2, 2023
@robertodr robertodr deleted the patches-windows branch June 2, 2023 07:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants