I’m getting this error in my GiHub Action build, but not when building locally:
I bumped the Rack SDK version in the build.yaml config, thinking the problem was that I’m out of sync with my current cloned Rack sync to latest, but it didn’t help:
env:
rack-sdk-version: 2.6.4
src/widgets/text-input.hpp: In member function 'virtual void pachde::MultiTextInput::onSelectKey(const rack::widget::Widget::SelectKeyEvent&)':
src/widgets/text-input.hpp:57:19: error: 'const struct rack::widget::Widget::SelectKeyEvent' has no member named 'isKeyCommand'
| if (e.isKeyCommand(GLFW_KEY_ENTER, RACK_MOD_CTRL) || e.isKeyCommand(GLFW_KEY_KP_ENTER, RACK_MOD_CTRL)) {
I realize I can just not use isKeyCommand and parse the key myself, but the difference between the CI and local builds is troubling.
Ideas?
(Local build is Windows, MINGW64 command line).
(ed. Local build on Mac also doesn’t hit the error, either/)
I’ve also had it happen twice that the Mac build in the GitHub action failed because the compiler did some stricter checking while the local build (also Windows MINGW64) and the Linux/Windows GitHub builds did not fail. So there are indeed small variations in the compilers used for the different environments.
My local builds are from Rack source. I usually just pull when Rack releases. I have been lazy and not checked when this method got added. I suppose I should grab an SDK for checking this kind of thing.
Does main track releases, or do I have to go by tags? I haven’t seen any notes on Rack’s release management style.
The rack-sdk-version version in qno’s Github Actions workflow only controls the version used for the Rack SDK on Mac, where it downloads the SDK and compiles the plugin directly on a Mac server.
For Windows and Linux, it uses a pre-compiled version of the plugin toolchain, and it just uses whatever version of the SDK is present in the toolchain image. For qno’s, that’s still at Rack 2.5.2. You’ll need to use a more up-to-date version like Bloodbat’s to compile against a newer version of the SDK.
Using potentially different SDKs in the different platform arms is a pit of fail I just fell in – thanks!
I have in my TODO list for a while to try Bloodbat’s, but now I guess it’s time.
Next on the todo list is try building my own toolchain, now that I have a Mac. I want to keep Windows as my main driver, but I really don’t want to deal with Docker.
Next project isn’t Rack, and I’ll be looking into using Zig, which has a far better cross-platform build story than just about anything else.
My toolchain image should work as a drop-in replacement for QNO’s.
My image uses the 2.6.3 SDK; 2.6.4 produces plugins with funky errors, so, if you want to keep SDK synchronization, the Apple ones should be set to 2.6.3 as well.
