The file FFTW3LibraryDepends.cmake is missing

[jlelong]

The file FFTW3Config.cmake tries to include the file FFTW3LibraryDepends.cmake, which is apparently missing in release 3.3.7.

[matteo-frigo]

@xantares You contributed this functionality, do you know what's wrong?

[jschueller]

This file should be created by cmake:
https://github.com/FFTW/fftw3/blob/master/CMakeLists.txt#L358

If the lib was packaged using autotools it may be absent.

[jlelong]

However as the documentation says to use configure rather than cmake, the file FFTW3LibraryDepends.cmake may be missing on most installations.
Is there any plan to make CMake the default compilation toolchain? Anyway, it would be worth supporting fftw detection through Cmake's find_package.

[alalazo]

+1 to the number of people hit by this.

[tcanabrava]

still happening on many packages.

[peanutfun]

After installing FFTW v3.3.8 with homebrew, the CMake instruction find_package(FFTW) fails because the installed FFTWConfig.cmake file refers to a file FFTW3LibraryDepends.cmake which is not there. This is tiresome because it requires projects which depend on FFTW to supply their own CMake configuration and imported targets, to properly link to FFTW.

[phcerdan]

One solution would be to trust the user and provide a step by step docs on how to build fftw3 with CMake, so FFTW3LibraryDepends.cmake can be generated.

Or even better, create a complete CMakeLists.txt including all the dependencies for generating the code.
Current CMakeLists.txt should fail at configure time, not at build time with missing references. This would be ideal, so developers could (in whatever OS):

git clone https://github.com/FFTW/fftw3
cmake -GNinja -DENABLE_XXX ...
ninja

As most of c/c++ projects do nowadays.

[pisto]

+1

[stevengj]

As I understand it, the issue here is that the cmake build installs this file okay, but if users do ./configure && make && make install using the autotools build, as is likely on Unix systems, then they don't get this file because it is generated only within the cmake build?

If so, I see three solutions:

1. No longer install FFTWConfig.cmake at all in the autotools build, since it is broken without the FFTW3LibraryDepends.cmake file.

2. Eliminate the autotools build option completely so that everyone is forced to use cmake. Currently this is impossible because the bootstrap build (codelet generation) requires autotools.

3. Get the autotools build to generate FFTW3LibraryDepends.cmake, ideally without invoking cmake. How complicated is this file to generate manually?

[stevengj]

For reference, the FFTW3LibraryDepends.cmake file on my machine is:

# Generated by CMake

if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.5)
   message(FATAL_ERROR "CMake >= 2.6.0 required")
endif()
cmake_policy(PUSH)
cmake_policy(VERSION 2.6)
#----------------------------------------------------------------
# Generated CMake target import file.
#----------------------------------------------------------------

# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)

# Protect against multiple inclusion, which would fail when already imported targets are added once more.
set(_targetsDefined)
set(_targetsNotDefined)
set(_expectedTargets)
foreach(_expectedTarget FFTW3::fftw3)
  list(APPEND _expectedTargets ${_expectedTarget})
  if(NOT TARGET ${_expectedTarget})
    list(APPEND _targetsNotDefined ${_expectedTarget})
  endif()
  if(TARGET ${_expectedTarget})
    list(APPEND _targetsDefined ${_expectedTarget})
  endif()
endforeach()
if("${_targetsDefined}" STREQUAL "${_expectedTargets}")
  unset(_targetsDefined)
  unset(_targetsNotDefined)
  unset(_expectedTargets)
  set(CMAKE_IMPORT_FILE_VERSION)
  cmake_policy(POP)
  return()
endif()
if(NOT "${_targetsDefined}" STREQUAL "")
  message(FATAL_ERROR "Some (but not all) targets in this export set were already defined.\nTargets Defined: ${_targetsDefined}\nTargets not yet defined: ${_targetsNotDefined}\n")
endif()
unset(_targetsDefined)
unset(_targetsNotDefined)
unset(_expectedTargets)


# Create imported target FFTW3::fftw3
add_library(FFTW3::fftw3 SHARED IMPORTED)

set_target_properties(FFTW3::fftw3 PROPERTIES
  INTERFACE_LINK_LIBRARIES "m"
)

# Import target "FFTW3::fftw3" for configuration "Release"
set_property(TARGET FFTW3::fftw3 APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(FFTW3::fftw3 PROPERTIES
  IMPORTED_LOCATION_RELEASE "/Users/stevenj/Code/fftw3/build/libfftw3.3.dylib"
  IMPORTED_SONAME_RELEASE "@rpath/libfftw3.3.5.7.dylib"
  )

# This file does not depend on other imported targets which have
# been exported from the same project but in a separate export set.

# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)
cmake_policy(POP)

Seems like we could easily generate this: just substitute the correct path into IMPORTED_*_RELEASE ourselves by using the above file as a .in template for the `configure script.

[alalazo]

Seems like we could easily generate this: just substitute the correct path into IMPORTED_*_RELEASE ourselves by using the above file as a .in template for the `configure script.

I see that the file contains:

# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)

Is the format version documented somewhere, or does it need to be reverse engineered? The latter case might require some efforts to follow up on changes needed to accommodate operating systems, build types, etc. that we didn't account for in the first implementation.

[stevengj]

Is the format version documented somewhere

No, but it is hard-coded to 1 in cmake and has been ever since this feature was implemented 11 years ago (Kitware/CMake@5594ad4), so I'm not too worried.

changes needed to accommodate operating systems, build types, etc.

This would only be used for autoconf builds on Unix systems. But in any case if you look at the cmake source code it looks like there is not much platform variation in how this file is generated — mostly it is boilerplate. (The only platform dependency I can see is for certain kinds of builds on MacOS that don't apply to us.)

[Be-ing]

Eliminate the autotools build option completely so that everyone is forced to use cmake. Currently this is impossible because the bootstrap build (codelet generation) requires autotools.

I suggest this. Maintaining build systems that CMake can generate automatically is counterproductive.

[lyogavin]

I run into this too. This could be fixed by build with cmake and copy FFTW3LibraryDepends.cmake manually on my environment:

mkdir build & cd build
cmake ..
make -j 4
make install
sudo cp FFTW3LibraryDepends.cmake /usr/local/lib/cmake/fftw3/

[ferdnyc]

The autotools build also installs the files in <libdir>/cmake/fftw3/ no matter which version of the library is built, whereas the CMake builds will install each FFTW3(|f|l|q)Config.cmake into <libdir>/cmake/fftw3(|f|l|q)/.

That becomes relevant because it interferes with autodiscovery when using find_package(). You're meant to do (for example) find_package(FFTW3f), if you want the single-precision floating point version of the library. find_package(FFTW3f) isn't going to look in <CMAKE_PREFIX_PATH>/<libdirs>/cmake/fftw3/ — it will look in <CMAKE_PREFIX_PATH>/<libdirs>/cmake/fftw3f/, though. So even if the configuration files were correctly generated, the location they're installed into isn't correct except for the un-precision-suffixed library version.

Granted, even on the CMake side it might be better to support multiple library builds in a single run, with different precision options. (As opposed to currently, where you have to build each in a separate build tree or the configs will trample all over each other setting up the one ${fftw3_lib} target for the chosen precision.) Then, the build could create and export a single package FFTW3, with the various library versions configured as COMPONENTS of the package.

Set up that way, another project could use e.g. find_package(FFTW3 COMPONENTS single) to specifically require the target for FFTW3::single (or FFTW3::fftw3f, like today, if people are really attached to the ugly filenaming), vs. using find_package(FFTW3 COMPONENTS quad threads) to get a target for FFTW3::fftw3q_threads. (None of the _threads, _omp, etc. subtargets appear anywhere in either the CMake or pkgconfig metadata, today.)

As a single package, the CMake configuration(s) could all live in the same directory, named for the package, and at least some of the common configuration would be shared between the components.

But I agree the CMake configs as generated by the autotools build aren't useful today. It shouldn't even be trying to install them (broken, and in the wrong place), unless it's going to use CMake to ensure that they'll be proper, valid configs.

Looking at the history of Makefile.am, until 2017 FFTW was distributed with a Find module, FindFFTW3<suffix>.cmake — it was fairly simple for autotools to naively generate that. (And to install it, since all Find modules go in /usr/share/cmake/Modules/ or equivalent.) But when the CMake build moved to an EXPORTED configuration, things got a lot more complex CMake-internally, to the point where it's not so easy for autotools to just fake it (... correctly).

[milahu]

when i build fftw with cmake,
it produces the wrong package version in cmake files

expected: 3.3.10 (gnumake build)
actual: 3.3.9 (cmake build)

source: https://fftw.org/fftw-3.3.10.tar.gz

configure

PACKAGE_VERSION='3.3.10'

CMakeLists.txt

set (FFTW_VERSION 3.3.9)

ideally the version is single-sourced, for example from the file VERSION

diff of cmake files: gnumake-build vs cmake-build

diff -r -u /nix/store/xggal21xgmk747gwhzbkrg8ddgyqwkcd-fftw-double-3.3.10-dev/lib/cmake/fftw3/FFTW3Config.cmake /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/lib/cmake/fftw3/FFTW3Config.cmake
--- /nix/store/xggal21xgmk747gwhzbkrg8ddgyqwkcd-fftw-double-3.3.10-dev/lib/cmake/fftw3/FFTW3Config.cmake	1969-12-31 16:00:01.000000000 -0800
+++ /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/lib/cmake/fftw3/FFTW3Config.cmake	1969-12-31 16:00:01.000000000 -0800
@@ -7,8 +7,8 @@
 set (FFTW3_CONFIG_FILE "${CMAKE_CURRENT_LIST_FILE}")
 
 set (FFTW3_LIBRARIES fftw3)
-set (FFTW3_LIBRARY_DIRS /nix/store/dyizjvy16q1j7q79z59xb2a1dx7vd317-fftw-double-3.3.10/lib)
-set (FFTW3_INCLUDE_DIRS /nix/store/xggal21xgmk747gwhzbkrg8ddgyqwkcd-fftw-double-3.3.10-dev/include)
+set (FFTW3_LIBRARY_DIRS /nix/store/vw2gnkz6ksbcpbn8j9z01wlc4f3qf35q-fftw-double-3.3.10/lib)
+set (FFTW3_INCLUDE_DIRS /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/include)
 
 include ("${CMAKE_CURRENT_LIST_DIR}/FFTW3LibraryDepends.cmake")
 
diff -r -u /nix/store/xggal21xgmk747gwhzbkrg8ddgyqwkcd-fftw-double-3.3.10-dev/lib/cmake/fftw3/FFTW3ConfigVersion.cmake /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/lib/cmake/fftw3/FFTW3ConfigVersion.cmake
--- /nix/store/xggal21xgmk747gwhzbkrg8ddgyqwkcd-fftw-double-3.3.10-dev/lib/cmake/fftw3/FFTW3ConfigVersion.cmake	1969-12-31 16:00:01.000000000 -0800
+++ /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/lib/cmake/fftw3/FFTW3ConfigVersion.cmake	1969-12-31 16:00:01.000000000 -0800
@@ -1,5 +1,5 @@
 
-set (PACKAGE_VERSION "3.3.10")
+set (PACKAGE_VERSION "3.3.9")
 
 # Check whether the requested PACKAGE_FIND_VERSION is compatible
 if ("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}")
Only in /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/lib/cmake/fftw3: FFTW3LibraryDepends.cmake
Only in /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/lib/cmake/fftw3: FFTW3LibraryDepends-release.cmake
diff -r -u /nix/store/xggal21xgmk747gwhzbkrg8ddgyqwkcd-fftw-double-3.3.10-dev/lib/pkgconfig/fftw3.pc /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/lib/pkgconfig/fftw3.pc
--- /nix/store/xggal21xgmk747gwhzbkrg8ddgyqwkcd-fftw-double-3.3.10-dev/lib/pkgconfig/fftw3.pc	1969-12-31 16:00:01.000000000 -0800
+++ /nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/lib/pkgconfig/fftw3.pc	1969-12-31 16:00:01.000000000 -0800
@@ -1,11 +1,11 @@
-prefix=/nix/store/dyizjvy16q1j7q79z59xb2a1dx7vd317-fftw-double-3.3.10
-exec_prefix=${prefix}
-libdir=/nix/store/dyizjvy16q1j7q79z59xb2a1dx7vd317-fftw-double-3.3.10/lib
-includedir=/nix/store/xggal21xgmk747gwhzbkrg8ddgyqwkcd-fftw-double-3.3.10-dev/include
+prefix=/nix/store/vw2gnkz6ksbcpbn8j9z01wlc4f3qf35q-fftw-double-3.3.10
+exec_prefix=/nix/store/vw2gnkz6ksbcpbn8j9z01wlc4f3qf35q-fftw-double-3.3.10
+libdir=/nix/store/vw2gnkz6ksbcpbn8j9z01wlc4f3qf35q-fftw-double-3.3.10/lib
+includedir=/nix/store/992cz8d5hh0s265h7swj0943b0xrkhls-fftw-double-3.3.10-dev/include
 
 Name: FFTW
 Description: fast Fourier transform library
-Version: 3.3.10
+Version: 3.3.9
 Libs: -L${libdir} -lfftw3 
 Libs.private: -lm
 Cflags: -I${includedir}

[milahu]

example: migrate autotools-build to cmake-build

diff: fftw in nixpkgs

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/fftw/default.nix

diff --git a/pkgs/development/libraries/fftw/default.nix b/pkgs/development/libraries/fftw/default.nix
index e57cbc34fa2..a56a9b9eaf1 100644
--- a/pkgs/development/libraries/fftw/default.nix
+++ b/pkgs/development/libraries/fftw/default.nix
@@ -1,6 +1,7 @@
 { fetchurl
 , stdenv
 , lib
+, cmake
 , gfortran
 , perl
 , llvmPackages
@@ -11,7 +12,7 @@
 , enableFma ? stdenv.hostPlatform.fmaSupport
 , enableMpi ? false
 , mpi
-, withDoc ? stdenv.cc.isGNU
+, enableFortran ? stdenv.cc.isGNU # generate Fortran wrapper with hardcoded gcc
 }:
 
 with lib;
@@ -30,33 +31,52 @@ stdenv.mkDerivation rec {
     sha256 = "sha256-VskyVJhSzdz6/as4ILAgDHdCZ1vpIXnlnmIVs0DiZGc=";
   };
 
-  outputs = [ "out" "dev" "man" ]
-    ++ optional withDoc "info"; # it's dev-doc only
-  outputBin = "dev"; # fftw-wisdom
+  # fix package version in cmake files
+  # https://github.com/FFTW/fftw3/issues/130#issuecomment-1409884653
+  postPatch = ''
+    substituteInPlace CMakeLists.txt \
+      --replace "set (FFTW_VERSION 3.3.9)" "set (FFTW_VERSION 3.3.10)"
+  '';
 
-  nativeBuildInputs = [ gfortran ];
+  outputs = [ "out" "dev" ];
+  #outputBin = "dev"; # fftw-wisdom # not in cmake
+
+  nativeBuildInputs = [
+    gfortran
+    cmake
+  ];
 
   buildInputs = optionals stdenv.cc.isClang [
     # TODO: This may mismatch the LLVM version sin the stdenv, see #79818.
     llvmPackages.openmp
   ] ++ optional enableMpi mpi;
 
-  configureFlags =
-    [ "--enable-shared"
-      "--enable-threads"
+  cmakeFlags =
+    let
+      # all x86_64 have sse2
+      # however, not all float sizes fit
+      enableSse2 = (stdenv.isx86_64 && (precision == "single" || precision == "double"));
+      enableSse = enableSse2;
+    in
+    [
+      "-DBUILD_SHARED_LIBS=ON"
+      #"-DBUILD_TESTS=ON" # default ON
+      "-DENABLE_OPENMP=ON" # Use OpenMP for multithreading
+      "-DENABLE_THREADS=ON" # Use pthread for multithreading
     ]
-    ++ optional (precision != "double") "--enable-${precision}"
-    # all x86_64 have sse2
-    # however, not all float sizes fit
-    ++ optional (stdenv.isx86_64 && (precision == "single" || precision == "double") )  "--enable-sse2"
-    ++ optional enableAvx "--enable-avx"
-    ++ optional enableAvx2 "--enable-avx2"
-    ++ optional enableAvx512 "--enable-avx512"
-    ++ optional enableFma "--enable-fma"
-    ++ [ "--enable-openmp" ]
-    ++ optional enableMpi "--enable-mpi"
-    # doc generation causes Fortran wrapper generation which hard-codes gcc
-    ++ optional (!withDoc) "--disable-doc";
+    # default precision is double
+    ++ optional (precision == "single") "-DENABLE_FLOAT=ON"
+    ++ optional (precision == "long-double") "-DENABLE_LONG_DOUBLE=ON"
+    ++ optional (precision == "quad-precision") "-DENABLE_QUAD_PRECISION=ON"
+    ++ optional enableSse "-DENABLE_SSE=ON"
+    ++ optional enableSse2 "-DENABLE_SSE2=ON"
+    ++ optional enableAvx "-DENABLE_AVX=ON"
+    ++ optional enableAvx2 "-DENABLE_AVX2=ON"
+    #++ optional enableAvx512 "-DENABLE_AVX512=ON" # missing in cmake
+    #++ optional enableFma "-DENABLE_FMA=ON" # missing in cmake
+    #++ optional enableMpi "-DENABLE_MPI=ON" # missing in cmake
+    ++ optional (!enableFortran) "-DDISABLE_FORTRAN=ON"
+  ;
 
   enableParallelBuilding = true;
 

not in cmake-build:

• fftw-wisdom
• ENABLE_AVX512
• ENABLE_FMA
• ENABLE_MPI

[SuHang980715]

I run into this too. This could be fixed by build with cmake and copy FFTW3LibraryDepends.cmake manually on my environment:

mkdir build & cd build cmake .. make -j 4 make install sudo cp FFTW3LibraryDepends.cmake /usr/local/lib/cmake/fftw3/

Could I ask about that, where did you download the file FFTW3LibraryDepends.cmake?

[sergiomb2]

@bergus solution is the best I think , I will apply

since migration to cmake still missing

fftw-wisdom
ENABLE_AVX512
ENABLE_FMA
ENABLE_MPI

and breaks autotools build , congratulations !

the fix is remove the false dependency that cmake generate .

diff --git a/FFTW3Config.cmake.in b/FFTW3Config.cmake.in
index 6b1fbc2..e8a2ed8 100644
--- a/FFTW3Config.cmake.in
+++ b/FFTW3Config.cmake.in
@@ -10,8 +10,6 @@ set (FFTW3@PREC_SUFFIX@_LIBRARIES fftw3@PREC_SUFFIX@)
 set (FFTW3@PREC_SUFFIX@_LIBRARY_DIRS @CMAKE_INSTALL_FULL_LIBDIR@)
 set (FFTW3@PREC_SUFFIX@_INCLUDE_DIRS @CMAKE_INSTALL_FULL_INCLUDEDIR@)

-include ("${CMAKE_CURRENT_LIST_DIR}/FFTW3LibraryDepends.cmake")
-
 if (CMAKE_VERSION VERSION_LESS 2.8.3)
   set (CMAKE_CURRENT_LIST_DIR)
 endif ()

[ferdnyc]

@sergiomb2

the fix is remove the false dependency that cmake generate .

diff --git a/FFTW3Config.cmake.in b/FFTW3Config.cmake.in
index 6b1fbc2..e8a2ed8 100644
--- a/FFTW3Config.cmake.in
+++ b/FFTW3Config.cmake.in
@@ -10,8 +10,6 @@ set (FFTW3@PREC_SUFFIX@_LIBRARIES fftw3@PREC_SUFFIX@)
 set (FFTW3@PREC_SUFFIX@_LIBRARY_DIRS @CMAKE_INSTALL_FULL_LIBDIR@)
 set (FFTW3@PREC_SUFFIX@_INCLUDE_DIRS @CMAKE_INSTALL_FULL_INCLUDEDIR@)

-include ("${CMAKE_CURRENT_LIST_DIR}/FFTW3LibraryDepends.cmake")
-
 if (CMAKE_VERSION VERSION_LESS 2.8.3)
   set (CMAKE_CURRENT_LIST_DIR)
 endif ()

I mean, personally I'd go with:

if (EXIST "${CMAKE_CURRENT_LIST_DIR}/FFTW3LibraryDepends.cmake")
  include ("${CMAKE_CURRENT_LIST_DIR}/FFTW3LibraryDepends.cmake")
endif ()

Which handles both the CMake and autotools cases, and could be committed to the repo as a fix.

[sergiomb2]

thanks @ferdnyc seems a good option , lets do one pull request ?