I would prefer to either use create_test_sourcelist or use an upstream Fortran unit tester like Fortuno.

This would minimize the executables displayed in IDEs, faster to build, and it is easier to add tests (less poilerplate compared to writing Program for each one)

I see your point.

I could not figure out how to put multiple test functions in one file, which is for easier writing and reading the test code. Using create_test_sourcelist, it registers one function per one file, as far as I tried. So if I want to add more tests, I thought I had to create a number of files. If this point is overcome, surely what you explained is better.

Totally agree with you. I would like it in a similar file as well.

Here is a design choice to consider though. Do we want ctest to be able to call subfunctions as well?

For example:

# Loop over all main tests
foreach (test ${TestsToRun})
  get_filename_component(test_name ${test} NAME_WE)
  # Check if we have subtests defined
  if (${SubTests_${test_name}})
    # Loop over all subtests
    foreach (subtest ${SubTests_${test_name}}
      # Call test via ${FortranTests_Executable} ${test_name} ${subtest}
      # E.g.: ./FortranTests_Executable test_fortran_spg_get_symmetry test_rutile112
      add_test(NAME "${test_name}/${subtest}"
               COMMAND $<TARGET_FILE:FortranTests> ${test_name} ${subtest})
    endforeach ()
  else ()
    # Only run main test
    add_test(NAME "${test_name}"
             COMMAND $<TARGET_FILE:FortranTests> ${test_name})
  endif ()
endforeach ()

I can show you how to implement that from the argc/argv if you need help on that.

I see. It is a good trick. If I understand it correctly, I need two lists, ${TestsToRun} and ${SubTests_${test_name}. Am I correct?

I can show you how to implement that from the argc/argv if you need help on that.

Yes, I need your help. I would appreciate it.

Ok, I'll push a commit directly here with an example for test_fortran_spg_get_symmetry maybe tonight or tomorrow.

Maybe worth making a:

interface assert
  module procedure assert_int, assert_...
end interface

I agree! I am not yet familiar with fortran and just learning right now. Hopefully this will be done at near future.

Yeah Fortran is a mess of a language, I can barely get a footing into it without cursing

Yeah, just add an if (NOT) statement so that devs can choose their own workflow, like this:

Naming is arbitrary, that's what I implement in octopus.

As for the other fix in spglib_f08, I was refering to these lines:

https://github.com/atztogo/spglib/blob/a0dfab447faced40b70f02a9783b477e108110a9/fortran/CMakeLists.txt#L9-L11

The target_include_directories there is so that the Fortran compilers includes the folder where the .mod file is, either CMAKE_Fortran_MODULE_DIRECTORY during when we build locally (BUILD_INTERFACE), or the location where we installed it to (CMAKE_INSTALL_INCLUDEDIR at INSTALL_INTERFACE). So something like this:

target_include_directories(spglib_f08 PUBLIC
		"$<BUILD_INTERFACE:${CMAKE_Fortran_MODULE_DIRECTORY}>"
		"$<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>")

One thing I didn't test, but it seemed to be working is that for Fortran modules (maybe even C++ modules in the future), we do not need to include the folder with the .F90 file (as we do with .h in C/C++). In principle we could remove spglib_f08.F90 from the install, but we need to test it out a bit further.