add missing pin to libcxx-devel; fix libcxx run-export

[h-vetinari]

Oversight in #311, see here

[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/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

@isuruf, so it turns out that adding a version pin on libcxx-devel runs into a bunch of issues:

• it conflicts with libcxx {{ cxx_compiler_version }} host pins (for packages depending on clangxx)
• it would cause a bootstrap issue because we don't have libcxx X+1 when we first build clangdev X+1

The bootstrapping I think I solved with a174f3a, but for the first issue I'm not 100% sure.

I think we could loosen the libcxx pins to build here, but not 100% sure why those were there in the first place.

[h-vetinari]

I would have expected the "use same as top-level" to have something to do with having the same hash of the host environment and maybe not busting the cache to rebuild things unnecessarily; however, I'm not sure from 91ad7d6 resp. ac155e5 if that's actually the case? I've removed it now to try and see.

[h-vetinari]

I should probably update the comment # Use the same requirements as the top-level requirements for these outputs, but since I don't know/understand the original reason, I can only remove them. If you have input on this, please let me know.

[h-vetinari]

Tentatively updating the comment now to be

# unpinned because we depend on clangxx here, which pins libcxx-devel

If we want to keep everything on the same libcxx version, we could go one step further and pin everything to {{ version }}, now that we're building libcxx before clangdev.

[isuruf]

You need https://github.com/conda-forge/libcxx-feedstock/pull/190/files#r1737146437

[h-vetinari]

You need https://github.com/conda-forge/libcxx-feedstock/pull/190/files#r1737146437

Ah, thanks. OK, I was waiting for your feedback on that PR (and thought we'd want to fix the compilers first).

[h-vetinari]

You need https://github.com/conda-forge/libcxx-feedstock/pull/190/files#r1737146437

I merged conda-forge/libcxx-feedstock#192, which is the backport that's relevant here, as our cxx_compiler_version is still on 16 in this PR (which is nice because it lets us do this without touching the current compiler default version or newest libcxx).

However, this is still not enough, because now that we want clangxx to run-depend on libcxx-devel {{ version }}, it can then not be installed anymore for outputs depending on clangxx, which want to use libcxx-devel {{ cxx_compiler_version }}.

That particular problem should be solvable by reinstating the commit (1ab6b2d) I had before for loosening the libcxx-devel constraint in outputs depending on clangxx, but I've realised that this still creates bootstrapping problems.

Whether we put the version pin in run_constrained: or in run: is immaterial, wanting to install clangxx during the build here means we're creating a cycle here with the libcxx feedstock, which depends on clangdev. The saving grace (perhaps?) is that it does so only on linux. IOW, we can build libcxx 19 on osx using older compilers (if we merge with broken CI on linux, or add a bootstrapping switch), and then build clangdev + the rest of the stack.

[h-vetinari]

The saving grace (perhaps?) is that it does so only on linux. IOW, we can build libcxx 19 on osx using older compilers (if we merge with broken CI on linux, or add a bootstrapping switch), and then build clangdev + the rest of the stack.

Even better, I tried building libcxx without clangdev, and it builds correctly, no problems with the link check, and the content looks unchanged (no extra headers or libs).

[h-vetinari]

This and conda-forge/libcxx-feedstock#190 are now passing, and I believe should cover all bases, including the bootstrapping case. PTAL @isuruf

[h-vetinari]

Gentle ping @isuruf

[h-vetinari]

If you have some input on the thread above, please let me know. :)

[h-vetinari]

Alright putting this in for now, but happy to iterate further on the upcoming PRs for 19.1.0.rc4 & then 19.1.0