[82233] trunk/dports/python/py-bdist_mpkg/Portfile

[Ryan Schmidt]

On Aug 10, 2011, at 22:01, Joshua Root wrote:

> On 2011-8-11 12:24 , Ryan Schmidt wrote:
>> 
>> Why don't you just set "python.link_binaries yes" and let the portgroup do it for you? Even better question: why doesn't the portgroup do this automatically? My understanding was that link_binaries was a feature added to the python26 portgroup that nobody ever bothered backporting to the python25 and python24 portgroups, but with the new unified python portgroup, why have we taken a special effort to duplicate that deficiency?
> 
> What would it link to? That's the only place the executable exists.

....I see. And the reason this is different in python26 and up is that they do a framework build, so the unprefixed binaries go into a version-specific directory, so there's no problem. Whereas with python25 and earlier the unprefixed binaries go directly into ${prefix}/bin so they need to be renamed.

I still hate to see code like this having to be added to each unified python port:

On Aug 10, 2011, at 19:49, jmr at macports.org wrote:

> +    if {${python.version} == "24" || ${python.version} == "25"} {
> +        post-destroot {
> +            move ${destroot}${prefix}/bin/bdist_mpkg \
> +                 ${destroot}${prefix}/bin/bdist_mpkg-${python.branch}
> +        }
> +    }

Portgroups are supposed to handle redundant tasks for us. What about if it would [glob] everything in ${destroot}${prefix}/bin and suffix it (if ${python.link_binaries} is yes and ${python.link_binaries_suffix} is nonempty)?

I guess the names of the options don't make sense then, for what they'd be doing.