Skip to content

Update OCP to 7.9.3.1#57

Merged
bernhard-42 merged 1 commit intomainfrom
ocp7931
Feb 13, 2026
Merged

Update OCP to 7.9.3.1#57
bernhard-42 merged 1 commit intomainfrom
ocp7931

Conversation

@adam-urbanczyk
Copy link
Copy Markdown
Member

Releasing new OCP tweak (7.9.3.1).

@bernhard-42
Copy link
Copy Markdown
Collaborator

Thanks @adam-urbanczyk

The build of OCP currently fails, because we need to add fmt to the environment.yml of ocp-build-system.
I will merge your PR, add the lib and start a new build as soon as the VTK and SDKs are built and cached.

@bernhard-42 bernhard-42 merged commit 28c4498 into main Feb 13, 2026
53 of 71 checks passed
@adam-urbanczyk
Copy link
Copy Markdown
Member Author

Perfect, looking forward.

@adam-urbanczyk
Copy link
Copy Markdown
Member Author

AFAICT novtk builds are still failing due to missing fmt symbols.

@adam-urbanczyk
Copy link
Copy Markdown
Member Author

@bernhard-42 do you understand the root cause of the failures. fmt is an explicitly dep in the original CMakeLists.txt. If patching goes OK, it should not be needed to manipulate linker flags.

@bernhard-42
Copy link
Copy Markdown
Collaborator

bernhard-42 commented Feb 14, 2026

Compiling for pypi is significantly more difficult, e.g. I have to use _GLIBCXX_USE_CXX11_ABI=0 to match pip VTK, but from my understanding that clashes with libfmt from conda.
Now changed to header-only for libfmt.

Changes in OCP typically cannot be mirrored 1:1 when one doesn't use the consistently built lib ecosystem of conda.

@adam-urbanczyk
Copy link
Copy Markdown
Member Author

OK, so the solution would be to build libfmt ABI compatible with pypi VTK and make it findable for CMake? In principle I could also switch to header only fmt in OCP, but that would likely deteriorate the already long build times.

@bernhard-42
Copy link
Copy Markdown
Collaborator

I anyhow have to fine tune every cmake call for every platform and even patch the ninja build file, since the VTK libs on pypi do not have the version in their name, see https://github.com/CadQuery/ocp-build-system/blob/main/.github/actions/build-ocp/action.yml

So having yet another new param for cmake is not an issue for me. So thanks, but from my side no need to change your approach.

After building the wheel, the github action will then tests against cadquery and build123d. I'd expect some failure there, since I haven't adapted the build123d patches by now (when I built OCP 7.9.3.0, build123d did not support 7.9.3, so a patch was needed). For cadquery I think I still need to patch setup.py of the main branch to install with 7.9.

When finally both the cadquery and build123d tests are all fine, I publish the wheels as release artefacts.

This is typically all a more or less iterative process, since cadquery and build123d main branches evolve over time.

@bernhard-42
Copy link
Copy Markdown
Collaborator

fyi, both ubuntu x86_64 and aarch64 now successfully built the wheels.
Looks like header-only is the way to go for pypi (in order to avoid to additionally need to build libfmt for each platform in its very specific config)

@bernhard-42
Copy link
Copy Markdown
Collaborator

@adam-urbanczyk OCP 7.9.3.1 for pypi is ready and uploaded to https://github.com/CadQuery/ocp-build-system/releases/tag/v7.9.3.1

CC: @jmwright

@adam-urbanczyk
Copy link
Copy Markdown
Member Author

Thank you @bernhard-42 !

@jmwright
Copy link
Copy Markdown
Member

I will upload those tomorrow morning.

@jmwright
Copy link
Copy Markdown
Member

Uploads:

Thanks to @adam-urbanczyk for all your work on OCP, and to @bernhard-42 for all your work on the wheels!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants