meson and swipl-ld

[dunklecat]

Hi all!

I'm trying to set up a C++/Prolog project using meson. Sadly meson is telling me that it doesn't know the compiler (swipl-ld) that I'm trying to use. This compiler is just a wrapper around gcc and other common tools that is needed to automate some operations needed to call Prolog inside my C++ application. Is there a way to pass this phase or I'd need to add this compiler to the meson's known compilers here?

Console output

The Meson build system
Version: 1.8.2
Source dir: **Redacted**
Build dir: **Redacted**/build
Build type: native build
Project name: myProject
Project version: undefined

meson.build:1:0: ERROR: Unknown compiler(s): [['swipl-ld']]
The following exception(s) were encountered:
Running `swipl-ld` gave "no pre-processor defines"

Log

Main binary: /nix/store/9yh9ak97gn659bk4d3n411fx6c0ng7s2-python3-3.13.5/bin/python3.13
Build Options: -Db_coverage=true --native-file=./meson-swipl.ini
Python system: Linux
The Meson build system
Version: 1.8.2
Source dir: **Redacted**
Build dir: **Redacted**/build
Build type: native build
Project name: myProject
Project version: undefined
-----------
Detecting compiler via: `swipl-ld --version` -> 0
stdout:
gcc (GCC) 14.3.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-----------
Running command: -cpp -x c -E -dM -

meson.build:1:0: ERROR: Unknown compiler(s): [['swipl-ld']]
The following exception(s) were encountered:
Running `swipl-ld` gave "no pre-processor defines"

meson-swipl.ini

[binaries]
c       = 'swipl-ld'
cpp     = 'swipl-ld'
ld      = 'swipl-ld'

[eli-schwartz]

The reason meson needs to correctly detect the compiler is precisely because swi-ld is a wrapper that doesn't expose the same interface as a real GCC compiler.

Per your link, you need to pass GCC options via -cc-options, and select whether to use GCC or clang via -cc. Meson would need to know how to handle all this correctly, it can't just assume any valid GCC command line flag is a flag for this wrapper.

[dunklecat]

Thank you for your reply. What I wonder is if there is an "easy" way to tell meson this on my end instead of (or before) contributing to the source code as stated here. I read the documentation but as I'm not really experienced with meson apart common project layouts I may have missed something useful.

PS I noticed the answer to the FAQ is incorrect as detect_c_compiler is inside mesonbuild/compilers/detect.py and is just an alias for _detect_c_or_cpp_compiler. I'll look into it later trying to understand if is it better to open an issue or create a little PR for it.

[eli-schwartz]

Not sure.

The easiest mechanism for allowing this sort of code generation wrapping tool, is probably if the tool supports a mode whereby it generates the code (e.g. an object file) specific to that ecosystem, and allows you to drive the compilation and linking yourself. For example, swig is pretty easy to use from meson as a custom target that outputs a C/C++ wrapper file for whatever language you want to generate a binding for.

On the other side of things, gnome has the gobject introspection scanner and compiler, which is implemented as a custom meson module. Meson needs to detect a C compiler, then passes the path to that compiler (and also passes CFLAGS) as a special argument to the introspection tooling, as well as setting up dependencies and link commands for any C libraries that are needed by introspection. It turned out to be complicated enough that it wasn't practical to support without handwritten tool-specific support.

swi-ld could turn out to be like either one of these, or else somewhere in the middle. I don't know since I've never used it. :D

[dunklecat]

Thank you for your insight! I'll look into them asap.

As far as I understood maybe the first part of the gnome tool (detecting c/c++ compiler and linker) can be useful in order to pass everything to swipl-ld, but I hope it will turn out simple enough.

PS welp, more than 2k locs for that module...