3 ms·

That can't be true. For any mildly complex application I install it asks for "xcode-select --install". I'm using an intel Mac on 10.14.6, so it is pretty standa

That can't be true. For any mildly complex application I install it asks for "xcode-select --install". I'm using an intel Mac on 10.14.6, so it is pretty standard. I just reinstalled the software under a year ago and redownloaded macports from the website and installed it. It seems to require a local compiler to be installed for most applications, such as gcc or llvm. For instance, why wouldn't installing ffmpeg just download the ffmpeg binary instead of the all the compiler dependencies? > sh ~ % sudo port install ffmpeg ---> Computing dependencies for ffmpeg The following dependencies will be installed: Xft2 XviD aom autoconf automake brotli cairo cargo cargo-bootstrap cargo-c cctools cmake ... etc

Wowfunhappy 6y ago
Oh, that may be because ffmpeg uses libraries with incompatible licenses. I should have mentioned, ports with nonredistributable binaries are also built from source, and MacPorts tends to interpret licenses conservatively. Does the list change if you specify the +gpl2 varient?
- guessbest 6y ago
  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

Oh, that may be because ffmpeg uses libraries with incompatible licenses. I should have mentioned, ports with nonredistributable binaries are also built from source, and MacPorts tends to interpret licenses conservatively. Does the list change if you specify the +gpl2 varient?

guessbest 6y ago
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.