CMake: Introduce CMake dependent options and print build summary

[Growl1234]

Notes:
Out-of-source CMake build is required.
ENABLE_LIBRI/PEXSI requires ENABLE_MPI (see #7626 (comment)).
USE_CUDA_MPI requres USE_CUDA
CUBLASMP/NCCL will quietly turn off when requirement not satisfied, with no error reported

This PR introduces cmake_dependent_option with intention to make the dependency handling logic clearer from the beginning of CMake logic.

Example:

cmake_dependent_option(EXX_DEV "Enable LibRI developing features" OFF "ENABLE_LIBRI" OFF)

This means EXX_DEV is available only when ENABLE_LIBRI is set to ON, and defaults to OFF; if ENABLE_LIBRI=OFF, the EXX_DEV option will be forced to be off. So if one passes -DENABLE_LIBRI=OFF -DEXX_DEV=ON to CMake (by mistake?), the actual resulting logic will be -DENABLE_LIBRI=OFF -DEXX_DEV=OFF. (One thing that might need to care is that this logic is done by CMake without any warnings; the comment # Options requiring ... is therefore added to remind users to know what they are doing.)

cmake_dependent_option(ENABLE_ELPA "Enable ELPA for LCAO" ON "ENABLE_LCAO;ENABLE_MPI" OFF)

This means ENABLE_ELPA is available only when both ENABLE_LCAO and ENABLE_MPI are set to ON.

[Growl1234]

There is one RFC about how we should detect and show the version of MPI, as existing version detection logic seems invalid.

I currently choose to show the real MPI-standard what an MPI implementation follows, as this is generally available for any MPI implementations through a single ${MPI_CXX_VERSION}. For example:

• MPICH 5.0.1 follows MPI-5.0 standard (therefore MPICH (MPI standard: 5.0))
• OpenMPI 5.0.10 follows MPI-3.1 standard (therefore OpenMPI (MPI standard: 3.1))
• Intel MPI 2021.18 follows MPI-4.1 standard (therefore Intel MPI (MPI standard: 4.1))

However, one concern is that users might not be used to it, so might there be other easier way?

[Growl1234]

Side note: an inconsistent change is made here: ENLABLE_LIBRI will requrie ENABLE_MPI.

If enable LibRI support without MPI, compilation will report error:

[303/692] Building CXX object source/source_lcao/CMakeFiles/hamilt_lcao.dir/hamilt_lcao.cpp.o
FAILED: source/source_lcao/CMakeFiles/hamilt_lcao.dir/hamilt_lcao.cpp.o 
/usr/bin/c++ -DCOMMIT_INFO -DEXX_DM=3 -DEXX_H_COMM=2 -DMETIS -DTEST_EXX_LCAO=0 -DTEST_EXX_RADIAL=1 -DUSE_NEW_TWO_CENTER -D__EXX -D__FFTW3 -D__LCAO -D__MKL -D__SELINV -I/root/GitHub/abacus-dev/source -I/root/GitHub/abacus-dev/source/source_base/module_container -I/root/GitHub/abacus-dev/build -I/opt/intel/oneapi/mkl/2026.1/include/fftw -I/root/GitHub/abacus-dev/build/_deps/libri-src/include -I/root/GitHub/abacus-dev/build/_deps/libcomm-src/include -std=gnu++14 -O3 -g -fopenmp -MD -MT source/source_lcao/CMakeFiles/hamilt_lcao.dir/hamilt_lcao.cpp.o -MF source/source_lcao/CMakeFiles/hamilt_lcao.dir/hamilt_lcao.cpp.o.d -o source/source_lcao/CMakeFiles/hamilt_lcao.dir/hamilt_lcao.cpp.o -c /root/GitHub/abacus-dev/source/source_lcao/hamilt_lcao.cpp
In file included from /root/GitHub/abacus-dev/source/source_lcao/module_ri/Exx_LRI.h:10,
                 from /root/GitHub/abacus-dev/source/source_lcao/module_ri/Exx_LRI_interface.h:4,
                 from /root/GitHub/abacus-dev/source/source_lcao/hamilt_lcao.cpp:21:
/root/GitHub/abacus-dev/source/source_lcao/module_ri/ewald_Vq.h:19:10: fatal error: mpi.h: No such file or directory
   19 | #include <mpi.h>
      |          ^~~~~~~
compilation terminated.

Same as ENABLE_PEXSI, as PEXSI requires MPI and therefore no reason to build ABACUS with PEXSI but without MPI.

Also, require out-of-source CMake build as in-source is dangerous and might affect the real source code in the build process.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[AsTonyshment]

Thanks for introducing cmake_dependent_option; it makes the option dependencies much clearer. One concern is that an explicitly requested feature may now be silently disabled. For example:

-DENABLE_NCCL_PARALLEL_DEVICE=ON -DENABLE_MPI=OFF

CMake will force ENABLE_NCCL_PARALLEL_DEVICE to OFF but still configure successfully. Users may therefore assume NCCL support was enabled unless they carefully inspect the build summary.

I noticed that you have already raised this upstream:

CMakeDependentOption: Add warning when overriding value #27960

Since generic warnings inside cmake_dependent_option may be noisy, could ABACUS add targeted warnings for hard requirements such as NCCL, CUDA-aware MPI, LibRI, and PEXSI? For example:

ENABLE_NCCL_PARALLEL_DEVICE was requested, but USE_CUDA and ENABLE_MPI are not enabled. Disabling it.

This would preserve the cleaner dependency logic while making overridden user requests visible.

[AsTonyshment]

Although this naming predates this PR, could we use the official capitalization consistently here: cusolvermp -> cuSOLVERMp and cublasmp -> cuBLASMp?

[Growl1234]

... could ABACUS add targeted warnings for hard requirements such as NCCL, CUDA-aware MPI, LibRI, and PEXSI?

Honestly I didn't find a proper way to do it without introducing another weird and redundant helper (no reason to increase the complication just for options clarification). Introducing a modified CMakeDependentOption.cmake might be another solution, but I am not sure whether just copying from CMake and modifying it "locally" is really appropriate. Currently I add a global warning at the top, which might be revised or removed in the future.

Regarding the CMake issue, the upstream discussion is still ongoing and has not yet reached a conclusion. Therefore, further messages from the upstream developers can still be expected. That said, users and downstream should definitely be clear what they are doing anyways, whether the warning is added or not...