BUG: the default +universal variant shouldn't appear in ports where we know it won't work

[ryandesign@…]

This is a follow-up to #12137 in which I experienced this problem:

$ sudo port install glitz +universal
Error: Error executing universal: Default universal variant only works with ports based on configure
Error: Unable to execute port: Error evaluating variants

Turns out it's not complaining about the glitz port, which does use configure, but rather about the XFree86 port, which doesn't use configure. I'm not even using XFree86; I'm using Apple's X11.

I worked around the problem for XFree86 by removing its +universal variant in r26296, since it was nonfunctional anyway, but the fundamental problem remains: MacPorts made the default +universal variant available to XFree86, although we already know the default +universal variant only works with ports that use configure. I say that, for ports that say "use_configure no", MacPorts shouldn't give them the default +universal variant. This would have avoided the problem I experienced.

[eridius@…]

Duplicate of #12169, which you filed 4 minutes prior. WTF, man?

[ryandesign@…]

Not a duplicate of #12169, though I did copy and paste the initial paragraphs. The situation from #12137 is the catalyst for filing both for #12169 and this bug, but they are separate bugs which require separate solutions. This issue is for the fundamental problem in base the universal variant is given to ports for which we should already know that it won't work, which caused the problem I experienced in #12137, which could have been avoided if base were more selective about which ports it makes the universal variant available to.

[ryandesign@…]

Currently, when users use "port info foo" they will see a universal variant available for most ports. Users may rightly assume that this means that they can use +universal to build the port, but this will fail and annoy them if the port does not use configure. This will be even more noticeable to users who add +universal to their default variants. Basically, +universal is broken by default for ports that do not use configure. My request in this ticket is to fix this so that "universal" does not show up in "port info foo" if the port says "use_configure no".

[jmpp@…]

Milestone Needs developer review deleted

[jmr@…]

The attached patch avoids defining a universal variant in the cases where it won't work, instead of making a variant that throws an error. Nominating this for the upcoming release.

[jmr@…]

Sorry, the patch doesn't work properly. Should have known it would already have been done if it were that easy.

[jmr@…]

OK, new patch attached, which seems to do it right. If there are nicer ways to achieve what it does, I'm all ears.

[raimue@…]

Instead of platform_is_macosx, can't you use this?

if {[info exists variations(macosx)] && $variations(macosx) == "+"}

I don't like duplicating this check.

[jmr@…]

Replying to raimue@macports.org:

Instead of platform_is_macosx, can't you use this?

if {[info exists variations(macosx)] && $variations(macosx) == "+"}

I tried that, but it didn't seem to work. I think the variant isn't set any more at that point if the portfile doesn't contain a platform macosx block.

[jmr@…]

proposed fix

[jmr@…]

Patch updated: replaced the redundant platform_is_macosx procedure with a new os.universal_supported variable, and deleted an unreachable error condition from the universal variant.

[jmr@…]

Patch is working well in my testing. Committed to trunk in r36764. Leaving this ticket open until the patch is merged into the 1.6 branch, or retargeted to a later release.

[jmr@…]

Marking fixed since 1.6.1 has turned into 1.7.