Native conan dependency support

[Sahnvour]

Hello,

I'm using conan for some dependencies. It has advantages over wrapdb, namely a much much bigger pool of libraries, and the ability to acquire prebuilt packages.

Currently, conan-installed packages can be detected via pkg-config or cmake but both have problems. However, when installing packages it also produces a summary file conanbuildinfo.txt that, I think, contains all the relevant pieces of information: include dirs, lib dirs ...

Would you consider a builtin way to detect dependencies from this ?

[e820]

Would you be able to outline some of the problems and shortcomings of the existing pkg-config based approach? As far as I know the Conan team recommends the use of the pkg-config generator for Meson builds so I'm guessing they deem it sufficient.

[Sahnvour]

As I've reported in #6711, I can't use pkg-config if the output of the generator is in the build directory itself. If you know a better way that keeps builds self-contained I'd be glad !

[e820]

Hmm. Personally I would not be against having a Conan dependency method, it certainly shouldn't be hard to implement, I do however see 1 (and a half) issues:

• Meson has traditionally not quite been in favour of fully self-contained builds without external configuration. At the very least this is true for the current stance on toolchain configuration via machine files and the rather primitive build option mechanism.
• You mentioned conanbuildinfo.txt, is this a stable format that can be relied upon?

[Sahnvour]

The format is documented here, and looking at the page it seems that's the purpose of the file to be relied upon.

I just discovered there is also the option of custom generators but I don't know yet if one could be written to work with meson.

Meson has traditionally not quite been in favour of fully self-contained builds without external configuration. At the very least this is true for the current stance on toolchain configuration via machine files and the rather primitive build option mechanism.

Why is that ? I don't mind configuring the build from the command-line (even if I'd rather be able to do it from the script/option file directly sometimes), or depending on the local machine toolchain, but self-contained is important for reproducibility and ease of use.

[Sahnvour]

So I've quickly hacked a custom generator as proposed in conan's documentation. See https://gist.github.com/Sahnvour/5810692a395589c62086f1bc7f0ddf13 for the (short) impl and resulting meson.build (with glfw/3.3.3 as the only dependency) that can then be used in a meson project.

I'm not sure what to make of cflags vs cppflags, sharedlinkflags and exelinkflags. @jpakkane does this seem worth pursuing to you ?

[bruchar1]

The way to work with conan packages is to use conan to generate pkg-config files and meson configuration:

    def generate(self):
        pc = PkgConfigDeps(self)
        pc.generate()

        tc = MesonToolchain(self)
        tc.generate()

Then you configure meson using the generated file:

meson setup --native-file conan_meson_native.ini ...

(or similarly for cross-build)

[Sahnvour]

@bruchar1 If I understand correctly this means writing a conan.py for the project, calling conan and then always having to setup meson with this particular file manually. My goal is to not have to call multiple tools in order to setup/build the project, I would really like to keep it all inside meson somehow. This is a major point for user-friendliness.

[eli-schwartz]

Is there something like conan --print-pkgconfig-directory that you can run after installing deps?

Or maybe conan run meson setup builddir that sets up a Conan environment with PKG_CONFIG_PATH etc. set up, then runs the command (in this case Meson) in the modified environment?

Or maybe conan-pkg-config --cflags --libs depname that installs on demand, then runs pkg-config under the hood and passes its output to the invoking tool?

What's the general recommended way to use Conan to install dependencies and then manually use them?

[bruchar1]

Conan has generators for different toolchains. For instance, with cmake, it will generate a file to import in your cmakelists.txt. For meson, the MesonToolChain generates the ini file to use for --native-file or --cross-file parameter. conan also provides a Meson build helper to call meson from conan build and package commands. The advantage of using the Meson ToolChainGenerator is that it will configure your meson setup with the right build type, architecture, etc.

Therefore, the usual way to use conan would be to do:

conan install
meson setup
ninja

It is also possible to configure the build command in conan to allow doing;

conan install
conan build

at the expense of wrapping the build process in the python process.

Files conan generates through generators are put in the --install-folder (for conan 1.x) or --output-folder (for conan 2.0).

I think it could also be possible to call conan from meson. But in that case, you must ensure you pass the right settings (architecture, compiler, etc.) to conan to be sure it installs the right version of the package.

[bruchar1]

See https://docs.conan.io/2/integrations/meson.html for an example.

[Sahnvour]

Thanks I see.

Also, my projects are divided in multiple git repositories making use of the subproject feature. Multiple projects can use different conan dependencies, and I don't want to have to transitively accumulate every dependency in the final superproject, so I fear this is not an option.

For now I'm back to "abusing" the pkg_config_path default option, which does exactly what I want, except that my use case isn't handled by meson. https://github.com/mesonbuild/meson/issues/6711#issuecomment-1382285806