This is very interesting. MacPorts does allow building portable packages though, unless i’m missing something here?
@barracuda156?
Are you saying that packages built via portable-mac-directory can work across different versions of OS X, having included copies of all the system dependencies?
You can basically do:
`sudo port install ffmpeg` (or anything really)
and then run pmacd:
pmacd ffplay ffplay-pmacd
(this is an example for newer Mac OS which actually enables FFplay in the MacPorts builds).
Then you have a ffplay-pmacd folder in the current directory. You can move this to anywhere and it works because it contains all the dynamic libraries in the folder, and the executable was also copied to the folder and modified to point to the dynamic libraries relatively in the folder itself. You can also copy this directory to any Mac without MacPorts even installed, and if it is the same Mac OS version it will work. Newer Mac OS versions then what it was compiled on should also work. This is probably more forward compatible on older Mac OS versions since it can bundle the actual system libraries and frameworks linked. Newer Mac OS doesn't really work like that but it should not be a problem really unless an entire framework was removed in the newer OS version.
This also works for like wget, git whatever but you need to make sure that the program itself doesn't require external config files or SSL certs and what not because that won't be on someone else's Mac if they don't have the same exact setup as you. If you just compile the software yourself you can configure the SSL certs to a relative path for example and bundle them in the directory though. FFplay is just an easy one without any of that being required to just play videos anyways. It's really meant as a tool to run after building your own software but it's an example that's easy to understand.
What I used this for first was my
source-engine-mac-app. So I compiled the source engine on Mac OS 12, which linked to MacPorts libraries. The user would have to install MacPorts and the same versions of said libraries if I didn't run it through PMacD to just run Half-Life 2. Instead they can just download Source Engine.app and run it without even knowing what MacPorts is.
Also, if you are developing a program from scratch that uses dynamic libraries, this allows you to release it in a way that actually works on other Macs.
Another way I could explain it, is PowerPC Media Center 7 infamously requires to be in /Applications to function. This tool can change all the dynamicly linked executables to point to relative self-contained paths instead of absolute ones, and with some additional AppleScript related updates the whole thing could be ran from anywhere, i.e. ~/Desktop/PPCMC.app or ~/Downloads/PPCMC.app or wherever.
I originally wrote the PLED tool because of how bad releasing Linux software is. If you download some linux program precompiled it probably will complain about some old version of a dynamic library not being installed and won't run and then you just end up compiling it from source. PLED fixes that, I've released portable disc burning software that actually works on all modern Linux distros using it. Same idea with PMacD.
Another example is
https://github.com/LukeZGD/Semaphorin. It literally doesn't work on anything but Mac OS 10.15, but if they had PMacD it would (because i.e. Mac OS 12 doesn't have the OpenSSL lib the internal executables needs to run).
I hope that made sense.
