(APPLE) Build a Universal Framework, and add code signing and notarization #237
Conversation
cboulay
force-pushed
the
cboulay/cmake_cleanup
branch
from
8d2a332 to
c1d3ebe
Compare
cboulay
force-pushed
the
cboulay/apple_framework
branch
from
9202bd9 to
9531c43
Compare
…ion that installed non-flat header tree by transitive dependencies.
cboulay
force-pushed
the
cboulay/apple_framework
branch
from
7eec7ce to
d2b56fe
Compare
Initial support for Apple Frameworks Move scripts into subfolder Remove set(CMAKE_MACOSX_RPATH ON) because that is already the default value. Fix framework install directory when not installing to the system.
…d for Ubuntu 18.04 which we no longer support)
…(temporarily disabled non apple runners for debugging)
…de_directories. :`(
cboulay
force-pushed
the
cboulay/apple_framework
branch
from
d2b56fe to
73d3650
Compare
cboulay
force-pushed
the
cboulay/apple_framework
branch
from
732e542 to
779473e
Compare
|
I think everything is working. I'll try to retarget a couple applications (e.g., LabRecorder) and the homebrew recipes to this branch and if that goes smoothly then I'll merge this in. |
|
@cboulay let me know if you need any help with this one, I managed to get a pipeline running for code signing and publishing an iOS app via TestFlight. It wasn't fun. |
|
@zeyus , absolutely I'd love some help. In fact, I was going to ask you to re-target your other PRs on this branch because I intend to merge this branch soon (early next week). My (private) projects that use liblsl are currently using What I haven't been testing thoroughly is installing this as a system lib (this works) then linking to the system lib (still works) and figuring out how much or how little of LSLCMake.cmake do we actually want to keep? The only way I could think of figuring this out is refactoring several Qt-enabled liblsl-linking apps to use this branch of liblsl and see what common functionality is needed and isn't better served by some recent functionality in CMake. I haven't had the time to do that. If you manage any liblsl-linking apps, then please try targeting them on this branch and let me know how it goes. |
|
@cboulay Sounds good, I can retarget the other PRs. For my experiment and some other things, I have iOS and MacOS targets, so I can definitely try linking against the system lib instead of bundling the built dylib. I will need to pull this branch into my fork and rebase my changes onto it though because I'm relying on the runtime API config functionality. This isn't a problem and any issues from that will be resolved when I retarget that PR in particular |
This PR attempts to build the lsl library as a (universal) framework instead of a dylib. The primary advantage of putting everything (library, headers, cmake files) inside a framework vs a folder is that it allows us to add entitlements for multicasting. From what I've read, this will make it easier for consumers of lsl.framework to enable multitasking and I hope this will fix some issues with Unity and Apple Vision Pro.
This one is going to take a while to get working on GHA I'm sure while I workout all the certificate and signing/notarizing steps.