Addition of FPM Support

[robin-dahl]

Summary
This PR adds support for building ddX with the Fortran Package Manager. It includes changes required to build & compile the project with FPM, run the standalone executable, and use the test suite. The documentation has also been updated with instructions for using FPM with ddX.

Key Changes
Adding FPM support typically requires only limited changes, provided that the repository structure is broadly compatible with FPM's conventions.

• This PR adds the standard fpm.toml manifest file, which enables compilation of the source code via fpm build. To avoid compilation issues, #ifdef BUILD_PYBIND11 and #endif guards were added to non-Fortran source files in the src directory. Without these guards, FPM attempts to compile the C++ and Python-related files as part of the build, which leads to errors. These preprocessor guards, however, should not affect the behavior of these files in any other build configuration.
• The standalone executable can be run with fpm run [path/to/input].txt (for instance, fpm run tests/Input-example.txt). As usual for FPM, this command also compiles the project prior to execution, so an explicit fpm build step is optional.
• Normally, the test suite would be run with fpm test. For ddX, however, this is currently not possible because several tests require individual command-line arguments. While FPM allows arguments to be passed to specific target tests, for example fpm test --target ddlpb_esolv -- tests/data/ddlpb_force.txt, a general fpm test command would only work for test suites with a uniform execution structure. To address this, this PR adds a Python wrapper in the tests directory. The wrapper runs all unit and standalone tests, analyzes the output, and provides a summary. The full test suite can therefore be run in one go with python tests/fpm_tester.py.

[mnottoli]

@robin-dahl you can give a look to my changes, if you are fine with them, I will merge this.

[robin-dahl]

@mnottoli I see that you removed the fpm test targets that require command-line arguments from fpm.toml. If we are fine with those tests not being part of the fpm test suite, that is okay with me. In that case, we can probably also remove tests/fpm_tester.py.
I originally added that Python wrapper so there still was one fpm-facing command that runs all relevant ddX tests, including the ones that need command-line arguments. However, I now see that the wrapper currently has a bug: when fpm is asked to run a target that is no longer declared in fpm.toml, it exits with returncode 0 and prints "No tests to run". The wrapper only checks returncode == 0, so it incorrectly reports those cases as PASS instead of warning that no test was actually run (that's why this script does not crash currently).

So the wrapper needs fixing if we want to use it. What is your preference for how these tests should be treated? Do you like the idea of the Python wrapper (then I would correct the bug of course), or are you okay with the command-line-argument tests genuinely not being runnable through fpm? In case of the latter, that should be noted in the documentation (together with the removal of the Python wrapper explanation)

[mnottoli]

Thanks for noticing.

I think it is fair to put fpm in a state that "fpm test" doesn't fail by definition, which means removing the tests with command line arguments. If they then merge this fortran-lang/fpm#1276, we can put back those tests.

In the meanwhile, I will translate the wrapper in fortran, and add another test for fpm which goes through it.
This should be the cleanest approach.

Maybe I will also add a subset of fpm tests in the github CI - just to make sure that we don't mess up with fpm in any further development.

[robin-dahl]

That sound like a good idea! I was not aware of this fpm issue, seems promising

[mnottoli]

Hi @robin-dahl, I made a few modifications:

• the python wrapper was replaced with two fortran wrappers, one for tests with command arguments and one for standalone tests. The two wrappers are listed as [[test]] targets for fpm.

• In the fpm.toml, the source codes of the tests are listed as executables. Otherwise, fpm does not compile them, as they are only used through wrappers.

• I added a github CI for fpm, but as for meson, I am only testing the standalone - I think they are enough to confirm that the code is working. This is why I made two wrappers in the first place.

• I had to change slightly the python wrapper run_test.py for the standalone tests. As fpm compiles the executables in some "secret" folder, and the best way is to use fpm run, which is enabled by passing a flag --fpm.

• I noticed existing problems with both cmake and meson for the standalone tests, which are now fixed. In particular, cmake was copying run_test.py to the build dir, but then using the one from the source dir. meson was not building ddx_driver_testing at all, but for some reason it was not caught before.

I would ask you to see if these modifications do not ruin the cross compilation with tblite.

[robin-dahl]

Everything seems to work, @mnottoli, thank you!

[mnottoli]

Good to hear, I am now on this: #165