Add testing against older clangs on osx

[h-vetinari]

This is my hypothesis, given that I hadn't noticed that the last libcxx-testing build still required clang 11! Should be fixed now by conda-forge/libcxx-testing-feedstock#2

See below

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[isuruf]

We are using older clangs with newer libcxx. For eg: cling, root, etc.

[h-vetinari]

We are using older clangs with newer libcxx.

That's a tricky situation, but it simply does not work indefinitely. It would have stopped with LLVM 16 already if I hadn't managed to revert the patch that caused the test with clang 11 to fail. It's going to get harder and harder for ever-older clangs to use current libcxx (and that setup basically gets zero testing).

Which of course is a problem because everything is geared towards only using newest libcxx (which thus becomes a run-dep of most compiled packages), see also conda-forge/clangdev-feedstock#188

So how do we square that circle?

• Stop upgrading LLVM?
• Leave cling/root/etc. in a frozen ecosystem of old libcxx?
• Manage a policy/transition somehow, where newer libcxx has a lower bound for the clang it supports?

Independently of which approach we choose, I really think we need to start testing these things, otherwise we're flying blind. What would you think about building libcxx-testing for a range of clang versions, and versioning libcxx-testing with something like 0.{{ CLANG_MAJOR }}. Then we could expand the downstream test here to something like:

      downstreams:              # [osx]
        - python-symengine      # [osx]
        - openturns             # [osx]
        # test current libcxx against a range of clang builds;
        # version correspondence is 0.{{ CLANG_MAJOR }} 
        - libcxx-testing 0.16   # [osx]
        - libcxx-testing 0.15   # [osx]
        - libcxx-testing 0.14   # [osx]
        - libcxx-testing 0.13   # [osx]
        - libcxx-testing 0.12   # [osx]
        - libcxx-testing 0.11   # [osx]
        - [however far down we manage...?]

Assuming this shows a bunch of failures, I suggest that it would be up to cling/root etc. to propose fixes. IMO it must remain a question of best-effort to support ancient compiler versions, where our entire infrastructure has moved on already. But with the above setup, at least we'd have a better picture of what would need fixing, resp. which combinations of new libcxx with old clang still work.

[h-vetinari]

Note that, compared to libcxx's support policy, we're pretty far out on a limb here - officially supported are only the last two stable releases.

Obviously we've been able to stretch this quite a bit further, and I'm not against it if it works, but that just means that at any point we could encounter a degree of breakage with old clangs that's beyond salvaging (I'm against heavily patching libcxx for that purpose - that's potentially a huge amount of work but more importantly: way more risk to get something wrong).

In any case, I have a implemented the testing idea in conda-forge/libcxx-testing-feedstock#3.

Still builds down to clang 11, as before (I kept the revert also on osx; contrary to the state of the PR at the time of the change request)