Cross-compiling ldr_tools_py

[philm400]

Hi,

I took a fork of your plugin a few weeks back and have been extending it some of my own ideas whilst merging in some of your more elegant code implementations for stud logo type and primitives than mine where.

https://github.com/philm400/ldr_tools_blender

However, I see when you publish a release you have a number of platform you support through compilation of the ldr_tools_py library.

• Are you doing this through cross-compilation using Rust / Rustup and a combination of other tools in the chain?
• Or are you natively compiling on each platform via physical device or VM?

I'm MacOS based.

Reason I ask is that I've tried to setup RustUp with MinGw-w64, but have errors in the build (trying to compile for x86_64-pc-windows-gnu from my M2 MacOS). I feel really close but think I need a little guidance in the right direction now.

:)

[ScanMountGoat]

You should be able to cross compile ldr_tools_py for different targets using the PyO3 guide. The process doesn't look as straightforward as with a regular Rust program.
https://pyo3.rs/v0.21.0/building-and-distribution.html?highlight=cross#cross-compiling

I use a separate runner for Windows, Linux, and MacOS when publishing using GitHub actions. Each runner builds for its own target. MacOS also cross compiles for arm64 on an x64 host, which seems to not require any additional PyO3 configuration. You should be fine just compiling for arm64 for local development on your Mac.

[philm400]

No, just curious to go full circle and see how it works to cross-compile. Plus my eldest son is on Windows machine and is curious to try it out in Blender.
I'm fine building for my Apple Silicon MacOS device, I've got a build script in a .sh file I'm running that builds the library, copies and deploys all files over to the Blender add-on folder to streamline it all.
Pull request at some point would be good. I haven't looked at the new commits or work required yet to make the plugin B4.1/Py3.11 ready. Hopefully it's can be easily done. I've integrated most the work you did on studs and primitives, my own implementation was close but your use of Enum's was more elegant.
One thing I did find though is that the base install of Stud.io's LDraw library doesn't appear to include the High Contrast studs. I had to download the Unofficial parts separately from the LDraw site and merge the two. What I've done in my fork is extract the High Contract stud files and bring them in as part of the add-on folder structure, and add a new path in ldr_tools/src/lib.rs DiskResolver() function for it to work.

[ScanMountGoat]

Makes sense. The actions/upload-artifact@v3 section of the yml script uploads the builds without needing to create a release. You should be able to use the workflow_dispatch trigger to start the action manually. This is what I use if I need to test a build without actually releasing anything. If you're using Blender 4.0, modify the workflow on your fork to use Python 3.10. I'm not sure if there are any limitations for running actions on your own fork.

[ScanMountGoat]

Cross compiling is probably the easiest if it works for you.

[philm400]

You've done all the hard work, I didn't realise GitHub had forked the YAML file too. I've trigger the action and it's successfully completed the Linux build, but the others have been stuck for 30mins waiting for a runner. Internet opinion is to cancel it and run it all again as it shouldn't take that long.

[philm400]

SUCCESS!

On 2nd attempt, huge thanks for the pointers to use Actions