Removed from being a draft to check concretization in pipelines

@alalazo can you time concretization on this?

Based on this:

C_EXT = {".c"}
CXX_EXT = {".cpp", ".cc", ".cxx", ".c++"}
FORTRAN_EXT = {".f", ".f77", ".f90", ".f95", ".f03", ".f08"}

I think we're missing a few suffixes -- these are what cloc uses:

> cloc --show-lang=c
C                          (c, cats, ec, idc, pgc)
> cloc --show-lang=c++
C++                        (C, c++, cc, CPP, cpp, cxx, h++, inl, ipp, pcc, tcc, tpp)
> cloc --show-lang="fortran 77"
Fortran 77                 (F, F77, f77, FOR, FTN, ftn, pfo)
> cloc --show-lang="fortran 90"
Fortran 90                 (F90, f90)
> cloc --show-lang="fortran 95"
Fortran 95                 (F95, f95)

And I guess I would also add hpp for C++ as I see that frequently. Once @alecbcs gets the source mirror fully downloaded here, can we go and re-run your script and do some sampling to check it?

Once @alecbcs gets the source mirror fully downloaded here, can we go and re-run your script and do some sampling to check it?

Don't see the point of waiting for that. The # generated comment is enough to update packages at a later stage, I doubt it can be improved.

I've force pushed the PR with the patch generated by https://github.com/haampie/spack-language-to-package-py/actions/runs/9952936512/job/27495303284, the number of changed files is 89, half of which is about .C classified as C++ now instead of C, so that leaves about 1.5% of package changes due to flaky downloads compared to last run. That's likely already below the false positive threshold, we don't need 100% accuracy on 90% reliable data...

IMO let's merge this now, it's easy enough to fix things later. I don't want to rebase this.

I confirm that I see no significant differences in concretization times:

• Spack: 0.23.0.dev0 (89c0b4a)
• Python: 3.11.5
• Platform: linux-ubuntu20.04-icelake
• Concretizer: clingo

radiuss.pr.csv
radiuss.develop.csv
radiuss.txt

A few specs seems slower, a few faster. Notably, py-deephyper (which is kind of unstable in concretization time) is 30 sec. faster in this branch using gcc. Maybe adding information on fortran/cxx virtuals helped concretizaton.

I would be for merging this asap,

apart from the significant differences no significant differences?

apart from the significant differences no significant differences?

I mean, there are no trends for things getting generally slower or faster due to this PR 😉

I see tons of rebuilds. Non-determinism?

Edit: nope it was 40b3909

FWIW, there is non-determinism, but not due to this PR :)

These two specs

warpx ^openpmd-api@0.14
warpx ^openpmd-api@0.15

have the same "version badness", because

• openpmd-api@0.14 is 3 versions from latest but does not depend on toml11
• openpmd-api@0.15 is latest, but depends toml11 3 versions from latest

🎉

not a blocker here, just happened to be that warpx ^openpmd-api@0.14 was picked and that exposed a missing compat bound.

cairo failure is also unrelated and also caused non-deterministic concretization. Fix in #45272

Thank you, @haampie - both for the excellent detection (confirming in #45251) and for fixing the WarpX / openPMD-api constraint.