BLD: handle gcc on MacOS

[tylerjereddy]

• 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)

• 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 #3109

PR Checklist

• Tests?
• Docs?
• CHANGELOG updated?
• Issue raised/referenced?

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (develop@f2745a9). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop    #3234   +/-   ##
==========================================
  Coverage           ?   92.81%           
==========================================
  Files              ?      170           
  Lines              ?    22801           
  Branches           ?     3239           
==========================================
  Hits               ?    21162           
  Misses             ?     1591           
  Partials           ?       48           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f2745a9...271bab7. Read the comment docs.

[IAlibay]

So I have no issues with the setup file as-is, but I do wonder if this is opening a pandora's box in supporting the peculiarities for various build tools (for example, does EasyBuild also need handling differently?).

Is this the same way numpy/scipy is handling compiler identification @tylerjereddy ?

[tylerjereddy]

No, SciPy uses scipy/_build_utils/compiler_helper.py, which is a module dedicated to compiler handling. As discussed in the matching issue, they implement a small try_compile() function to only allow flags to get appended to the compile line if the compiler genuinely supports them.

We could redesign to use something like that--that may be biting off a bit more than I was hoping to chew here, though we could probably even copy-paste a decent bit of the code.

Here's an example of how it works:

    if sys.platform == 'darwin':
        # Set min macOS version
        min_macos_flag = '-mmacosx-version-min=10.9'
        if has_flag(cc, min_macos_flag):
            args.append(min_macos_flag)
            ext.extra_link_args.append(min_macos_flag)

That has_flag() function checks that the compile flag works "for real" with the compiler:

def has_flag(compiler, flag, ext=None):
    """Returns True if the compiler supports the given flag"""
    return try_compile(compiler, flags=[flag], ext=ext)

[orbeckst]

Is this starting to re-implement what automake and cmake build systems do?

[orbeckst]

I don't see any specific harm coming from being more correct in how clang is identified.

@IAlibay if you (or anyone else) has a particular view on how to proceed then please block the PR with a "Request changes".

[tylerjereddy]

Is this starting to re-implement what automake and cmake build systems do?

Yeah, basically--this discussion is also relevant: scipy/scipy#13615

I wonder if the Python ecosystem will stabilize on a common solution eventually.

[IAlibay]

I probably should have just approved in my first review 😅

Thanks for the insights @tylerjereddy, maybe we should open a separate issue to target a refresh of the build system based on what scipy does? (if it somehow fixes #3176 at the same time, then even better!).

[tylerjereddy]

Sounds good, your skepticism is justified--this isn't exactly elegant either. And we have in-house expertise with CMake, so some of our dystopia project assembly-level folks may share my irritation with having to learn meson on top of CMake, but anyway..