Qt6, pcl 1.14.1, occt 7.8.1, vtk 9.3.1, boost 1.86

[looooo]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• When defining a source/url please add a sha256, sha1 or md5 checksum (sha256 preferably).

[adrianinsaval]

I would not recommend shipping 0.21.2 with qt6, hang on a bit I will be finishing back porting some things to the 0.21 branch and making a final release around the weekend. We can make a qt6 version then

[looooo]

This is for testing only. My goal was to upload 0.22pre packages to freecad/label/qt6. But there is still something missing:

package pcl-1.14.0-h4836831_0 is excluded by strict repo priority

[looooo]

@conda-forge/core anyone able to tell what package is missing for the vtk9.3.0 migration:

Could not solve for environment specs
The following packages are incompatible
├─ hdf5 1.14.3.*  is requested and can be installed;
├─ libboost-devel 1.84.*  is installable and it requires
│  │  └─ python_abi 3.11.* *_cp311, which can be installed;
│  ├─ pyside6 [6.5.0|6.5.1|...|6.6.2] would require
│  │  └─ python_abi 3.8.* *_cp38, which can be installed;
│  ├─ pyside6 [6.5.0|6.5.1|...|6.7.2] would require
│  │  └─ python_abi 3.9.* *_cp39, which can be installed;
│  ├─ pyside6 6.6.0 would require
│  │  └─ qt6-main >=6.6.0,<6.6.1a0 , which can be installed;
│  └─ pyside6 [6.6.1|6.6.2|6.7.0|6.7.1|6.7.2] would require
│     └─ python_abi 3.12.* *_cp312, which conflicts with any installable versions previously reported;
├─ python 3.12.* *_cpython is not installable because there are no viable options
│  ├─ python [3.12.0|3.12.1|3.12.2|3.12.3|3.12.4] would require
│  │  └─ python_abi 3.12.* *_cp312, which conflicts with any installable versions previously reported;
│  └─ python 3.12.0rc3 would require
│     └─ _python_rc, which does not exist (perhaps a missing channel);
├─ qt6-main 6.7.*  is not installable because it conflicts with any installable versions previously reported;
└─ vtk 9.3.0.*  is installable with the potential options
   ├─ vtk 9.3.0 would require
   │  └─ vtk-base [9.3.0 egl_py310h1234567_0|9.3.0 osmesa_py310h1234567_100|9.3.0 qt_py310h1234567_200], which can be installed (as previously explained);
   ├─ vtk 9.3.0 would require
   │  └─ vtk-base [9.3.0 egl_py311h1234567_0|9.3.0 osmesa_py311h1234567_100|9.3.0 qt_py311h1234567_200], which can be installed (as previously explained);
   ├─ vtk 9.3.0 would require
   │  └─ vtk-base [9.3.0 egl_py312h1234567_0|9.3.0 osmesa_py312h1234567_100|9.3.0 qt_py312h1234567_200], which requires
   │     └─ libexpat >=2.6.2,<3.0a0 , which conflicts with any installable versions previously reported;
   ├─ vtk 9.3.0 would require
   │  └─ vtk-base [9.3.0 egl_py38h1234567_0|9.3.0 osmesa_py38h1234567_100|9.3.0 qt_py38h1234567_200], which can be installed (as previously explained);
   └─ vtk 9.3.0 would require
      └─ vtk-base [9.3.0 egl_py39h1234567_0|9.3.0 osmesa_py39h1234567_100|9.3.0 qt_py39h1234567_200], which can be installed (as previously explained).

[hmaarrfk]

it might be that noqt is valuable in build situations like this one.

[h-vetinari]

it might be that noqt is valuable in build situations like this one.

Definitely, that sounds like a great solution! I wasn't aware of your old PR, but it sounds like we should try reactivating it?

[looooo]

it might be that noqt is valuable in build situations like this one.

can you explain what this does.

I think for qt5 we need to specify an older vtk version as vtk was updated to be build against qt6 with more reccent versions..

[h-vetinari]

it might be that noqt is valuable in build situations like this one.

can you explain what this does.

The idea would be that we could do something like:

      {% if qt|int >=6 %}
        - qt6-main
        - pyside6
        - noqt5    # <-- !
      {% else %}
        - qt-main
        - pyside2
        - noqt6    # <-- !
      {% endif %}

and so avoid having two different qt versions in the host environment, which confuses CMake currently.

[hmaarrfk]

I wasn't aware of your old PR

I reopened it. Review appreciated.

[looooo]

