Description
Now that 1.6 is released, I would like to eliminate the Pkg.build() step within FFTW entirely, instead changing it to use Preferences to manage which backend its using. I'd also like to explore ways that it can make optional use of MKL and not unconditionally install it as a dependency.
My proposed plan is to use Preferences to perform a lookup (at compile time) for the provider key and use that, instead of looking at the value of libfftw3. So e.g. this line would instead become something like:
const fftw_vendor = @load_preference("provider")
The @load_preference macro will record in the .ji file that it accessed the provider key at compile-time, and so Julia, when loading the .ji file, will check to see if the current provider key matches the one recorded in the .ji file and if they do not match, it will reject the .ji file and possibly recompile FFTW. This allows for FFTW to use MKL in some projects, and to use FFTW_jll in others.
More importantly for me, it removes the need to write out state into the depot and eliminates the Pkg.build() step, which should help in some of our caching efforts in large-scale deployments (where we want to make the depot read-only, we want to transfer around only content-addressed chunks of data from machine to machine, etc... and FFTW needing to rebuild itself because of the prefs/FFTW file causes a cascade of recompilation).
This capability is, of course, 1.6+. @stevengj how do you feel about branching and creating a 1.6+ release?