Providing multiple language bindings in a project

[mitchgrout]

I'm working on a library that provides both C and C++ bindings. This library could be consumed as part of a cross-build that only supports C (e.g. no CXX compiler available). How could I set up this library to provide both C and C++ bindings as needed by the consuming project?

Preferably I would like to have these housed under a single meson.build file as they would be kept in the same repository, and could potentially share code (e.g. the C++ bindings may be thin-wrappers over the C code).

Naively I want something like this to work:

# subprojects/foo/meson.build
project('foo', 'c', 'cpp')

foo_c_lib = library('foo-c', c_sources, ...)
foo_cxx_lib = library('foo-cxx', cxx_sources, ...)

foo_c_dep = declare_dependency(link_with: foo_c_lib, ...)
foo_cxx_dep = declare_dependency(link_with: foo_cxx_lib, ...)

# meson.build
project('main', 'c') # *only* supporting C, e.g. no CXX compiler available

foo = subproject('foo').get_variable('foo_c_dep')
executable('main', 'main.c', dependencies: foo)

My hope would be to have some way of making this work. As of meson v1.1.0, this could potentially error due to meson attempting to find a usable C++ compiler (as needed by foo), and failing; however, at no stage does my top-level project want to use C++.

[eli-schwartz]

The add_languages() function allows you to add additional languages / compilers late, i.e. some time after the project() function initialization.

You can use this conditionally inside of an if/endif block, pass the required kwarg to it, read its boolean return value to see if it was able to find those languages, etc.

So you could choose to only build the C++ bindings if:

• not cross compiling
• a C++ compiler is available
• the project is being used standalone as opposed to a subproject
• an option was explicitly specified

Option 2 is the simple option, and would mean always compiling the C++ bindings if possible, and then if the parent project doesn't have a C++ compiler and yet tries to find that dependency specifically, the lookup fails ("no such variable" / "no such dependency") which was going to be an error no matter what.