MacPorts base should verify build_arch has a sensible value

[ryandesign@…]

build_arch is meant to contain a single architecture value only. If the user sets build_arch to a nonsense value like "i386 x86_64" or "green", ports quite understandably fail to compile. (See #22534 for an example.) MacPorts base should prevent user confusion by verifying that build_arch contains a valid value. Attempting to cross-compile using build_arch is probably also a bad idea, so the valid values should probably be "i386" or "x86_64" on Intel Macs and "ppc" or "ppc64" on PowerPC Macs. We could consider allowing "ppc" on Intel Macs as well due to Rosetta.

[snc@…]

From the aspect of future architectures (atom, arm, etc) why not just make sure there are no spaces?

[snc@…]

test for space in build_arch

[ryandesign@…]

That wouldn't catch typos. I'd rather check for the four specific architectures Mac OS X currently supports. If Mac OS X supports additional architectures later, we can update the check.

[snc@…]

test for arch in list

[snc@…]

Attached is testing for the buildarch in a list of the four sensible architectures.

[snc@…]

I'm thinking we shouldn't check what architecture we're on -- as you indicated there is a blur of ppc on intel hardware through Rosetta. This will only go away in the future (and who knows, we might pick up doing ARM).

Why not simply check that they're trying to build a legit Mac architecture and leave it at that?

[rogerdpack@…]

I believe this has been resolved now. If I enter a "garbage" build_arch I get this (slightly unhelpful) error message, at least, these days:

Error: Unable to open port: can't read "my_targets(garbage)": no such element in array

[ryandesign@…]

No, this hasn't been resolved. The message about my_targets is specific to the libvpx and XviD ports, which define an array called my_targets, fill it with values for all the known OS X architectures, and then, at build time, expect build_arch to be a member of that array, thus creating the error you saw when it isn't.