[bug] [fftw] Precision options are not mutually exclusive

The FFTW library can be configured to support FFTs with single, double, or long double precision, generating a separate library object for each precision. Applications that wish to support FFTs with multiple floating-point precisions must link to multiple FFTW libraries.

The current fftw/3.3.8 recipe allows specifying precision as an option but doesn’t supply an option to choose multiple precisions.

In my conanfile.txt file, I want to require fftw and specify multiple values for the precision option, e.g.:

[requires]
fftw/3.3.8

[generators]
cmake

[options]
fftw:precision=float,double

Is this possible? If so, would it generate a single cmake target with both libraries or two different cmake targets? If not, is there some other way to achieve this with conan?

[jgsogo]

I’m not aware of other recipes with the same casuistics, but I think it is perfectly ok to run the build three times and package all the libraries. Something like:

class Recipe(ConanFile):
    def build(self):
        if self.options.precission_double:
            with tools.chdir("build-precission-double"):
                cmake = CMake(self)
                cmake.definitions["PRECISSION_DOUBLE"]  = True
                cmake.configure()
                cmake.build()

        if self.options.precission_float:
            ...

    def package(self):
        self.copy("fftw-double.dll", src=".../build-precission-double", dst="bin")
        ...
        self.copy("fftw-float.dll", src=".../build-precission-float", dst="bin")
        ...

    def package_info(self):
        self.components["fftw-double"].libs = [...]
        ...
        self.components["fftw-float"].libs = [...]
        ...

Maybe @uilianries or @SSE4 , more experienced with recipes, have some other suggestion.

[jgsogo]

Two comments are very interesting here:

link with both binaries (impossible to do it statically due to the ODR violations), probably adding runtime dispatch to load the right binary

When those libraries are mutually exclusive, the global target Conan generates is no longer valid. This is a supporting argument for @fulara 's proposal here: https://github.com/conan-io/conan/issues/7475

okay, this will work in case of two options, but in generic way… probably requires some dedicated development effort in conan client. what if we have an option with value ANY? what if we have bit_depth: range(0…1000)? doesn’t scale well enough.

IMO, this is not a scenario strong enough to justify such development in Conan (it introduces a new paradigm), I want to think that methods can be easily parametrized in the recipe:

def _build(self, precission):
    if get(self.options, "precission_" + precission):
        with tools.chdir("build-precission-" + precission):
            cmake = CMake(self)
            cmake.definitions["PRECISSION_" + precission.upper()]  = True
            cmake.configure()
            cmake.build()

def build(self):
    self._build("double")
    self._build("float")