Prepare and pursue Chapel's application to E4S about chapel

[arezaii]

I took a preliminary pass at comparing the requirements to the project's state. Here is what I think we're starting from, roughly:

• P1 Spack-based Build and Installation - Our spack package builds and installs the compiler and runtime, with several variants for configuring the installation.
• P2 Minimal Validation Testing - TBD - basically contributing a test for the Chapel spackage to the e4s testing repo. PR (needs review) E4S-Project/testsuite#74
• P3 Sustainability - The Chapel sources for the spackage are the same as Chapel's normal release and share a release cycle cadence of once every 3 months.
• P4 Documentation - The Chapel project documentation is available at https://chapel-lang.org/docs/
• P5 Product Metadata - TBD - need to provide some brief info to populate the fields on this table (https://e4s-project.github.io/DocPortal.html) PR accepted at E4S-Project/E4S-Documenter#9
• P6 Public Repository - Chapel sources are available from the public repository github.com/chapel-lang/chapel
• P7 Imported Software - TBD - we mostly accomplish this by providing spack variants for hwloc, llvm, jemalloc, etc
• P8 Error Handling - Chapel provides helpful error messages
• P9 Test Suite - Chapel provides support for make check through spack test run chapel (need more tests than that)

[jabraham17]

Yes we did carry forward the patch from #25507, and currently that is the only patch applied to qthreads on main today.

[bonachea]

PRs against E4S repositories associated with P2 and P5 above are now merged, and Chapel now appears in the online E4S product list as a "Member Product".

Our understanding is that Chapel builds should first appear in the E4S 24.11 release that will be packaged in November.

I concur with @arezaii that P7 is also mostly accomplished, as the Spack package variants currently allow swapping in alternative versions of the following bundled third-party dependencies:

• gasnet
• gmp
• hwloc
• jemalloc
• libfabric
• libunwind
• llvm

This list includes all the dependencies for which the Chapel build system currently documents support for =system settings.

Dependencies currently missing =system build system support and variants in the chapel spackage include:

• qthreads
• re2

Both of these are available in Spack, and could be added as variants with additional effort. However it appears bundled versions of both libraries include some Chapel-specific patches, so vanilla versions might not function correctly without additional Spack-driven patching.

[bradcray]

Of those two packages, the re2 patches are necessary for using re2 with Chapel's IO features, and we were unsuccessful in getting them accepted back upstream when we tried (many years ago now, admittedly).

qthreads feels like a package where we'd have a much better chance of using the official Spack formula—I believe that most qthreads patches have traditionally been bug fixes that we've applied before they were available in an official release, though I know we added one recently to work around a C/C++ issue (#25507 which may be addressed in future qthreads releases, though I don't think we know yet). And we also recently updated our bundled version to match Qthreads' latest release, which I believe removed the need for any previous bug fix patches (#25210). @jabraham17 would be the expert on the latter, and would also know whether we carried forward the patch from #25507.