conan-io / cmake-conan

CMake wrapper for conan C and C++ package manager

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

conan_cmake_configure ignores `OPTIONS` arguments

RomanArzumanyan opened this issue · comments

Hello world,

I've built ffmpeg conan package with following options and uploaded it to internal conan artifactory:

conan create .\
  --user ci_cd \
  --channel release \
  -r internal_artifactory \ 
  -b missing \
  -s os=Windows \
  -s arch=x86_64 \
  -s compiler=msvc \
  -s compiler.version=191 \
  -s compiler.cppstd=14 \
  -s compiler.runtime=dynamic \
  -s compiler.runtime_type=Release \
  -s build_type=Release \
  -o disable_all_hardware_accelerators=True \
  -o with_nvdec=False \
  -o with_nvenc=False \
  -o with_cuvid=False \
  -o with_libnpp=False \
  -o with_cuda_nvcc=False

I can see the package with conan-list and it's also found by conan in requirements:

Requirements
    ffmpeg/master_tot@ci_cd/release#792d2a218187408c41db2d7809d884c5 - Downloaded (internal_artifactory )

Then I build my app which is to be linked against FFmpeg libraries.
For that purpose in my CMakeLists.txt file, conan_cmake_configure is invoked with same conan options:

conan_cmake_configure(
  REQUIRES ffmpeg/master_tot@ci_cd/release
  GENERATORS CMakeDeps
  OPTIONS ffmpeg/master_tot:disable_all_hardware_accelerators=True
  OPTIONS ffmpeg/master_tot:with_nvdec=False
  OPTIONS ffmpeg/master_tot:with_nvenc=False
  OPTIONS ffmpeg/master_tot:with_cuvid=False
  OPTIONS ffmpeg/master_tot:with_libnpp=False
  OPTIONS ffmpeg/master_tot:with_cuda_nvcc=False)

But for some reason options are ignored and default options from conanfile.py are used by conan instead:

ERROR: Missing binary: ffmpeg/master_tot@ci_cd/release:3f4e85d017a776311deac90cf464502f82e9994e
ffmpeg/master_tot@ci_cd/release: WARN: Can't find a 'ffmpeg/master_tot@ci_cd/release' package binary '3f4e85d017a776311deac90cf464502f82e9994e' for the configuration:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=191
os=Windows
[options]
...
disable_all_hardware_accelerators=False
...
with_cuda_nvcc=True
with_cuvid=True
...
with_libnpp=True
...
with_nvdec=True
with_nvenc=True
...

Could anyone give me a hand please?

Hi @RomanArzumanyan

I think the issue is that they are not additive. You should either use a conanfile file or define it on the fly via conan_cmake_configure(), but it is not that the options defined in conan_cmake_configure() override or compose with the conanfile ones.

Hi @memsharded
Thank you for the swift response!

I don't have conanfile in my application, it's conan_cmake_configure which generates conanfile.txt in build directory.

Alright, here's the workaround. Hope it helps.

Use conanfile.py in application which depends on ffmpeg package:

from conan import ConanFile

class FfmpegRecipe(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeDeps"

    def requirements(self):
        pkg_name = "ffmpeg/master_tot@ci_cd/" + str(self.settings.build_type).lower()
        self.requires(pkg_name)

    def configure(self):
        if self.settings.os == "Windows":
            self.options["ffmpeg/*"].with_nvdec = False
            self.options["ffmpeg/*"].with_nvenc = False
            self.options["ffmpeg/*"].with_cuvid = False
            self.options["ffmpeg/*"].with_libnpp = False
            self.options["ffmpeg/*"].with_cuda_nvcc = False
            self.options["ffmpeg/*"].disable_all_hardware_accelerators = True

Then install from CLI:

conan install . \
  --update \
  -of $(pwd) \
  -s os=Windows \
  -s compiler=msvc \
  -s build_type=Release \
  -s arch=x86_64

I don't have conanfile in my application, it's conan_cmake_configure which generates conanfile.txt in build directory.

Oh, sorry about that, I thought that you were using one.

Thanks for sharing your workaround and closing the issue.
As this cmake-conan integration is legacy anyway, and it is being deprecated and superseded by the new Conan 2.0 cmake-conan new transparent integration based on the new CMake dependency providers, it is not worth investigating further. Thanks again!