On Mar 22, 2015, at 2:52 PM, David Evans wrote:
> On 3/22/15 10:35 AM, Lawrence Velázquez wrote:
>> On Mar 21, 2015, at 4:43 PM, Ryan Schmidt wrote:
>>
>>> If you use "use_configure no", you're indicating to MacPorts that this port
>>> uses something that isn't anything like autoconf, so that default universal
>>> variant goes away, and you get to program one yourself.
>> This implies that "use_configure no" overrides "universal_variant yes".
>> Would it make sense to reverse this? That is, for an explicit
>> "universal_variant yes" to create the universal variant, despite a
>> "use_configure no"?
>>
> I was thinking along the same lines.
I haven't looked too much into the universal_variant option. I know it is used
to disable the default universal variant if for some reason it does not work
("universal_variant no"). It is not unreasonable to assume that it could be
used to turn on a universal variant when a default one is not provided (i.e.
"universal_variant yes" would be equivalent to "variant universal {}"). I don't
know whether or not it works that way today. I don't have any objection to
changing it to work that way, if it doesn't already. But I also don't think it
makes much difference whether you write "universal_variant yes" or "variant
universal {}", do you?
> You could even go one step further and leave the default for
> universal_variant as yes even when use_configure no is asserted but with an
> empty universal variant and no configure (as the current port does) and allow
> the maintainer to assert universal_variant no if necessary.
>
> This would provide the same behavior as other ports (that do use configure)
> but leaves the implementation of the universal variant to the maintainer.
So many portfile authors already do not understand (probably because we have
not correctly documented it) that when you use "use_configure no", you must add
code to ensure you use the right compiler and -arch flags. Auto-enabling the
universal variant in these cases would result in a port that advertises the
existence of a universal variant which would result in non-universal software
being installed. So, it would appear to install correctly, but doesn't. The
other problems -- not using the right compiler, or not using -arch flags for
non-universal builds -- should be fixed, but will not affect most users,
because most users will not have overridden `cc` or `gcc` nor will they have
specified a nonstandard build_arch in macports.conf, so the likelihood of an
incorrect installation in those cases is much lower.
> But I haven't looked at the base code to see what's really going on and
> probably won't have time to do so for a while.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
