Devilutionx: [macOS] Standalone package

[AJenbo]

The generated macOS app bundle should contain the SDL frameworks so that people don't have to install them manually. For this, we need to setup the @rpath directory to @executable_path/../Frameworks and only to copy the framework inside to bundle, in the path devolutionx.app/Contents/Frameworks/
Check this like reference https://wincent.com/wiki/@executable_path,_@load_path_and_@rpath

[alexey-lysiuk]

I would like to propose a different approach. How about building all dependencies as static libraries? There will be single self contained executable inside app bundle.

[AJenbo]

SDL advices against statically linking. Having it dynamically linked allows others to replace it with a newer version in case the OS changes. I think this applies especially in the case of macOS since Apple is dropping several APIs and changing things on a regular basis.

https://wiki.libsdl.org/Installation

you can build a static library linked directly to your program, or just compile SDL's C code directly as part of your project. You are completely allowed to do that. However, we encourage you to not do this for various technical and moral reasons (see docs/README-dynapi.md)

[alexey-lysiuk]

Why didn’t they mention that updating dynamic libraries may break things?
It’s not about digital signature which breaks as well. It’s about real bugs in any external library, and in SDL in particular.
The problem is users will blame you, not library’s authors.

[AJenbo]

I'm not sure I get your point, by dynamically linking we give the user the option to update it themself. Sure, some people might not initially know how to, and some may blam us and stop there, but they are not everyone and I think users would be better served by having an easier way to solve this class of issues. IMO this is also the strength of the macOS app bundles.

[alexey-lysiuk]

The point is pretty simple. Use monolithic executable, so there will be no way to screw up anything by replacing dynamic libraries.
If something will break because of Apple, you can always release an update.
Letting users to handle such things is a lost cause.

The approach with replaceable libraries just an additional point of failure.
In case of any issue you will need to ask a reporter “Did you alter your app bundle?”

If advanced users desperately want a power to change libraries, they can figure out how to build from sources. Or to stop replacing something that is not broken.

[AJenbo]

I remain unconvinced, if some one is having issues we can ask them to try different issues of sdl much more easily this way, and above all this is the recommended way of doing it by the library authors.

you can always release an update

Update: Since I don't have good access to macOS I can't easily test what version of SDL solves the issues so I'm also dependent on users being able to test and very fy what works before I do a new release, so lowering barrier to doing so is also important for the project.

[alexey-lysiuk]

Sure, there is no silver bullet for software packaging.

[AJenbo]

@BennyFranco & @KarinaRomero since you are the Mac experts here do you have any input on this?

[BennyFranco]

Reviewing this, I think that we should respect the SDL2 team instructions, they have solid reasons about the use of dynamic libraries here.

Since we are not doing any change to the sdl2 core, we don't need add more complexity and build time to the project. It's true that dylibs should be placed in the correspondent directories and embedded libraries should be used for plugin but we only need to load sdl dependencies in this way.

Another good point about use dynamic libs it's performance, its better for the first run load only the needed information instead of a monolithic executable, however macOS needs a way to track dylibs, that is the reason to put it on the system folders, but in the first tests I don't see an important impact and the benefit for macOS users its better.

I'll place here some links for future reference:

• Dynamic Library Programming Topics
• Framework Programming Guide
• Optimizing App Startup Time