Closed Julusian closed 1 year ago
I'm not familiar enough with the MacOS build process, so it may take me some time to look in to this and figure the best solution. In the mean time if there are windows builds where the module is working I'll just stick with those for my clients who use pre-built Companion.
I realised this morning that I hadnt looked at this yet, but I havent completely forgotten. Because of the large amount of loose files that this module was adding due to the native libraries being added as externals, one of them was likely a symlink which apparently breaks the code signing (it has happened before too) I have some ideas on how to make the modules work when not marked as externals, so I'll give that a try when I can
All of these builds which are missing macos versions will have it
Out of curiosity, is there any capability for Companion to reference different module tags for different OS? As that's one way I could resolve this as the libraries that are breaking builds on MacOS, aren't needed on MacOS but are there because they are needed on Windows.
There isn't currently, but that is something we should do. Extending the manifest json schema to support an optional array of supported platforms, then after we do the copy of bundled-modules during the build we could filter and delete some. (Or work the other way and do a selective copy)
But even with that, because of the externals, this module adds 816 files to be installed. All of the other v3 modules are 3006, so this is quite a large number. It would be nice to condense that if possible, and in doing so it would most likely remove the symlink that is causing things to break.
This is a hypocritical thing to say, as bmd-atem is 1802 of those files, I have been putting off dealing with that...
https://github.com/bitfocus/companion-module-tools/pull/24 reworks the build to 'properly' support node-gyp-build, by changing how webpack manipulates __dirname
.
With this, your build-config,cjs
can look like:
module.exports = {
useOriginalStructureDirname: true
}
I need to think on this solution some more. I am hesitant to support it as the webpack config change could have unexpected side effects for modules where its enabled. I have no idea on the implications, or I would have made it the default for modules way back before anything was converted to the 3.0 format.
The builds are now passing with this module. @thedist could you verify that they still work with voicemeeter?
Both running locally on Windows, and running/connecting to it running as proxy on a remote windows machine, works fine!
I'll try and take a look at this over the weekend, for now I have removed the module so that the macos beta builds are working again.
It looks like the native dependencies both provide prebuilds, hopefully it will be possible to use those without marking the whole of the library as external
The build log that gave no indication of the cause:
Build with module: https://github.com/bitfocus/companion/actions/runs/5155551834 Build without module: https://github.com/bitfocus/companion/actions/runs/5156648365