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

Fix GCC 5 Builds #2939

Merged
merged 9 commits into from
Dec 4, 2020
Merged

Fix GCC 5 Builds #2939

merged 9 commits into from
Dec 4, 2020

Conversation

ax3l
Copy link
Contributor

@ax3l ax3l commented Oct 8, 2020

PR Summary

Use GCC 5 to trigger compiler errors with non-default C++14 compilers.

Follow-up to regressions from #2575 and #2610
Fix #2892

export CC=$(which gcc-5)
export CXX=$(which g++-5)
python3 -m pip wheel -v .

PR Checklist

  • pass black --check yt/
  • pass isort . --check --diff
  • pass flake8 yt/
  • pass flynt yt/ --fail-on-change --dry-run -e yt/extern
  • New features are documented, with docstrings and narrative docs
  • Adds a test for any bugs fixed. Adds tests for new features.

@ax3l ax3l changed the title [CI] [Temporary] GCC 5 [WIP] Fix GCC 5 Builds Oct 8, 2020
.travis.yml Outdated Show resolved Hide resolved
@ax3l
Copy link
Contributor Author

ax3l commented Oct 8, 2020

Hi @matthewturk @cphyc,

I saw your PRs in #2575 and #2610 and am not an expert in the places I touch here. Help & hints welcome :)

@ax3l ax3l force-pushed the fix-gcc5 branch 4 times, most recently from ce27c43 to b7e178d Compare October 9, 2020 07:24
@ax3l ax3l changed the title [WIP] Fix GCC 5 Builds Fix GCC 5 Builds Oct 9, 2020
@ax3l
Copy link
Contributor Author

ax3l commented Oct 9, 2020

@RevathiJambunathan does this PR work for you, with respect to #2892?

python3 -m pip uninstall yt
python3 -m pip install -U pip
python3 -m pip install git+https://github.com/ax3l/yt.git@fix-gcc5

@@ -42,4 +43,4 @@ fi
# Step 3: install yt
$PIP install -e .
Copy link
Contributor Author

Choose a reason for hiding this comment

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

fyi: there is no editable install with PEP517 projects anymore [1] [2]

Copy link
Member

Choose a reason for hiding this comment

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

Oh, I didn't know that! I believe a simple fix would be to use $PIP install . instead, right?

Copy link
Contributor Author

@ax3l ax3l Oct 9, 2020

Choose a reason for hiding this comment

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

Just found out as well.

Even more complicated. According to my understanding, PEP517 packages should be installed locally like this:

python3 -m pip wheel .
python3 -m pip install *whl

brave new world, I guess.

Copy link
Member

Choose a reason for hiding this comment

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

wow. Sorry for asking the naive question, but by "PEP517 project" you mean any project with a pyproject.toml file, right ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep... I know...

Copy link
Member

Choose a reason for hiding this comment

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

thanks for bringing this up, I was the person who introduced pyproject.toml to the project but wasn't aware of this :/

@ax3l ax3l force-pushed the fix-gcc5 branch 2 times, most recently from 5fd256b to a231da6 Compare October 9, 2020 07:49
@cphyc
Copy link
Member

cphyc commented Oct 9, 2020

