[QGIS-Developer] cmake PYQT_SIP_DIR (via Python_SITEARCH) value wrong on Debian and derivatives

[Greg Troxel]

Richard Duivenvoorde via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> On 2/9/24 14:24, Greg Troxel via QGIS-Developer wrote:
>> How will this affect builds on other systems?   It seems there is
>> something deeper wrong, and the real problem might be that there are
>> multiple legitimate ways to install things, and that the Find script is
>> deficient.
>> How is it looking?   It would seem that finding the python directory
>> should use some python config mechanism.
>
> There are links to deeper info in my issue comment, so see:
>
> https://gitlab.kitware.com/cmake/cmake/-/issues/25113
>
> which makes it most clear.

Thanks, that helps tremendously but I am not yet fully understanding.

This helped me:

https://askubuntu.com/questions/1406304/virtualenv-installs-envs-into-local-bin-instead-of-bin

So:

  This is about Debian (and hence Ubuntu etc.) doing something unusual,
  vs every other system (Other Linux, Windows, Mac, *BSD, illumos.)

  Instead of using the default paths that python uses, they have
  configured python so that things have an extra local in the path, so
  that the prefix is $foo/local when the user asks for it to be $foo.

  This choice on Debian's part is a bug to be worked around.

  Setting DEB_PYTHON_INSTALL_LAYOUT='deb' will set the scheme to
  deb_system which is like posix_default.  This is likely ok if one is
  building a deb, but I am guessing not ok if one is building qgis with
  --prefix=/usr/foo.

  It seems like the right fix is for the cmake support that qgis is
  using to say "if scheme is posix_local, change it to posix_default",
  thus working around the Debian bug.

  However, surely Debian people don't think this is a bug.

  Other python software, build on this system, sees a different path?


It sounds like you are proposing to work around this by setting the env
var in the qgis CI environment, and perhaps to recommend to users, and
maybe even to flip it on for users, which is a workaround.

And in the glorious future, cmake will someone manage this by itself.

(I remain unclear on what happens if someone builds on Debian with
--prefix=/usr/foo, but me being unclear on that is ok.)