[dev] build from main for testing flang-rt

[h-vetinari]

For testing llvm/llvm-project#110217

Also remove the emscripten changes, which have been moved to a separate branch.

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

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

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

[h-vetinari]

@isuruf, could you PTAL here? This is for testing llvm/llvm-project#110217, which proposes to introduce flang-rt (similar relationship to flang as compiler-rt to clang).

This PR is just a POC to see how things would work together, but my idea would be to create a separate feedstock flang-rt after that upstream PR is merged. It would come after flang, but before flang-activation. I think it would also make sense to turn libflang into an alias for flang-rt, for continuity (at least for a couple releases).

Would appreciate your thoughts!

PS. Note that windows has no builds for now because upstream had a major build regression that killed builds for conda-forge/clangdev-feedstock#330 (& subsequent packages). This should hopefully be fixed soon-ish.

[h-vetinari]

Aside from some minor bugs (and shared runtime lib support on unix) still being worked out upstream, could you please let me know if you're alright with the approach structurally @isuruf?

(i.e. flang-rt being a separate feedstock depending on flang; the activation then depending on both)

[isuruf]

Sounds good to me. We probably don't need to have a libflang->flang-rt redirection, because it looks like flang-rt is a colleciton of static libraries just like compiler-rt

[h-vetinari]

Thanks for the response

it looks like flang-rt is a colleciton of static libraries just like compiler-rt

Shared support is being worked on upstream: llvm/llvm-project#120213

Shared libs on windows is still a bit further out, but should also follow. If we want to switch to the shared libs, then we'd switch on the run-export for flang-rt.

We probably don't need to have a libflang->flang-rt redirection

This was more from the POV that we've been producing packages (both with current and former flang) that have a run-dep on libflang, and I thought it might be prudent to avoid that the old builds gets coinstalled with flang-rt, by turning libflang into a wrapper around flang-rt