Overriding requirements and their default options

[Morwenn]

In a project of mine I am trying to use two libraries that require the same version of glib (probably not relevant here but the libraries are harfbuzz/2.4.0 and qt/5.13.0), but configured differently: one uses with_pcre=True and the other one with_pcre=False. This naturally leads to an issue, namely the following error message:

ERROR: glib/2.58.3@bincrafters/stable: Incompatible requirements obtained in different evaluations of 'requirements'
    Previous requirements: [zlib/1.2.11@conan/stable, libffi/3.2.1@bincrafters/stable, pcre/8.41@bincrafters/stable, libelf/0.8.13@bincrafters/stable, libmount/2.33.1@bincrafters/stable, libselinux/2.8@bincrafters/stable]
    New requirements: [zlib/1.2.11@conan/stable, libffi/3.2.1@bincrafters/stable, libelf/0.8.13@bincrafters/stable, libmount/2.33.1@bincrafters/stable, libselinux/2.8@bincrafters/stable]

Considering that they both needed different versions of glib, it's not surprising. To avoid that, I tried to explicitly override the glib dependency in my conanfile.py's requirements() function as follows:

self.requires("glib/2.58.3@bincrafters/stable", override=True)
self.options['glib'].with_pcre = True

Since one of the libraries requires a PCRE-augmented glib, I decided to force both to True, but the error message didn't disappear. It does disappear when I try to force self.options['glib'].with_pcre = False, but I am not sure that it is what I want since one of the libraries is fine with PCRE. I'm not sure.

The default value for with_pcre is True, so I guess that the override only works properly when we force it to a value different from the default one?

I'm not sure what is the most sensible thing to do in such a case, and it feels like a general Conan knowledge issue on my side more than a lib-specific issue, but if I'm wrong I will ask on bincrafters instead.

Any help in understanding why it behaves like it does and what is the most idiomatic way to fix this kind of issue is very welcome :)

---

To help us debug your issue please explain:

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant: Ubuntu 18, Conan 1.16.0, glib/2.58.3@bincrafters/stable, harfbuzz/2.4.0@bincrafters/stable and qt/5.13.0@bincrafters/stable
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[Minimonium]

Hi, Morwenn!
It seems like the issue is with the Qt's recipe forcing the option on its consumers. I'm pretty sure it shouldn't behave like this.
Qt's recipe forces the option (while the intent, I assume, is to provide a default value since Qt recipe doesn't necessary require it).
It works when you force the value to False because of this line:
https://github.com/bincrafters/conan-qt/blob/testing/5.13.0/conanfile.py#L215

/cc @ericLemanissier

[memsharded]

Indeed, doing something like:

self.options['glib'].with_pcre = True

In a recipe is the equivalent to hardcoding it. It cannot be undone or overwritten from downstream. Only default_options can be overriden. This is supposed to be used exclusively when a package will only work with that configuration, and fail otherwise. The package could even try to raise a ConanInvalidConfiguration if it found that an invalid option is going to be used. But as @Minimonium correctly suggest, it might be possible that it is not necessary that Qt package force this, in this case, I would try to collaborate with @ericLemanissier for this. A good start would be to fork their Qt recipe, remove that line, and see if it builds and you can use it the way you want in your project).

[ericLemanissier]

Qt recipe uses self.options['packageA'].option = whatever, because packageA is not always a dependency of qt (it can depend on the settings, or on qt's options). What happens on conan side if I did instead default_options = {...,"packageA:option": whatever} and not require packageA because it is not mandatory with the options/settings selected by the user?

[memsharded]

Hi @ericLemanissier

Default options value that do not apply are just discarded, so it is safe to say default_options = {...,"packageA:option": whatever} even if packageA is not a dependency.

[Morwenn]

It seems to work when I comment the line in the Qt recipe :)

In the grand scheme of things, does that mean that if two of my dependencies require the same dependency with incompatible options there's basically no way out?

[ericLemanissier]

@Morwenn On my side I could not compile the recipe successfully without self.options["glib"].with_pcre = False. Could you please send me the log of qt's build, especially the part between looking for library glib and test config.qtbase_corelib.libraries.glib ?

[Morwenn]

@ericLemanissier Sure, here is the log (I replaced references to my home directory by ~ everywhere, but in the actual log it's an absolute path):

looking for library glib
Trying source 0 (type pkgConfig) of library glib ...
+ /usr/bin/pkg-config --exists --silence-errors glib-2.0 gthread-2.0
+ /usr/bin/pkg-config --modversion glib-2.0 gthread-2.0
> 2.58.3
> 2.58.3
+ /usr/bin/pkg-config --libs-only-L glib-2.0 gthread-2.0
> -L~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/lib
+ /usr/bin/pkg-config --libs-only-l glib-2.0 gthread-2.0
> -lgthread-2.0 -lglib-2.0
+ /usr/bin/pkg-config --cflags glib-2.0 gthread-2.0
> -pthread -I~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/include -I~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/include/glib-2.0 -I~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/lib/glib-2.0/include
Note: Dropped compiler flags '-pthread'.
+ cd ~/.conan/data/qt/5.13.0/bincrafters/stable/build/7eadbcc1d81cf4cb6da18c3e0b9961f100ab38ba/config.tests/glib && ~/.conan/data/qt/5.13.0/bincrafters/stable/build/7eadbcc1d81cf4cb6da18c3e0b9961f100ab38ba/qtbase/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" 'QMAKE_USE += glib' 'QMAKE_LIBS_GLIB = ~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/lib/libgthread-2.0.so ~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/lib/libglib-2.0.so' 'QMAKE_INCDIR_GLIB = ~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/include ~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/include/glib-2.0 ~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/lib/glib-2.0/include' ~/.conan/data/qt/5.13.0/bincrafters/stable/build/7eadbcc1d81cf4cb6da18c3e0b9961f100ab38ba/config.tests/glib
+ cd ~/.conan/data/qt/5.13.0/bincrafters/stable/build/7eadbcc1d81cf4cb6da18c3e0b9961f100ab38ba/config.tests/glib && MAKEFLAGS= /usr/bin/make
> g++ -c -pipe -O2 -w -fPIC  -I. -I~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/include -I~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/include/glib-2.0 -I~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/lib/glib-2.0/include -I~/.conan/data/qt/5.13.0/bincrafters/stable/source/qt5/qtbase/mkspecs/linux-g++ -o main.o main.cpp
> g++ -Wl,-O1 -o glib main.o   ~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/lib/libgthread-2.0.so ~/.conan/data/glib/2.58.3/bincrafters/stable/package/f328e8721181dbb381ed842e289123010efd816c/lib/libglib-2.0.so   
 => source accepted.
test config.qtbase_corelib.libraries.glib succeeded

[Morwenn]

I sorted my issues out in private emails with @ericLemanissier, and it turns out that the issues where indeed on the side of my understanding: I didn't know that default options and options explicitly passed in the recipe were considered differently, which explains some of my attempts and of my later misunderstanding.

I'm closing this issue, I suppose that you don't need more noise :)