[Buildroot] [PATCH v2 1/2] package/python-pybind: fix upgrade to version 2.6.1

[Arnout Vandecappelle]

On 06/12/2021 22:45, Yann E. MORIN wrote:
> Guillaume, All,
> 
> On 2021-12-06 20:31 +0100, guillaume.bressaix at gmail.com spake thusly:
>> From: "Guillaume W. Bres" <guillaume.bressaix at gmail.com>
>>
>> The python 'setup.py' script needs header files
>> in $(@D)/pybind11 to work since v2.6.1, and these
>> files are generated by an internal minimalist cmake build.
>>
>> Fixes
>>     http://autobuild.buildroot.net/results/b89f1de64b308dffa73675f1f31ccb0b7be5a10d
>>     http://autobuild.buildroot.net/results/d0287b7f64f206b0f074908c5780a3632e0cb799
>>     http://autobuild.buildroot.net/results/27efb545a5a719a5581c8f746d3a3555ff4216ce
>>     http://autobuild.buildroot.net/results/d2f0a0ad8f6c7178517df109e7d885dac9134c3a
>>     http://autobuild.buildroot.net/results/b57e9a3279260dae4a590f9421238fcabb2f7cab
>>     http://autobuild.buildroot.net/results/515e6f2fc6b5780260d98d6bb52b541ce4bf1afe
>>     http://autobuild.buildroot.net/results/d89c4ecc81222d4f80c951da2232d2e393fa1c69
>>
>> Signed-off-by: Guillaume W. Bres <guillaume.bressaix at gmail.com>
>>
>> ---
>> This remains a python-package.
>>
>> 'python setup.py' actually hardcodes a system call to cmake now,
>> which seems dirty at first. But if we have a cmake env when they
>> do that, the install variables are passed and installation
>> is smooth. They probably introduced this call to make setup.py
>> self sufficient, as most people install this package from 'pip'.
>>
>> ---
>>   package/python-pybind/python-pybind.mk | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/package/python-pybind/python-pybind.mk b/package/python-pybind/python-pybind.mk
>> index a6a1bdb976..bfd7f6f59a 100644
>> --- a/package/python-pybind/python-pybind.mk
>> +++ b/package/python-pybind/python-pybind.mk
>> @@ -9,5 +9,12 @@ PYTHON_PYBIND_SITE = $(call github,pybind,pybind11,v$(PYTHON_PYBIND_VERSION))
>>   PYTHON_PYBIND_LICENSE = BSD-3-Clause
>>   PYTHON_PYBIND_LICENSE_FILES = LICENSE
>>   PYTHON_PYBIND_SETUP_TYPE = setuptools
>> +PYTHON_PYBIND_INSTALL_STAGING = YES
>> +
>> +# every single 'python setup.py' call actually calls cmake
>> +# internally, to populate $(@D)/pybind11 with build requirements.
>> +# If we have a host-cmake env at that moment,
>> +# then the final installation paths are properly defined
>> +PYTHON_PYBIND_DEPENDENCIES = host-cmake
> 
> We do not hard-code a dependency to host-cmake, in case the system cmake
> is sufficient. Instead, we use $(BR2_CMAKE_HOST_DEPENDENCY) which is set
> appropriately.

  This turns out not to work in Guillaume's test setup.

  It turns out that he has a preinstalled cmake which is very old, but also 
cmake3 which is recent enough. Therefore, BR2_CMAKE is set to /usr/bin/cmake3 
and BR2_CMAKE_HOST_DEPENDENCY is empty. However, setup.py hardcodes "cmake".

  So, possible solutions:

- Forget about setup.py and instead hack it into a cmake-package. Not ideal from 
a maintenance perspective, because later updates may have changes to setup.py 
that we need to replicate.

- Patch setup.py so we can tell it to use BR2_CMAKE instead of cmake-in-path. 
This is nice because we can use the occasion to also pass in the rest of the 
cmake options for proper cross-compilation.

- In host-skeleton, symlink BR2_CMAKE to host/bin/cmake, so that will be the 
'cmake' that is found in $PATH. This has the advantage of also covering other 
potential cases of the same problem, but I feel it's a bit meh.

  So I have a slight preference for the second option, but Yann you may have 
other ideas.


  Regards,
  Arnout