[MacPorts] #47790: pstree: update to 2.39 2.39)

[Ryan Schmidt]

> On Jun 8, 2015, at 7:32 AM, Jan Stary wrote:
> 
> On Jun 08 14:27:33, hans at stare.cz wrote:
>> On Jun 08 02:32:01, noreply at macports.org wrote:
>>> #47790: pstree: update to 2.39
>>> ---------------------+----------------------
>>>  Reporter:  hans@???  |      Owner:  mww@???
>>>      Type:  update  |     Status:  closed
>>>  Priority:  Normal  |  Milestone:
>>> Component:  ports   |    Version:
>>> Resolution:  fixed   |   Keywords:  haspatch
>>>      Port:  pstree  |
>>> ---------------------+----------------------
>>> Changes (by ryandesign@???):
>>> 
>>> * status:  new => closed
>>> * cc: ryandesign@??? (added)
>>> * resolution:   => fixed
>>> 
>>> 
>>> Comment:
>>> 
>> I've updated pstree to 2.39 in r137283, but I haven't made all the changes
>> you proposed, because many of them are regressions.
> 
> Thanks.
> 
>> For example, pstree does not install any libraries, and it correctly
>> indicates this via the line `installs_libs no`, but your patch removes
>> this line. There are no ports that depend on pstree, so it doesn't really
>> affect anything, but since the port maintainer has already gone out of his
>> way to indicate that the port does not install libraries, there's no
>> reason to remove this indication.
> 
> Are the ports that install no libraries supposed to say so?
> From the top of my head, there are many ports that don't.
> Maybe I am missing something, but shouldn't the ports that _do_ install
> libraries explicitly say so, with 'installs_libs no' being the default?
> (And if 'installs_libs no' _is_ the default, why have it in the Portfile?)

installs_libs defaults to yes. It was introduced to MacPorts fairly recently, within the past few years, so there are probably many ports that should set it to no that don't. These ports should be fixed.

Setting installs_libs no help when another port depends on this port. When a port declares that it installs no libraries, MacPorts knows that that port's license needn't be examined to determine if a port is distributable. No ports depend on pstree so it doesn't exactly matter in this case. However, it is still better to indicate it. Maybe future versions of MacPorts will use this information in other ways.


>> The existing configure script records the values of the CC, CFLAGS and
>> LDFLAGS variables into the Makefile and uses them at build time, which
>> means it's UsingTheRightCompiler and `-arch` flags. Your proposed change
>> doesn't do any of this, so a wrong compiler might be used, and the build
>> will always use the compiler's default architecture even if the user
>> requested something different.
> 
> Please excuse my ignorance: how does a macport user specify, say,
> the exact CC to use when installing a port?

It's less about accommodating users who want to change the compiler; that's not supported though it can be a useful diagnostic tool. It's more about ensuring that if a user has selected a different compiler for their own use at the command line (using "sudo port select gcc"), that compiler selection does not bleed into ports, which it would have with your proposal. The UsingTheRightCompiler wiki page explains in more detail.


> The provided Makefile
> then also uses the specified CC and CFLAGS and build time, right?

But the port didn't specify any values for CC and CFLAGS to pass to the Makefile at build time. (MacPorts only provides values for these at configure time.)


>> The README should still be installed, even if there is also a manpage.
> 
> Why?

Discoverability. Some users may look for manpages, others may look for readmes. By providing both, both types of users are satisfied.