[134288] trunk/dports/sysutils/pidof/Portfile

[Ryan Schmidt]

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.