It seems the bug triggered on OSX may be fixed by replacing -fopenmp by -fopenmp=libomp (https://stackoverflow.com/questions/47822547/non-default-compilers-gcc-or-vanilla-clang-on-macos-high-sierra-linking-issue/50313990#50313990). I don't understand why it is failing now and used to work before?

@cphyc
Copy link
Member

cphyc commented Oct 9, 2020

I am sorry, I pushed onto your branch by mistake. I meant to push on my fork instead…

Copy link
Contributor Author

@ax3l ax3l left a comment

Choose a reason for hiding this comment

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

The compiler flags are wrong.

setup.py Outdated Show resolved Hide resolved
setup.py Outdated Show resolved Hide resolved
setup.py Outdated Show resolved Hide resolved
Copy link
Contributor Author

@ax3l ax3l left a comment

Choose a reason for hiding this comment

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

Fix compiler flags for OpenMP and C++ std.

@ax3l
Copy link
Contributor Author

ax3l commented Oct 9, 2020

@cphyc can you please add the bug label to this PR? the mergable CI test fails due to that missing classification.

setup.py Outdated
@@ -36,8 +37,20 @@
with open("README.md") as file:
long_description = file.read()

OMP_CONFIG = defaultdict(
lambda: ["-fopenmp"], {"unix": ["-fopenmp"], "msvc": ["/openmp"]}
Copy link
Contributor Author

@ax3l ax3l Oct 9, 2020

Choose a reason for hiding this comment

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

comment on @cphyc's change here:

unix: this is a bit optimistic but will work as before for GCC and Clang at least

Copy link
Contributor Author

@ax3l ax3l Oct 9, 2020

Choose a reason for hiding this comment

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

furthermore: AppleClang does not support OpenMP on a vanilla macOS.
If you want to unconditionally add an OpenMP prerequisite, you could install brew install libomp on CI (and need to document this new dependency on macOS). with AppleClang, this will still not be a -fopenmp flag then, but another set of flags.

Practically, one might want to implement a compiler check and keep OpenMP optional. Maybe instead of duplicating and guessing -fopenmp here, refactor check_for_openmp() in setupext.py to return the OpenMP flags (compiler and linker) it found to be working?

@ax3l
Copy link
Contributor Author

ax3l commented Oct 9, 2020

@cphyc if compile errors occur in the yt cythonization process then the overall build process does not always abort.

I am no cython / distutils expert, but ideally this should be addressed as well, in an independent PR: users get faulty installs because such errors are not aborting the build process and get lost between many build output messages. Ideally, abort on first build error.

@RevathiJambunathan
Copy link
Contributor

@ax3l Thank you for this PR!
I tried installing yt from your branch and I am able to successfully import it.

(yt_env) rjambunathan@zilla:~/Documents/SOFTWARES/yt$ python
Python 3.7.9 (default, Aug 18 2020, 06:24:24) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import yt
>>> yt.__version__
'4.0.dev0'

setup.py Outdated
)

_COMPILER = get_default_compiler()

if check_for_openmp():
Copy link
Member

Choose a reason for hiding this comment

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

check_for_openmp() makes some assumptions about openmp flags. As a result your code will only be called only if -fopenmp works, otherwise it will default to []

Copy link
Contributor Author

@ax3l ax3l Oct 9, 2020

Choose a reason for hiding this comment

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

yes, the assumption about flags (tested and applied) should be in one place, e.g. check_for_openmp. we currently duplicate the flags (and tested assumptions).

note that I did not put this into the change set.

@pep8speaks
Copy link

pep8speaks commented Oct 9, 2020

Hi there, @ax3l! Thanks for updating this PR.

There are currently no PEP 8 issues detected in this Pull Request. Hooray! 🎆

Comment last updated at 2020-12-02 16:19:36 UTC

@ax3l
Copy link
Contributor Author

ax3l commented Oct 9, 2020

@cphyc I simplified and fixed the compiler logic changes you pushed on this PR.

If you don't mind, I would love to not add features in this bugfix PR. If you like to widen the support for compilers and OpenMP to more platforms, can we do so in a follow-up PR? I would suggest to improve the compile tests performed in check_for_openmp by just testing more known flags of popular compilers. Let's focus on the bugfix here.

@ax3l ax3l force-pushed the fix-gcc5 branch 3 times, most recently from f0a7b1e to 9647efd Compare October 9, 2020 20:15
setup.py Show resolved Hide resolved
@matthewturk
Copy link
Member

matthewturk commented Oct 9, 2020 via email

@cphyc cphyc added bug infrastructure Related to CI, versioning, websites, organizational issues, etc labels Oct 14, 2020
@cphyc
Copy link
Member

cphyc commented Oct 14, 2020

Hm, I wonder why macOS still tries to build with OpenMP and what is wrong with the erf on Windows?

According to storpipfugl/pykdtree#51, this is an issue on pykdtree's side. One solution is to not use openmp when compiling on MacOSX. This can be done by setting USE_OMP=0 in the environment variables.

I have tried that in cphyc@2ad8d1b, and it seems to do the trick, but then yt's build fails on OSX... I am still investigating.

@cphyc
Copy link
Member

cphyc commented Oct 14, 2020

Good news, with the HEAD of https://github.com/cphyc/yt/tree/fix-gcc5 (cphyc@af550d9), the OSX job now builds! Note that it still doesn't work with Windows.

[EDIT]: now working with Windows

@cphyc
Copy link
Member

cphyc commented Oct 14, 2020

I've issued my fixes in another PR (#2943), which hopefully should contribute to make the tests pass on this one.

Copy link
Member

@cphyc cphyc left a comment

Choose a reason for hiding this comment

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

Provided the tests pass, I would be happy to merge this!

Comment on lines +16 to +17
cdef extern from "<cmath>" namespace "std":
bint isnormal(double x) nogil
Copy link
Member

@cphyc cphyc Oct 15, 2020

Choose a reason for hiding this comment

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

Note: for some reason, Visual Studio doesn't happy about this. However, if we replace by

Suggested change
cdef extern from "<cmath>" namespace "std":
bint isnormal(double x) nogil
from libc.math cimport isnormal

or

Suggested change
cdef extern from "<cmath>" namespace "std":
bint isnormal(double x) nogil
cdef extern from "<math.h>":
bint isnormal(double) nogil

it compiles.

@cphyc
Copy link
Member

cphyc commented Oct 28, 2020

/isort

@cphyc
Copy link
Member

cphyc commented Oct 28, 2020

@neutrinoceros @Xarthisius @ax3l I have pushed some more commits to make the Windows build build, do you think this is ready to go? I have added some code myself so I don't feel like pushing the merge button ;)

[EDIT]: I just realized b181ee4 may cancel the effect of 3347196 (esp. the cdef extern from "<cmath>" namespace "std": bit, which was preventing the windows build). Maybe it would be worth reapplying b7ccea3, to ensure it compiles with GCC5.

[EDIT2]: I have now checked locally that the gcc-5 build works, so this is ready to go on my side

@cphyc cphyc force-pushed the fix-gcc5 branch 2 times, most recently from adf26db to 5adf61f Compare October 29, 2020 21:20
@cphyc cphyc added the yt-4.0 feature targeted for the yt-4.0 release label Nov 13, 2020
.travis.yml Outdated
@@ -17,6 +17,8 @@ addons:
- proj-bin
- libgeos-dev
- libopenmpi-dev
- gcc-5
- g++-5
Copy link
Member

@Xarthisius Xarthisius Nov 18, 2020

Choose a reason for hiding this comment

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

Our testing setup change a bit with the merge of #2963, so this will need to be updated. However, I don't think we want to exclusively use gcc-5 in all our builds. Instead it would be worthwhile to set up a separate, compile-only test.

Comment on lines +43 to +45
CPP03_CONFIG = defaultdict(
lambda: ["-std=c++03"], {"unix": ["-std=c++03"], "msvc": ["/std:c++03"]}
)
Copy link
Member

Choose a reason for hiding this comment

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

I don't think it's used anywhere. At least git grep doesn't show anything. If I'm not missing anything, let's not add things that might be used, but are not.

@@ -3,7 +3,7 @@
# distutils: sources = yt/utilities/lib/cykdtree/c_utils.cpp
# distutils: depends = yt/utilities/lib/cykdtree/c_kdtree.hpp, yt/utilities/lib/cykdtree/c_utils.hpp
# distutils: language = c++
# distutils: extra_compile_args = -std=c++03
# distutils: extra_compile_args = CPP14_FLAG
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't it be CPP03_FLAG that I couldn't find in previous comment ?

@@ -2,7 +2,7 @@
# distutils: sources = yt/utilities/lib/cykdtree/c_utils.cpp
# distutils: depends = yt/utilities/lib/cykdtree/c_utils.hpp
# distutils: language = c++
# distutils: extra_compile_args = -std=c++03
# distutils: extra_compile_args = CPP14_FLAG
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't it be CPP03_FLAG that I couldn't find in previous comment ?

Copy link
Member

Choose a reason for hiding this comment

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

It depends, this was changed assuming that one flag was better than two. In this approach, the default C++ language version is C++14. If we want to make minimal changes, then this should be replaced by CPP03_FLAG. What do you think is best?


_COMPILER = get_default_compiler()

omp_args, _ = check_for_openmp()
Copy link
Member

Choose a reason for hiding this comment

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

If we are distinguishing between compile and link flags inside check_for_openmp(), shouldn't we do the same thing during cythonization, i.e. use two separate aliases? Otherwise, why return two variables?

@munkm
Copy link
Member

munkm commented Dec 2, 2020

/isort

@munkm munkm merged commit 1905842 into yt-project:master Dec 4, 2020
@ax3l ax3l deleted the fix-gcc5 branch December 4, 2020 22:20
@ax3l
Copy link
Contributor Author

ax3l commented Dec 4, 2020

Thank you everyone for getting this PR done and merged.

@RevathiJambunathan just a last check, does the yt master branch compile again on your system with GCC 5?

@munkm
Copy link
Member

munkm commented Dec 4, 2020

Thank you so much for the fix!! We really appreciate your contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug infrastructure Related to CI, versioning, websites, organizational issues, etc yt-4.0 feature targeted for the yt-4.0 release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fresh yt installation not importing
9 participants