I think about removing qt5 from the build matrix. qt5 needs several older (not up to date) dependencies. We can support qt5 via another branch.

[adrianinsaval]

freecad on qt6 has had very little testing and maintainers preferred to stay primarily on qt5 for this release so IMO a qt6 version should be a secondary build not the main one. I'll try again bringing qt5 and other dependencies up to date this week

[hmaarrfk]

I'm less sure that the noqt5 is a good solution. It won't help runtime constraints.

If pyvi is such a tight dependency at build time in terms of qt5/qt6 i think that it warrants a build string that would specify qt5/qt6 to help lock it in step with freecad.

[hmaarrfk]

qt5 needs several older (not up to date) dependencies. We can support qt5 via another branch.

I'm not really sure what this means. I keep both qt5 and qt6 updated. they should both have the same dependency matrix.

So maybe you have freecad dependencies that need to be built for both.

That can in fact be troubling...

[looooo]

I'm less sure that the noqt5 is a good solution. It won't help runtime constraints.

If pyvi is such a tight dependency at build time in terms of qt5/qt6 i think that it warrants a build string that would specify qt5/qt6 to help lock it in step with freecad.

pivy is not needed for the build. It is only a runtime tependency.

I'm not really sure what this means. I keep both qt5 and qt6 updated. they should both have the same dependency matrix.

recent versions of vtk are build only against qt6. Pyside2 is not working with python 3.12. And qt5/qt6 matrix complicates everything a lot.

[hmaarrfk]

Is there a world we’re the next released version of pivy old be built only for qt6?

that might simplify your constraints a lot.

Ps. Apparently there exists a finite set of patches for pyside2 to get it to work on Python 3.12 and 3.13. See feedstock for details.

[adrianinsaval]

looks like this is still needed:

-- Shiboken6Config: Using default python: .cp310-win_amd64
CMake Error at D:/bld/freecad_1730024460162/_h_env/Library/lib/cmake/Shiboken6/ShibokenHelpers.cmake:474 (message):
-- Found Python: C:/hostedtoolcache/windows/Python/3.12.7/x64/python3.exe (found suitable version "3.12.7", minimum required is "3") found components: Interpreter Development Development.Module Development.Embed
The detected Python minor version is not compatible with the Python minor

although I would put this on an if statement to detect if running in azure if possible

[looooo]

windows now fails with:

CMake Error at D:/bld/freecad_1730922399910/_h_env/Library/lib/cmake/Shiboken6/ShibokenHelpers.cmake:474 (message):
  The detected Python minor version is not compatible with the Python minor
  version which was used when Shiboken was built.  Consider building shiboken
  with FORCE_LIMITED_API set to '1', so that only the Python major version
  matters.

  Built with: '3.11' Detected: '3.12'
Call Stack (most recent call first):
  D:/bld/freecad_1730922399910/_h_env/Library/lib/cmake/Shiboken6/Shiboken6Config.cp311-win_amd64.cmake:45 (shiboken_check_if_built_and_target_python_are_compatible)
-- Configuring incomplete, errors occurred!
  D:/bld/freecad_1730922399910/_h_env/Library/lib/cmake/Shiboken6/Shiboken6Config.cmake:5 (include)
  cMake/FindShiboken6.cmake:6 (find_package)
  cMake/FreeCAD_Helpers/SetupShibokenAndPyside.cmake:25 (find_package)
  CMakeLists.txt:87 (SetupShibokenAndPyside)

The shiboken configuration runs find_package(Python, ...)again and somhow finds a wrong python in
C:/hostedtoolcache/windows/Python/3.12.7/x64/python3.exe

and later on for python312 with the mysterios unsolveable:

2024-11-06T20:16:54.2340510Z %SRC_DIR%\src\Mod\Mesh\App\WildMagic4\Wm4TRational.inl(699): error C2446: '<=': no conversion from 'int' to 'unsigned int *'

ref.: https://forum.freecad.org/viewtopic.php?t=57596

[looooo]

can we change this feedstock to rattler-build?

[h-vetinari]

The shiboken configuration runs find_package(Python, ...)again and somhow finds a wrong python in
C:/hostedtoolcache/windows/Python/3.12.7/x64/python3.exe

If you need a specific python version, put it in host: in this case you're picking up tools that are just present in the CI image.

can we change this feedstock to rattler-build?

rattler-build recipes are allowed, so if you get it working, go for it. However, the python issue is going to be there just as much and this PR is IMO massive enough to merit finishing it first before attempting a switch to rattler-build.