4 ms·

I'm just doing the "standard install". Macports does source code for standard installs. End of discussion. Heavenly Lord, he just keeps coming back with more r

I'm just doing the "standard install". Macports does source code for standard installs. End of discussion. Heavenly Lord, he just keeps coming back with more rules lawyering. The macport for git goes through patching, configuring, building routine that is common in source code installs. Give me peace of mind, strength, and patience in dealing with internet trolls.

Wowfunhappy 6y ago
...no, it does that when the standard install would not be possible to legally redistribute. :) It's true that MacPorts generally prioritizes providing more features (in ffmpeg's case, access to more encoders and decoders) over providing a prebuilt binary. I suggested the +gpl2 varient because I noticed it was present for all the ffmpeg binaries on MacPorts's build server. This is probably why. http://packages.macports.org/ffmpeg/ http://packages.macports.org/ffmpeg/ Now, if adding +gpl2 still causes MacPorts to pull in cmake, that's interesting, and I would like to bring that up on MacPorts's mailing list in case there's a bug. But I suspect adding +gpl2 will make it go away.
markemer 6y ago
Yeah, I’m a maintainer, MacPorts will download a binary if it can. ffmpeg is a weird case thanks to the non-free variants, but even it has some binary installs. Also, for instance, OpenJDK is a port that is offered and we do not compile that in any way on any system because that way lies madness. The other reason that macports will build from source is when there isn’t a binary like early on in Big Sur.
raimue 6y ago
I am sorry, but you are wrong. MacPorts will not go through configure/build/install for all ports, only those for which no binary archive can be made available. As others have already explained, this happens when license restrictions do not allow redistribution of a binary. With your example of ffmpeg, you can check yourself that ffmpeg-4.3.2_0+gpl2.darwin_18.x86_64.tbz2 exists as a binary archive and will be used on a standard install on macOS 10.14. MacPorts will definitely not build ffmpeg from source by default. I recommend you test again with something simpler than ffmpeg, for example bzip2 or less.

Wowfunhappy 6y ago

...no, it does that when the standard install would not be possible to legally redistribute. :) It's true that MacPorts generally prioritizes providing more features (in ffmpeg's case, access to more encoders and decoders) over providing a prebuilt binary. I suggested the +gpl2 varient because I noticed it was present for all the ffmpeg binaries on MacPorts's build server. This is probably why. http://packages.macports.org/ffmpeg/ http://packages.macports.org/ffmpeg/ Now, if adding +gpl2 still causes MacPorts to pull in cmake, that's interesting, and I would like to bring that up on MacPorts's mailing list in case there's a bug. But I suspect adding +gpl2 will make it go away.

markemer 6y ago

Yeah, I’m a maintainer, MacPorts will download a binary if it can. ffmpeg is a weird case thanks to the non-free variants, but even it has some binary installs. Also, for instance, OpenJDK is a port that is offered and we do not compile that in any way on any system because that way lies madness. The other reason that macports will build from source is when there isn’t a binary like early on in Big Sur.

raimue 6y ago

I am sorry, but you are wrong. MacPorts will not go through configure/build/install for all ports, only those for which no binary archive can be made available. As others have already explained, this happens when license restrictions do not allow redistribution of a binary. With your example of ffmpeg, you can check yourself that ffmpeg-4.3.2_0+gpl2.darwin_18.x86_64.tbz2 exists as a binary archive and will be used on a standard install on macOS 10.14. MacPorts will definitely not build ffmpeg from source by default. I recommend you test again with something simpler than ffmpeg, for example bzip2 or less.