add BUILD_ONLY_PYTHON_INTERFACE option

[nim65s]

Here is an example for jrl-umi3218/jrl-cmakemodules#745

I'm testing this with that script

#!/usr/bin/env bash

set -euxo pipefail

BLD=/tmp/coal/build
PFX=/tmp/coal/prefix
PYTHONPATH=""
export PYTHONPATH

rm -rf /tmp/coal

SUB=base
CMAKE_PREFIX_PATH=$PFX/$SUB
export CMAKE_PREFIX_PATH

cmake -B $BLD/$SUB -DCMAKE_INSTALL_PREFIX=$PFX/$SUB \
    -DBUILD_PYTHON_INTERFACE=OFF \
    -DCMAKE_INSTALL_LIBDIR=lib \
    -Wno-dev
cmake --build $BLD/$SUB
cmake --build $BLD/$SUB -t test
cmake --build $BLD/$SUB -t install

SUB=py312

cmake -B $BLD/$SUB -DCMAKE_INSTALL_PREFIX=$PFX/$SUB \
    -DBUILD_PYTHON_INTERFACE=ON \
    -DBUILD_ONLY_PYTHON_INTERFACE=ON \
    -DPYTHON_EXECUTABLE="$(which python3.12)" \
    -DCMAKE_INSTALL_LIBDIR=lib \
    -Wno-dev
cmake --build $BLD/$SUB
cmake --build $BLD/$SUB -t test
cmake --build $BLD/$SUB -t install

SUB=py313

cmake -B $BLD/$SUB -DCMAKE_INSTALL_PREFIX=$PFX/$SUB \
    -DBUILD_PYTHON_INTERFACE=ON \
    -DBUILD_ONLY_PYTHON_INTERFACE=ON \
    -DPYTHON_EXECUTABLE="$(which python3.13)" \
    -DCMAKE_INSTALL_LIBDIR=lib \
    -Wno-dev
cmake --build $BLD/$SUB
cmake --build $BLD/$SUB -t test
cmake --build $BLD/$SUB -t install

SUB=all
CMAKE_PREFIX_PATH=
export CMAKE_PREFIX_PATH

cmake -B $BLD/$SUB -DCMAKE_INSTALL_PREFIX=$PFX/$SUB \
    -DBUILD_PYTHON_INTERFACE=ON \
    -DCMAKE_INSTALL_LIBDIR=lib \
    -Wno-dev
cmake --build $BLD/$SUB
cmake --build $BLD/$SUB -t test
cmake --build $BLD/$SUB -t install

SUB=merged
CMAKE_PREFIX_PATH=$PFX/$SUB
export CMAKE_PREFIX_PATH

cmake -B $BLD/$SUB -DCMAKE_INSTALL_PREFIX=$PFX/merged \
    -DBUILD_PYTHON_INTERFACE=OFF \
    -DCMAKE_INSTALL_LIBDIR=lib \
    -Wno-dev
cmake --build $BLD/$SUB
cmake --build $BLD/$SUB -t test
cmake --build $BLD/$SUB -t install

SUB=merged/py312

cmake -B $BLD/$SUB -DCMAKE_INSTALL_PREFIX=$PFX/merged \
    -DBUILD_PYTHON_INTERFACE=ON \
    -DBUILD_ONLY_PYTHON_INTERFACE=ON \
    -DPYTHON_EXECUTABLE="$(which python3.12)" \
    -DCMAKE_INSTALL_LIBDIR=lib \
    -Wno-dev
cmake --build $BLD/$SUB
cmake --build $BLD/$SUB -t test
cmake --build $BLD/$SUB -t install

SUB=merged/py313

cmake -B $BLD/$SUB -DCMAKE_INSTALL_PREFIX=$PFX/merged \
    -DBUILD_PYTHON_INTERFACE=ON \
    -DBUILD_ONLY_PYTHON_INTERFACE=ON \
    -DPYTHON_EXECUTABLE="$(which python3.13)" \
    -DCMAKE_INSTALL_LIBDIR=lib \
    -Wno-dev
cmake --build $BLD/$SUB
cmake --build $BLD/$SUB -t test
cmake --build $BLD/$SUB -t install

NB: the nix commit is not meant to stay in the final version of this PR.

[jorisv]

I will review it as soon as I can

[jorisv]

@nim65s I think your change are good. I will try to create local conda-package to check if it's working well.

The only issue I see is in most of our project, the root CMakeLists will search for all dependencies. If we don't want some dependencies in the Python build, we will have to add guards around add_dependencies to avoid searching for them in the Python only build.

I was thinking to an alternative approach: turning the python/CMakeLists.txt file into a standalone project. So user that only want the python binding can go on this sub directory, run cmake and build it.
What do you think of this approach ?

[nim65s]

@nim65s I think your change are good. I will try to create local conda-package to check if it's working well.

Yes, I'm planninng to do test packaging on robotpkg / cmeel / nix before marking this as ready.

The only issue I see is in most of our project, the root CMakeLists will search for all dependencies. If we don't want some dependencies in the Python build, we will have to add guards around add_dependencies to avoid searching for them in the Python only build.

do you have an example in mind ? For eg. boost, we'll got this transitively with the c++ package anyways. For eg. eigen, well, I don't really see the issue.

I was thinking to an alternative approach: turning the python/CMakeLists.txt file into a standalone project. So user that only want the python binding can go on this sub directory, run cmake and build it. What do you think of this approach ?

I like the idea, this should probably be tried too. It sounds like it will require heavy changes in the cmake, the docs and the tests though.

[jorisv]

You right for the dependencies, it should be a non issue. The only issue is the guard added to avoid building the main project.

I have tried to create a separate sub project in this PR : #660
I'm just worried with JRL CMake and subproject using JRL CMake can conflict.