Compiling Cython code with C++ still generates an error suggesting C++ compilation is not occurring?

[adam2392]

Hi,

I am trying to compile a Cython project with C++ because it uses things like vector. The code is here. I have the following code in my meson.build file:

extensions = [
  '_sklearn_splitter',
  '_unsup_criterion',
  '_unsup_splitter',
  '_unsup_tree',
]

foreach ext: extensions
  py3.extension_module(ext,
    cython_gen.process(ext + '.pyx'),
    c_args: cython_c_args,
    include_directories: [incdir_numpy],
    override_options : ['cython_language=cpp'],
    install: true,
    subdir: 'sktree/tree'
  )
endforeach

This suggests, that I should be doing the equivalent of language="c++" inside my setup.py file when I was originally using setuptools/numpy.distutils. However, I run into an error linked in the below reference.

I am running the following commands with corresponding output:

(sktree) adam2392@Adams-MBP scikit-tree % meson build --prefix=$PWD/build  --wipe 
The Meson build system
Version: 1.0.0
Source dir: /Users/adam2392/Documents/scikit-tree
Build dir: /Users/adam2392/Documents/scikit-tree/build
Build type: native build
Project name: scikit-tree
Project version: 0.0.0.dev0
C compiler for the host machine: arm64-apple-darwin20.0.0-clang (clang 14.0.6 "clang version 14.0.6")
C linker for the host machine: arm64-apple-darwin20.0.0-clang ld64 609
C++ compiler for the host machine: arm64-apple-darwin20.0.0-clang++ (clang 14.0.6 "clang version 14.0.6")
C++ linker for the host machine: arm64-apple-darwin20.0.0-clang++ ld64 609
Host machine cpu family: aarch64
Host machine cpu: aarch64
Library m found: YES
Program cython found: YES (/Users/adam2392/miniforge3/envs/sktree/bin/cython)
Program python3 found: YES (/Users/adam2392/miniforge3/envs/sktree/bin/python3)
Message: /Users/adam2392/miniforge3/envs/sktree/bin/python3
Message: /Users/adam2392/Documents/scikit-tree/build/lib/python3.9/site-packages/
Found pkg-config: /opt/homebrew/bin/pkg-config (0.29.2)
Program _build_utils/cythoner.py found: YES (python /Users/adam2392/Documents/scikit-tree/sktree/_build_utils/cythoner.py)
Build targets in project: 4

scikit-tree 0.0.0.dev0

  User defined options
    prefix: /Users/adam2392/Documents/scikit-tree/build

Found ninja-1.11.1.git.kitware.jobserver-1 at /Users/adam2392/miniforge3/envs/sktree/bin/ninja
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.

Then I run ninja:

(sktree) adam2392@Adams-MBP scikit-tree % ninja -C build                          
ninja: Entering directory `build'
...

and get the following error

sktree/tree/_unsup_tree.cpython-39-darwin.so.p/_unsup_tree.c:757:10: fatal error: 'ios' file not found
#include "ios"
         ^~~~~
1 error generated.

Reference: https://stackoverflow.com/questions/53471655/compiling-cython-with-gcc-no-such-file-or-directory-from-include-ios

[dcbaker]

The override_options approach only works when you have Meson control the pyx -> cpp translation as well as the cpp -> o compilation.

you either need to get rid of the cython_gen generator, and pass the pyx files directly to py_extension or modify the generator to pass the right options and output a file called .cpp instead of .c (sorry if this is too brief, I’m on my phone)

[adam2392]

Ah I see! That makes sense. Would you want a PR to update the documentation explaining this to a user?

[eli-schwartz]

I mean, this basically boils down to "you are not using the cython language in Meson, you are using your own .c files", so it fails the "This means that you can include it as a normal language" step.

:)

The state of affairs is slightly confusing because it's still common for people using non-trivial cython projects to handle it themselves due to needed improvements in cython (header order-only dependencies support just landed, cython itself needed improvements for depfile generation) which means that they aren't yet using cython as a normal language in Meson. Hopefully that will no longer be an issue once Meson 1.1.0 (unreleased) is available everywhere.

Documentation PRs are always welcome though. :)