Port install never uses packages, always compiles from source - why?

[Ryan Schmidt]

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.