"cask" ports just keep on rolling in...

Ryan Schmidt ryandesign at macports.org
Sat Feb 6 11:02:34 UTC 2021



On Feb 6, 2021, at 04:15, Ken Cunningham wrote:

> try the sagemath one if you like. It's all set, for a newish system at present:
> 
> https://github.com/kencu/myports/blob/master/binary/sagemath-binary/Portfile
> 
> It is a stress test, for sure -- and I fully admit you may know simple tweaks to make it much more efficient.

I did see that portfile in the previous discussion. I don't feel a need to try it myself. The portfile doesn't look overly more complicated than most ports.

Some tweaks could of course be made to the portfile.

To save some time and disk space usage, the app could be moved to the destroot rather than copied.

Something should be done to ensure that the port errors out on earlier OS versions on which it won't work. This is not a binary-port-specific issue; we've long wanted MacPorts base to be improved to handle this better.

If the binary is x86_64 only supported_archs should reflect that. If the binary is arm64/x86_64 universal then the universal variant should be enabled and for nonuninversal builds the "other" arch should be removed from all files with lipo. The libxl port gives an example. This could be tedious if there are many files, and could be a candidate for including in a hypothetical portgroup.

You're currently setting version conditionally. version is a required keyword; it must be set in all cases or portindex will probably fail.



More information about the macports-dev mailing list