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.)

For the record, I have been working on a Meson build system for a while now that will eventually have feature parity with the Autotools build system, including the maintainer tools and tarball packaging.

This should provide good integration with IDEs and a more modern experience than Autotools would. It has far fewer problems and pitfalls than CMake as well, especially for cross-platform software, for inclusion as subproject in other software, and for distro packagers.

Currently, my intention is to just have it coexist with Autotools and not touch any existing files (apart from the commit that drops CMake as part of my personal crusade against it), maintaining the same directory structure for everything and mostly replicating its behavior. That makes it a lot messier (especially in terms of code duplication, as Meson deliberately avoids Turing completeness) and a bit slower than if I followed Meson’s intentions instead, but that’s a price I’m willing to pay. Any project-wide improvements will have to wait until this has left the experimental phase.

I’m also avoiding helper scripts written in Python for the sake of compatibility, and I test everything I do against Muon (large subset of Meson’s functionality but written in portable C).

If you’re curious, here’s a preview (still incomplete): https://github.com/mia-0/fftw3/tree/meson

Be warned though, I force-push that branch a bunch. It is not thoroughly tested, there are cases where it still falls apart, and it needs cleanup work. In particular, I have not yet tested it with Visual Studio on Windows or Xcode on macOS, or much of anything really, and I do expect it will need a few adjustments to make things work smoothly. But it will get there.

Maintainer documentation is also still missing, but I will put effort into that before submitting any pull request.

It’s actually been a pretty interesting project so far, and Meson is a joy to work with compared to other build systems I’ve used in the past. I think this might be the one that finally gets things right most of the time.

FYI, Meson can also work with CMake to some extent, if desired: It can generate CMake package files and it can use CMake to discover build dependencies. So projects that use CMake and depend on FFTW won’t have the rug pulled out from under them if this gets merged.