Feature Request: easy app bundle creation

[Ryan Schmidt]

Remember to Reply All so the conversation stays on the mailing list.

On Nov 30, 2011, at 11:43, Roger Pack wrote:

> On Tue, Nov 29, 2011 at 8:14 PM, Ryan Schmidt wrote:
>> 
>> If any port reasonably supports being launched as an app bundle, the port should install that app bundle. It should not be up to the user to need to figure out how to do that. File tickets in the issue tracker to request such changes to any ports where that makes sense. It's easy to add that to ports now, with the app portgroup.
> 
> Wow that is pretty close to what I want.  I was looking for more of a
> "create a standalone app" (or any way to not pollute /opt/local when
> users install it), though I guess I could use a new macports prefix I
> suppose.

The notion of creating a standalone app is pretty much directly opposite of the purpose of MacPorts, which is a good explanation why we don't have such a function.

The purpose of MacPorts is to provide an ecosystem of programs and libraries that work together.

Standalone app bundles are generally self-contained; if they require 3rd-party libraries or frameworks, they're inside the app bundle. Libraries and frameworks installed with MacPorts go in ${prefix}/lib and ${frameworks_dir} respectively.

Standalone app bundles are expected to be relocatable. Software installed with MacPorts usually isn't relocatable, and instead uses absolute paths.

MacPorts ports are designed to be as full-featured as possible; when building a standalone app, you usually want the bare minimum of libraries and features needed for your app. Optional features of libraries that you're not using would be disabled for example. MacPorts doesn't usually provide options to do that, because having a greater number of options (variants) increases our support burden and usually just ends up confusing users, and makes dependency handling more problematic, since we don't have a way to declare dependencies on particular variants of ports (ticket #126).

We do have a handful of ports for proper Mac standalone apps, like Adium. Ironically this type of software tends to be the hardest for us to create ports for, and to keep updated, since they want to link against system libraries, want to build against an older SDK in order to be compatible with the largest range of OS X versions, want to default to building universal, want to include auto-update mechanisms like Sparkle, etc., all of which is the opposite of what we want in MacPorts. Really, it'd be best to not have this type of software in MacPorts, since it can be installed quite easily simply by downloading it from the developer's site. MacPorts is primarily for software whose authors do not primarily (or at least not exclusively) target OS X.

I created the app portgroup for software that behaves like a proper Mac app but does not create its own app bundle -- primarily software written using libsdl, or sometimes Qt. libsdl is a cross-platform library commonly used for games; Qt is a cross-platform library often used for non-games. Both libraries contain enough Mac-specific code to make programs written using those libraries behave like proper Mac apps -- they have a Mac event loop, they show a Mac menu bar, they show an icon in the Dock that behaves properly, they have a Quit menu item that can quit the app, etc. IIRC Qt usually creates app bundles for you already, but libsdl doesn't.