Skip to content

Conversation

@HellAholic
Copy link
Contributor

@HellAholic HellAholic commented Nov 24, 2025

This pull request adds platform-specific configuration for ARM64 Windows systems to the profiles/cura.jinja file. The main goal is to ensure compatibility and proper functioning of dependencies when running on ARM64 Windows.

Platform-specific dependency configuration for ARM64 Windows:

  • Ensured mpdecimal is built as a shared library for CPython compatibility on ARM64 Windows.
  • Set arcus to build as a shared library for proper Python binding on ARM64 Windows.
  • Disabled tbbproxy in onetbb since it is not available on ARM64 platforms.

CURA-12814

Introduces cura_build_optimized.jinja to handle mixed C++ standard requirements across components, platform-specific options, and build optimizations. Includes settings for compiler standards, shared library configurations, plugin disabling, and parallelization for improved build performance.
Copy link
Contributor

@wawanbreton wawanbreton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does seem to re-copy a large part of existing files. If it is the case, please make a common file and include it in both.
Also, why do we need this ? If it is for a specific need, then the file name could be more explicit.

Added specific shared library and option settings for ARM64 Windows in cura.jinja to improve compatibility. Removed the cura_build_optimized.jinja profile, consolidating build configuration into the main profile.
Enhances the logic for selecting pip requirements by considering OS and architecture-specific keys, including normalized architecture names. This allows for more precise dependency resolution based on the target environment.
# ARM64 Windows: Arcus needs to be shared for proper Python binding
arcus/*:shared=True
# ARM64 Windows: Disable tbbproxy (not available on ARM64 platforms)
onetbb/*:tbbproxy=False
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just saw a conanfile.py in an other repository, that did the same locally, so since this is global, maybe the other one is no more required ? I can't find it though 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one you mean?

https://github.com/Ultimaker/CuraEngine/pull/2264/files#diff-63f09721ade419d29886e8190ffa3c9c756baa9bef8802a7f2aeabf3b545164fR98

So in my head it makes more sense to have it in the conan-config. So the one in the engine is a backup in case this one does not work as expected. I can make the builds based on changes on CuraEngine branches but making builds with different conan-config branches is much more difficult.
As part of the clean up probably one of the two will be yeeted out for the final version.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes some sense. I think I remember some good practices I learned during the conan2 migration, and one of them was to put as many of those things in profiles as possible, so that when you install dependencies of any sub-project, you get the same global configuration and that avoids conflicts. By putting it only in the conanfile of a single project, you can easily end-up with multiple projects requiring different versions/settings of the same dependency. In this case, the setting change is really specific to an architecture so having it in a profile fully makes sense. CuraEngine only specifies that it requires OneTBB, and the profile indicates that it should be setup in a specific way, whenever it is for CuraEngine or anyone else (for example if we some day use it on libuvula).

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