Bug: CMake configure fails when CUDA tests are enabled without `ENABLE_FLOAT_FFTW`

[AsTonyshment]

Summary

After updating to commit 59dc88428 (Add FindKML.cmake and resolve FFTW3 issue, #7576), CMake configuration fails when CUDA unit tests are enabled while ENABLE_FLOAT_FFTW is left at its default value OFF.

The failure happens because pw_test_gpu unconditionally links against FFTW3::FFTW3_FLOAT, while cmake/FindFFTW3.cmake now only defines that imported target when ENABLE_FLOAT_FFTW=ON.

Environment

• Commit: 59dc88428
• Branch: develop
• Compiler: GNU 12.4.0
• CMake: 3.28
• CUDA: 12.1

Trigger Conditions

The issue is triggered with the following configuration:

• USE_CUDA=ON
• BUILD_TESTING=ON
• ENABLE_FLOAT_FFTW=OFF or not specified, since it defaults to OFF
• FFTW is found through cmake/FindFFTW3.cmake

Actual Behavior

CMake configure/generate fails with:

CMake Error at cmake/Testing.cmake:42 (target_link_libraries):
  Target "pw_test_gpu" links to:

    FFTW3::FFTW3_FLOAT

  but the target was not found.
Call Stack (most recent call first):
  source/source_basis/module_pw/test_gpu/CMakeLists.txt:3 (AddTest)

Analysis

ENABLE_FLOAT_FFTW defaults to OFF in the top-level CMakeLists.txt.

After #7576, cmake/FindFFTW3.cmake only searches for fftw3f and creates FFTW3::FFTW3_FLOAT when ENABLE_FLOAT_FFTW=ON.

However, source/source_basis/module_pw/test_gpu/CMakeLists.txt still registers pw_test_gpu whenever USE_CUDA=ON, and links it unconditionally against FFTW3::FFTW3_FLOAT:

if (USE_CUDA)
AddTest(
  TARGET pw_test_gpu
  LIBS parameter ${math_libs} base planewave device FFTW3::FFTW3_FLOAT
  SOURCES pw_test.cpp  pw_basis_C2R.cpp pw_basis_C2C.cpp  pw_basis_k_C2C.cpp
)
endif()

The test sources also instantiate float GPU test cases and call fftwf_* APIs, for example fftwf_plan_dft_3d, so the test itself appears to require single-precision FFTW.

Expected Behavior

One of the following should happen:

1. pw_test_gpu should only be enabled when ENABLE_FLOAT_FFTW=ON, or
2. the float-specific parts of pw_test_gpu should be guarded by ENABLE_FLOAT_FFTW, or
3. ENABLE_FLOAT_FFTW=ON should remain available as long as BUILD_TESTING=ON.

The default configuration with USE_CUDA=ON and BUILD_TESTING=ON should not fail during CMake generation.

[Growl1234]

It seems the blame on the .../test/CMakeLists.txt side: these case were not well encapsulated at all.

[Growl1234]

I found the issue. It's due to the fix towards #7567. But why this test will parse the bare FFTW3::FFTW3_FLOAT target?? @mohanchen do you have idea on this?

[AsTonyshment]

Hi @Growl1234, I scanned the current test CMake files for direct imported-target references.

Confirmed issue:

1. source/source_basis/module_pw/test_gpu/CMakeLists.txt

   This is still guarded only by if(USE_CUDA), but links FFTW3::FFTW3_FLOAT directly:

   if (USE_CUDA)
   AddTest(
     TARGET pw_test_gpu
     LIBS parameter base planewave device FFTW3::FFTW3_FLOAT
     SOURCES pw_test.cpp  pw_basis_C2R.cpp pw_basis_C2C.cpp  pw_basis_k_C2C.cpp
   )
   endif()

Potential similar provider mismatch:

2. source/source_base/test_parallel/CMakeLists.txt

   The BLACS test chooses the provider like this:

   if(MKLROOT)
     list(APPEND BLACS_LIB MKL::MKL)
   else()
     set(BLACS_LIB ScaLAPACK::ScaLAPACK)
   endif()

   This is probably fine for the normal non-MKL ScaLAPACK path, where find_package(ScaLAPACK REQUIRED) creates ScaLAPACK::ScaLAPACK.

   However, after Add FindKML.cmake and resolve FFTW3 issue #7576 / CMake: Centralize target linkage in source/CMakeLists.txt #7584 there is also a KML provider path. With USE_KML=ON and ENABLE_MPI=ON, the dependency target appears to be KML::ScaLAPACK, not ScaLAPACK::ScaLAPACK. So this test may still assume the wrong provider-specific imported target under a KML build.

   I would suggest checking this one with if(TARGET KML::ScaLAPACK), if(TARGET MKL::MKL), and if(TARGET ScaLAPACK::ScaLAPACK), or reusing the centralized linear-algebra interface from CMake: Centralize target linkage in source/CMakeLists.txt #7584 if that is intended to cover tests too.

Other direct imported targets I checked:

• source/source_hsolver/test/CMakeLists.txt

  • Uses ELPA::ELPA.
  • CMake: Centralize target linkage in source/CMakeLists.txt #7584 already changes the relevant USE_ELPA checks to if(TARGET ELPA::ELPA), which looks aligned with the cleanup direction.

• source/source_hamilt/module_xc/test/CMakeLists.txt

  • Uses Libxc::xc.
  • The parent source/source_hamilt/module_xc/CMakeLists.txt only adds this test directory under ENABLE_LIBXC, and the top-level configuration uses find_package(Libxc CONFIG REQUIRED) in that mode. I did not find the same missing-target pattern here.

• source/source_hamilt/module_vdw/test/CMakeLists.txt

  • Links dftd4::dftd4 only inside if(ENABLE_DFTD4).
  • The top-level configuration calls find_package(dftd4 4.2.0 REQUIRED) under the same option. This also does not look like the same issue, although changing it to if(TARGET dftd4::dftd4) would be consistent with the target-based cleanup.

• MPI::MPI_CXX usages in test directories

  • The scanned test directories using this target are registered under ENABLE_MPI parents, or under the global MPI-required path. I did not find a missing-target case analogous to FFTW3::FFTW3_FLOAT.

• Threads::Threads, GTest::gtest_main, and GTest::gmock_main

  • These are provided by the test setup before unit-test subdirectories are added, so I did not flag them as optional-provider issues.

So the short list I found is:

1. Definite: pw_test_gpu should not directly require FFTW3::FFTW3_FLOAT unless that target exists.
2. Worth checking: MODULE_BASE_blacs_connector should not hard-code only MKL::MKL vs ScaLAPACK::ScaLAPACK if KML::ScaLAPACK is now a valid provider.