WIP: {chem,phys}[GCCcore/11.3.0] ASAP3 v3.12.12, openkim-models v20210811, kim-api v2.3.0 w/ Python 3.10.4

[schiotz]

(created using eb --new-pr)

[boegelbot]

@schiotz: Tests failed in GitHub Actions, see https://github.com/easybuilders/easybuild-easyconfigs/actions/runs/7673601287
Output from first failing test suite run:

FAIL: test_pr_CMAKE_BUILD_TYPE (test.easyconfigs.easyconfigs.EasyConfigTest)
Make sure -DCMAKE_BUILD_TYPE is no longer used (replaced by build_type)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/easybuild-easyconfigs/easybuild-easyconfigs/test/easyconfigs/easyconfigs.py", line 1317, in test_pr_CMAKE_BUILD_TYPE
    self.fail('\n'.join(failing_checks))
AssertionError: build_type was set to the default of 'Release'. Omit this to base it on toolchain_opts.debug: kim-api-2.3.0-GCCcore-11.3.0.eb

----------------------------------------------------------------------
Ran 19026 tests in 741.223s

FAILED (failures=1)
ERROR: Not all tests were successful

bleep, bloop, I'm just a bot (boegelbot v20200716.01)
Please talk to my owner @boegel if you notice me acting stupid),
or submit a pull request to https://github.com/boegel/boegelbot fix the problem.

[schiotz]

Test report by @schiotz
SUCCESS
Build succeeded for 5 out of 5 (4 easyconfigs in total)
slid.fysik.dtu.dk - Linux CentOS Linux 7.9.2009, x86_64, Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz, Python 3.6.8
See https://gist.github.com/schiotz/83bccddfc0c350181ebb3d53069f0ff5 for a full test report.

[schiotz]

I am marking this as WIP for now, as I have to understand why kim-api is already present at the GCC level and not at GCCcore, and how to handle this for the intel toolchain version of Asap.

[schiotz]

@branfosj
I see that you have moved kim-api from GCCcore to GCC in December. It has an effect on this PR. I am sure there is a good reason, could you fill me in, since that will help me handling this PR and kim-api for the Intel toolchain as well.

[branfosj]

@branfosj I see that you have moved kim-api from GCCcore to GCC in December. It has an effect on this PR. I am sure there is a good reason, could you fill me in, since that will help me handling this PR and kim-api for the Intel toolchain as well.

In kim-api there are fortran .mod files and these are compiler specific (see https://fortranwiki.org/fortran/show/Library+distribution). This means that there should be separate kim-api at GCC and intel-compilers level.

In EasyBuild 5 we will detect and error if we find these (see easybuilders/easybuild-framework#4203).

[schiotz]

Thank you @branfosj

I guess the reason I have not had problems with this that the Fortran files have only been used by openim-models which was also on GCCcore level, even if the resulting .so files were loaded into an Intel compiled Python module. I will play with this in the 2023a toolchain and come back to this PR once I have the details worked out. It should not be difficult.

Once upon a time, the KIM API insisted on compiling with GCC even when building with the Intel toolchain in EasyBuild, but I think that was before they revamped their build system to use cmake.