On Apr 11, 2020, at 02:20, Lothar Haeger wrote:
>> If you think about it for a moment you will realize there is no way to use
>> the prebuilt binaries with non-standard installation options.
>
> Application bundles are supposed to be self contained and movable, afaik, and
> I would expect those built by macports to be that, too.
Applications built within MacPorts would be movable, yes. But they would not
necessarily be self-contained.
If you are developing an application for standalone distribution outside of a
package manager, then yes you would want it to be self-contained. For example
if your application needs libpng or Qt or any other library that's not part of
macOS, you would want to put copies of those libraries inside the application
bundle. But within MacPorts, we do not want to do that. If an application needs
libpng or Qt, we would want the application to link to the existing MacPorts
copies of those libraries, both to reduce the disk space use by the application
and so that, if those libraries are updated, the application automatically
benefits from those updates.
A user who wishes to redistribute a MacPorts-built application as a standalone
application can do so with the help of the dylibbundler port.
> Command line tools installed under <prefix> might be different, but I can
> also move a binary from /opt/local/bin to e.g. /usr/local/bin and it still
> works and finds its libs and dependencies as long they're in the path.
Yes you can move a binary and the binary still works. But what if the absolute
path to that binary was baked into other files that the port (or another port)
installed? Will those other files still be able to find the binary you moved?
(No.)
Although it is less common, it is possible for the binary that lives within an
application bundle to be dual-purpose -- to be able to be used as a
command-line program, in addition to launching a GUI. Or a second
command-line-only binary might be located inside the application bundle. Ports
that install applications of this type might put a symlink to such a binary
into ${prefix}/bin. (I count over a dozen such ports in our tree today.) Those
symlinks would break if you were to move the application.
