Nowadays, I sometimes port slow portions of Python scripts to C++, in order to speed things up. Now, obviously C++ needs to be compiled before being able to use it in Python.
If I were to release an add-on - for which this would be the case -, I would have to include a signed Universal dylib for macOS and dll for Windows.
Can I differentiate between two platform-specific distribution packages or do I ship everything in a single package, say via Yak?
As an alternative to all of this, is it maybe possible to include a set of installation instructions, like a Python pip requirements.txt, a cmake makefile, or a Yak specific set of instructions?
My idea here is that Yak could potentially read these instructions, initiate the local compilation of the necessary dependencies, and install the add-on (much like homebrew on macOS)?
Has anybody already dealt with something similar and can kindly give me some pointers?
You don‘t want libraries to be build on a users PC. The reason is simple, you need to ensure that all the tooling is present on the targets system. And even with the correct tooling, the compilation can fail due to version mismatches, weird system configurations, security and access limitations etc. Its rather likely that things only work on your system. Ideally you ship a precompiled and tested application with (if possible) signed binaries. In theory you can use Python modules like CxFreeze to build msi installer on Windows if that helps and yes you could write CMakeLists file with CMake to create complex cross-platform buildscripts on a users PC. But honestly, you are quite a unicorn when building NET interfacing libraries with Python and C++. The easiest workflow when building addons for the Rhino environment is writing C# libraries (gha/rhp) , like 99% of all addon creators do. Btw a package manager like YAK should be able to ship everything, but the user needs to trigger a build script if that is required. The advantage of installer is that they are also being able to trigger custom actions. Another alternative is a bootloader script which gets executed on the first load of your addon. But again, don‘t do it unless its really required. You also don‘t need to compile Rhino before using it!
At the moment, yes, two separate yak packages to handle Mac and Win, which is also supported by the package manager and food4rhino: it’s not part of the build, just part of the package file name (“win” or “mac”).
I believe that McNeel is working on enhancing yak packaging and the related infrastructure to handle cases like this now that V8 and .NET core 7 open some doors but don’t have a bookmark for that.
That may be true on Windows, but on Linux and macOS, package managers often compile dependencies, when you install something through them. Not once have I encountered one of the problems you describe above, and I use homebrew (macOS package manager) quite frequently.
I know but I dislike C# and I’m not interested in using it, even if hell freezes over.
You’re right. Thanks for pointing that out and answering my question. I remember now reading about that in the Yak documentation a while back.