On Feb 2, 2021, at 11:18, Ken Cunningham wrote:
> One port needed +universal has some tricks in it, and requires
> "merger_must_run_binaries". That port cannot be built universal on an Intel
> system (which can't run arm64) but can be built universal on an arm64 system
> (which can run Intel).
Ideally of course the port would be fixed so that it can build on any system.
The problem only occurs when using the muniversal portgroup, so investigating
removing the portgroup is one possibility, though of course the portgroup
exists to solve a certain type of problem and that may be needed for that port.
Parts of the build that only need to be run on the build machine should be
built for the build machine's arch. For example, not using -arch flags when
building those parts would do it. Of course if the parts that will be run
during the build will also be installed, it's trickier. Since the muniversal
portgroup builds multiple times, once for each arch, you may be able to modify
the build so that it uses the version of that program that was built for the
machine's build arch. This would require that the build for the machine's build
arch happen before the build for foreign archs; I don't know if the muniversal
portgroup currently arranges for that to be the case, but if not, that would be
a good improvement to make there.
> Joe Schmoe on BigSur Intel could download and install that port +universal,
> and be on his way.
>
> But now, his system will never see that port could be universal (because he
> can't built it universal), and the chain collapses, some would say needlessly.
Josh recently made changes to how universal is handled in MacPorts, so I'm not
sure how much of your question is related to that. But if "his system will
never see that port could be universal" then how could he "download and install
that port +universal" in the first place?
