invisible universal variant and merger_must_run_binaries

[Ryan Schmidt]

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?