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.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
