Add hardened libcxx builds in separate label

[h-vetinari]

It turns out that the enabling the "fast" hardening mode (c.f. #136) was a bad idea (see #162), not least because the default assertion handler just crashes without any useful information. Go back to no hardening for the production builds, but add a maximally hardened (thus better crash information) variant in a separate label.

[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.

[jjerphan]

Thank you, @h-vetinari.

I strongly support such debug variants.

[jjerphan]

Naive question: what is the pros of using another build string and label over using a track feature for such variant?

[h-vetinari]

track-features don't support a way to explicitly select the package (except by channel priority¹), and we wouldn't be able to do a run-export. Arguably the latter isn't strictly necessary (because the hardening modes should be ABI-compatible), but after the recent experience with libcxx 18.x I want to start off defensively.

also, since libcxx has nothing that affects the build strings, we're not tight on real estate currently. ;-)

Footnotes

1. but at that point you don't need to weigh down builds anymore anyway; track features are useful for preferring one variant over another if both live in the same channel ↩

[ianthomas23]

I've locally built and used the hardened package and it is working as expected.

[h-vetinari]

OK, since all the relevant changes here are restricted to a separate label, I'm putting this in. Let's hope this helps with debugging! :)