boinc
boinc copied to clipboard
BOINC
[CI] Implement experimental build of OSX binaries with vcpkg
@AenBleidd As I have explained before, I purposely set up the Xcode project to work only with a specific version of each dependent library, to guarantee reproducibility of the exact binary. It will fail if you try to link it with a different version of any library.So you must make sure that vcpkg uses the correct version of each dependent library, not necessary the latest one. These are listed in mac_build/dependencyNames.sh.
@CharlieFenton, thank you for your comment. This is an experimental feature and we have no plans to switch to it in the near feature. And vcpkg support version pinning, so it will be possible to build BOINC with any particular version of any library we want. This could help us in future to react on the latest updates of libraries faster and see whether we are compatible with them or not (like this happens for example for Android with openssl 3.0.2).
Also, Xcode by default builds universal binaries, so the built client and manager will contain code for both the Intel x86_64 and Apple Silicon arm64 architectures. It therefore expects the dependent libraries to also be universal binaries, but the configure / make supplied with the libraries makes only one architecture, which by default is that of the build machine.
My build scripts build each library twice, once for each architecture, and combine them into universal binaries using the lipo command-line utility. The BuildMacBOINC.sh and buildMacBOINC-CI.sh scripts call the individual build scripts to handle this. The buildMacBOINC-CI.sh script also downloads the source code for the libraries, so if you want vcpkg to do this you probably should use BuildMacBOINC.sh or a modified version of it.
I'm afraid, you are looking too far already 😉. There is no goal (for now) to build production-ready binaries for OSX. I know that BOINC for OSX has very specific build flows and I appreciate your advices, we will definitely use them at appropriate time. For now we will just build binaries for separate architectures, maybe run some unit tests on them and nothing more. XCode build flow will remain the main flow for release version of BOINC.
That's fine as far as it goes.
But at some point, we have to move away from this introverted computer science form of testing: "is the code legal for the language we're using - does it compile without errors or warnings?", and move additionally to functional and logical testing: "does the finished program behave in the way we expect in the real world, and can it be used to support scientific research?"
Most of the bugs I've reported over the years have been at that logical level, and we need to have accessible, functional, binaries that can be used for production testing prior to release.
and move additionally to functional and logical testing: "does the finished program behave in the way we expect in the real world, and can it be used to support scientific research?"
Yeah, that is my plan also but this will require a lot of additional implementation, I have to choose what should be done first, new features implementation, bug fixing or adding unit/integration testing. And as you can understand, testing is definitely in this case on the last place.
Of course, if would be nice to cover at least new added/fixed functionality with unit/integration tests, and maybe exactly this I will start doing when working on the next release
@AenBleidd Sorry I wasn't more clear. I was trying to warn you that the Xcode build will fail with many linker errors unless you provide universal binaries for every dependent library.
This will require a lot of additional efforts to implement this.
Currently we have no plans to move everything to vcpkg, so I'm closing for now.