[FEATURE] Build ProjectM.framework for MacOS

[g-l-i-t-c-h-o-r-s-e]

Please confirm the following points:

• This feature request is NOT for the Android apps in the Play Store
• I have searched the project page to check if a similar request was already made

Application or Project

libprojectM (including the playlist library)

Is Your Enhancement Related to a Problem?

No response

Your Suggested Enhancement

Would love to have a release of a ProjectM.framework for MacOS development or preferably an update to the CMake scripts so we can build our own (:

Alternative Solutions

No response

Additional Context

No response

[kblaschke]

This is certainly something to look into. CMake fully supports building frameworks, but the actual installation process and layout differs a bit from the usual lib/include dir structure projectM and most other UNIX libs use.

I'm not really versed in creating or using frameworks, and certainly can't test them due to not owning any Apple device. I'll look into this matter at some point and have GitHub Actions build a test archive with frameworks and then update this issue so someone with a Mac and the required dev experience can test if the framework is usable.

If one can create a small test project and post the code here that would be great! Can be a simple Xcode or CMake project in Swift or Ocj-C, which uses projectM-4.framework (and probably projectM-4-playlist.framework, not decided a name yet - suggestions welcome!) in a small executable, that would be great for testing, as I can add it to a GitHub Actions workflow and let it check if the framework is good. We can then release it as re-built binaries alongside the sources.

[rootnotez]

I did some research on this, sharing what I found even though I don't know that it is relevant to the task at hand.

A mac framework is similar to a distribution format (.deb) and dynamic library (.so). It may be the most useful way to distribute libProjectM on macos. I suppose the alternative would be individual applications bundling / linking libProjectM statically?

Framework hierarchy, to give an idea of what it's for.

MyFramework.framework/
    MyFramework (the actual binary/library)
    Headers/ (public header files)
    Resources/ (images, nibs, etc.)
    Versions/ (versioning support)

Example frameworks:
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemFrameworks/SystemFrameworks.html

Signing, notarizing, entitlements in Github Actions:
https://github.com/GuillaumeFalourd/sign-and-notarize-gha
https://github.com/indygreg/apple-code-sign-action

Other framework background information:
macOS Code Signing in Depth - https://developer.apple.com/library/archive/technotes/tn2206/_index.html
Anatomy of Framework Bundles - https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html

Including Framework - https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/IncludingFrameworks.html

Bundles (Frameworks) - https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW26

Examples of GHA for Macs with cmake:
https://github.com/qt/qtbase/tree/dev/cmake/macos
https://github.com/forexample/cmake-osx-framework
https://github.com/opencv/ci-gha-workflow/blob/main/.github/workflows/OCV-PR-3.4-macOS-ARM64.yaml

What are the chances that .VCproj can be leveraged for building on MacOS?

[kblaschke]

To make it easier for developers, I'd also suggest to create an umbrella framework projectM.framework, which would then include both the core library as projectM-4.framework and the playlist library as projectM-4-playlist.framework (as each framework can only contain exactly one shared library) within the projectM.framework/Versions/A/Frameworks directory and put a "master header" into this framework, which will include projectM.h and playlist.h for convenience.

Since building as a framework is a different building and packaging process in CMake, it'll require a separate workflow.

The next major version (5.0) of projectM would then use version B, so both 4.x and 5.x releases could then be packaged into the same framework bundle.

[kblaschke]

I've changed how headers are installed via CMake while implementing the logging API, now making use of the PUBLIC_HEADER property which is required to properly structure the resulting framework.