Re-enable osx builds (closes #95)

[minhqdao]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Closes #95

Re-enable macOS builds (osx-64 + osx-arm64)

osx was originally added in #29 for debuggability, hit a segfault with BUILD_SHARED_LIBS=ON (MLIR TypeIDs duplicated across the many flang dylibs → dialect-registration collision), and was removed in #31 with the door left open: "We can still re-add this at a later point if we want."

The fix that didn't exist in 2023 does now: -DMLIR_LINK_MLIR_DYLIB=ON (+ -DLLVM_LINK_LLVM_DYLIB=ON) routes all MLIR/LLVM code through the monolithic libMLIR.dylib/libLLVM.dylib that conda-forge's osx llvmdev/mlir already ship — the same combination Homebrew's flang formula uses. Applied on osx only; linux/win are functionally unchanged (identical binaries, bumped build number).

Re: "why not gfortran" — conda-forge already builds the entire LLVM stack for osx; flang is the only missing piece, so this completes a stack rather than duplicating one, and there's real demand (#95, emscripten-forge, setup-fortran).

Tests: the unix test now also compiles a hello-world to an object file (flang -c), exercising the frontend where the 2023 segfault lived without needing the runtime for linking.

Note: flang-rt and the flang_osx-* activation packages remain separate follow-ups (#119, #63).

[minhqdao]

@conda-forge-admin, please rerender

[conda-forge-admin]

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.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/33100431861. Examine the logs at this URL for more detail.}

[minhqdao]

@h-vetinari, @isuruf PR is ready for review

[h-vetinari]

Thanks for the PR. Note that discussion in #95 is not resolved yet, in the sense that it's not clear whether we actually want a second fortran compiler on osx (especially given the situation with the way that fortran modules ABI is compiler-dependent).

In any case, for the purposes of this PR, you probably want to add

provider:
  osx_arm64: default

to conda-forge.yml and rerender; otherwise you're only getting the old osx-64 here, and not the newer osx-arm64 (M1+).

PS. I've pointed your to 22.x for now (to avoid conflicts after #137). If you want I can also point it back to the main branch, but then you'd have to rebase.

[minhqdao]

@conda-forge-admin, please rerender

[minhqdao]

Thanks for the review and the pointer to provider. It's added and the feedstock re-rendered, both osx_64_ and osx_arm64_ passing now.

22.x is fine for now. Once it's merged, I can open a follow-up against main.

On the bigger question: I've written up my thoughts in #95, and I'm happy to wait for whatever that discussion concludes.