-
Notifications
You must be signed in to change notification settings - Fork 673
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
BLD: compiler recognition on MacOS #3109
Comments
@tylerjereddy I think I'm misunderstanding the issue. Is it that somehow the If so, out of curiosity what's the output of |
@IAlibay Yes, that's what happens--I'd say that ideally the mechanism of compiler detection should not rely on string analysis alone--for example, we just do Here's a small sample of
|
I wonder if NumPy distutils has something we can borrow for this, probably |
So probably a very naive question (especially since we go through the trouble of using I realise folks could technically alias I can see a case of someone calling your above case |
I think 'gcc' more often means Indeed, it is me who has changed something by using genuine gcc instead of the "default alias to clang." That should be fair game though. I'm pretty sure most robust solutions to the problem involve a |
Sorry to chime in a bit here but down the road at distopia we use something like: #ifdef __clang_major__
#define DISTOPIA_CLANG 1
#endif
#ifdef __INTEL_COMPILER
#define DISTOPIA_ICC 1
#endif
#if defined(__GNUC__) && !defined(DISTOPIA_CLANG) && !defined(DISTOPIA_ICC)
#define DISTOPIA_GCC 1
#endif
#if defined(_MSC_VER) && !defined(DISTOPIA_ICC)
#define DISTOPIA_MSVC 1
#endif you could then combine with something like: static_assert(DISTOPIA_CLANG != 1, "compiler is not clang"); which will fail to compile if not on clang if you want to go for the |
Fixes #3109 ## Work done in this PR * gracefully handle the case where `gcc` toolchain in use on MacOS has been built from source using `clang` by `spack` (so it really is `gcc` in use, not `clang`) ## Notes * we could try to add regression testing, but a few problems: - `using_clang()` is inside `setup.py`, which probably can't be safely imported because it has unguarded statements/ code blocks that run right away - testing build issues is typically tricky with mocking, etc. (though in this case, probably just need to move `using_clang()` somewhere else and then test it against a variety of compiler metadata strings
Fixes MDAnalysis#3109 ## Work done in this PR * gracefully handle the case where `gcc` toolchain in use on MacOS has been built from source using `clang` by `spack` (so it really is `gcc` in use, not `clang`) ## Notes * we could try to add regression testing, but a few problems: - `using_clang()` is inside `setup.py`, which probably can't be safely imported because it has unguarded statements/ code blocks that run right away - testing build issues is typically tricky with mocking, etc. (though in this case, probably just need to move `using_clang()` somewhere else and then test it against a variety of compiler metadata strings
* added get_connections * modified tests for atoms.bonds/angles/dihedrals etc * modified parsers and things to use get_connections or bonds * updated CHANGELOG * pep8 * undo half of PR 3160 * add intra stuff * Update package/MDAnalysis/core/groups.py Co-authored-by: Jonathan Barnoud <jonathan@barnoud.net> * tighten up base class checking * update docstring * suppres warnings * Use absolute file paths in ITPParser (#3108) Fixes #3037 Co-authored-by: Lily Wang <31115101+lilyminium@users.noreply.github.com> * Adds aromaticity and Gasteiger charges guessers (#2926) Towards #2468 ## Work done in this PR * Add aromaticity and Gasteiger charges guessers which work via the RDKIT converter. * BLD: handle gcc on MacOS (#3234) Fixes #3109 ## Work done in this PR * gracefully handle the case where `gcc` toolchain in use on MacOS has been built from source using `clang` by `spack` (so it really is `gcc` in use, not `clang`) ## Notes * we could try to add regression testing, but a few problems: - `using_clang()` is inside `setup.py`, which probably can't be safely imported because it has unguarded statements/ code blocks that run right away - testing build issues is typically tricky with mocking, etc. (though in this case, probably just need to move `using_clang()` somewhere else and then test it against a variety of compiler metadata strings * Remove ParmEd Timestep writing "support" (#3240) Fixes #3031 * Adding py3.9 to gh actions CI matrix (#3245) * Fixes #2974 * Python 3.9 officially supported * Add Python 3.9 to testing matrix * Adds macOS CI entry, formalises 3.9 support * fix changelog * special metaclass * move function down * tidy code Co-authored-by: Jonathan Barnoud <jonathan@barnoud.net> Co-authored-by: Aditya Kamath <48089312+aditya-kamath@users.noreply.github.com> Co-authored-by: Cédric Bouysset <bouysset.cedric@gmail.com> Co-authored-by: Tyler Reddy <tyler.je.reddy@gmail.com> Co-authored-by: Irfan Alibay <IAlibay@users.noreply.github.com>
Expected behavior
Build system automagically handles both
clang
and "genuine"gcc
on MacOS. This command should work withspack
builtgcc
compiler toolchain loaded on macOS 10.15.7:python setup.py develop
Actual behavior
The build system thinks it is using
clang
but it is actually usinggcc
built withclang
byspack
(not the "alias" you would normally have on a "normal" mac machine).Code to reproduce the behavior
python setup.py develop
Python 3.7.4, though not likely relevant. Latest
develop
branch.Hacky work around, that hints at part of code involved:
The text was updated successfully, but these errors were encountered: