Clarify current/future cmake support

[LecrisUT]

The wording in the readme is rather contradictory with how the current status of the project is. I.e.:

• You can build the project from cmake, and it is suggested in order to get native support
  • If there are missing implementations specific to autotools, please enumerate them so that we can work on porting them
• Packagers should migrate to cmake build in order to support find_pacakge() The file FFTW3LibraryDepends.cmake is missing #130
• What is the future of cmake support, and the view of migrating to it completely

[matteo-frigo]

Here is my view on this issue.

autotools is and will remain the primary mechanism for compiling FFTW on any system that has a unix-like shell. It is the only mechanism that we personally use.

cmake support was contributed by other people, to whom we are thankful. We incorporated it because it simplifies building FFTW on Windows, which has historically been a problem for decades. We (as authors of Free Software) have no appetite whatsoever to touch Windows, and keeping the cmake support around is extra work for us. Nevertheless, not adding cmake support makes the life of other people harder at no benefit to us, so we added cmake support.

Building FFTW is complicated because a substantial majority of the C code that comprises FFTW is automatically generated, and code generation used to take a long time. Many years ago (before github was invented) we settled on a distribution model where the code-generation stage is performed by us once and for all, and the final user only needs a C compiler and a unix shell to compile FFTW. In this model, the primary distribution mechanism is a tarball downloaded from fftw.org, and github is a secondary distribution mechanism not really meant to be used by civilians.

The code generation machinery is currently only supported by autotools. Migrating this machinery to cmake would not solve any problem that we currently have, and thus I am disinclined to do any work on this front.

[LecrisUT]

I would say that one disadvantage of not migrating to more standard toolchains is the gatekeeping of new colaborators and the lack of IDE support. For example, easy CI support and maintenance.

Doing a preliminary scan of the code that is generated, there doesn't seem to be anything majorly complicated that cannot be done with macros (but honestly C++ templates would be significantly simpler, and migrating would not be difficult using a simple regex substitution). The code generation seems to be just calling some perl scripts, which can be done straightforwardly in cmake. If there are more complicated generations, please elaborate more on how the code-generation works.

[stevengj]

Doing a preliminary scan of the code that is generated, there doesn't seem to be anything majorly complicated that cannot be done with macros (but honestly C++ templates would be significantly simpler, and migrating would not be difficult using a simple regex substitution).

Um.... see the paper A Fast Fourier Transform Compiler.

C++ templates are turing complete, and so in principle could do anything, but it is unlikely to be "simpler" to do algebraic pattern matching and simplification in templates than using a language (OCaml) designed for those tasks. In any case, this isn't going to happen.

Definitely the code-generation programs could be invoked from cmake, but as Matteo wrote above this doesn't really interest us for any practical reason at the moment.

[LecrisUT]

Let me know if I understand this correctly:

• The main code generation that you are referring to is that in genfft and that is generated via OCaml. That is the main source of speed-ups of FFTW? I'm not familiar with OCaml, but does it create C source files or libraries that are linked to the C api? There does seem to be straightfoward ways of integrating with cmkae
• Otherwise there are no other custom hacks to the C source files that, and instead everything is handled via macros and passing defintions

The place where I was thinking would be a good idea to port to C++ is in substituting the macros, e.g. the X macro. The user would not need to care about what FFTW precision they need natively, and instead have the C++ template call the appropriate function. Am I missing something about OCaml - C/C++ interface?

The lack of native cmake integration is unfortunate because for users it would greatly simplify their implementation:

• More easily turn on features. E.g. in Better C++ support (#254) #255, there is a new flag that could be defined, which can easily be turned on/off by linking to an appropriate interface target
• All precisions are included in one file as per CMake: Adding support for building multiple precisions at once #276. Similarly it would be much easier to select between different variants like with or without openmp
• Better IDE support

[matteo-frigo]

I have no interest in continuing this conversation. The last one leaving please close the ticket.

[stevengj]

@LecrisUT, the API of FFTW needs to be based on C, not C++, even though it should be callable from C++. This is partly for technical reasons — it is vastly easier to call C libraries from other languages than it is to call C++ libraries.

(Various authors have layered more "native-feeling" C++ interfaces on top of FFTW and they are welcome to do so, along with the interfaces to FFTW from Python, Julia, R, Rust, etcetera.)