I’m looking for people who can help better shape the MacOS installer. As is, we use CMake’s cpack to generate a bundle as a .dmg file. No code signing, etc. is done. As a result, users have to be a little persistent in working around MacOS warnings that it is completely unsafe what they are doing
I registered as Apple Developer and generated a code signing certificate. Seems that is a step, but only the first I assume that if you do everything using Xcode, all will be easy from here, but we don’t.
It seems CMake’s Cpack now has support for MacOS installers. See CPack productbuild Generator — CMake 3.30.3 Documentation. Given some of the parameters they ask for, it looks like this can do the signing. Should we move from .dmg to .pkg? Does anyone has experience building a .pkg using cpack or, even better, getting the thing signed?
I pushed some changes that make the bundle satisfy the Apple bundle content requirements and added some calls to codesign that seems to result in a properly codesigned app on the disk image. But …
As a result the bundle can no longer load .dylibs from other places. Notably it can no longer load XQuartz, Python and Java I guess this is because these are not signed? Anyone here who knows are least how this must be fixed in theory? @twan maybe?
@jan I promised to return to this issue after June because I hoped to have a bit of a holiday. That is to say, I don’t consider the proposed SWI Prolog Framework as a holiday project
I want to start with an inventory of what is necessary to create a MacOS Framework (MFW from now on) of SWI-Prolog and the associated libraries without the applications, except for “command line” text-only SWI-Prolog applications.
To that end it seems advantageous to compile the core source code and some libaries in Xcode because it is then, probably, easier to find out how to (re-)configure the CMake configurations.
Please some opinions about this approach before I find myself in the weeds
No worries This post was mostly to run a new issue: how to we use XQuartz, Python and/or Java if we go for code signing? Will the framework approach also solve that?
I guess it can make sense to see how Xcode organizes similarly structure projects. Whether it is a good step to try and compile some of the code using Xcode, I don’t know. CMake does support Xcode as backend AFAIK. No clue how well it works. I once tried the Microsoft Visual Studio backend with little result. Using the Microsoft nmake backend sort of works (be it terribly slow to build).
Fixing up the bundle and getting it signed was after all not too hard. It does require quite some reading through rather fragmented and contradictory stories I guess the framework story is similar.
If we go the framework route, can we still get to a single download and have all working? Should we can go to .pkg instead of .dmg format?
@jan Okay, I’ll just start and see were it leads to.
With regard to deployment options, I think an installer becomes necessary. Frameworks are deployed as .pkg with install scripts. Of course, applications can also be installed using .pkg with install scripts.
But your’re right, it wouldn’t be as easy as simply dropping a single “application” into the Application-folder.
In my experience as a user, these .pkg installers on MacOS are pretty convenient and straightforward to use.
Do you have certain requirements precluding the deployment using .pkg with install scripts?
Moving to .pkg sounds fine to me. The only thing on which I insist is that it is easy enough to script building the .pkg, preferably directly through Cmake. CMake does support creating .pkg files.
