Fwd: Build Failure: (from, 10.6, OS, This, X, builds, configure.compiler=macports-gcc-4.7, newer, on, only, and 6 more

[Clemens Lang]

On Sun, Dec 11, 2016 at 02:28:14PM +0100, René J.V. Bertin wrote:
> > A Portfile should not should not print anything in response to it
> > simply being opened. (Think about it, does a user really want to see
> > this message whenever they run 'port info'
> 
> Yes they are supposed to! Cf. #52981

No, you even said that in the ticket:

"""
the information shouldn't be printed unconditionally because then it
most certainly would show up at inappropriate times like when running
portindex
"""

Your change made the information show up at an inappropriate time.
Remember that even though a user runs 'port info', they might limit the
output of that, e.g. using 'port -q info --line --subports'. There is no
way to get this right from a Portfile; you must declare the information
you want to be printed in a field and implement support for printing
this field in the port client, rather than attempting to hack around
this in the Portfile.

> This message should ideally be delivered before a user starts trying
> to install the port, or else when a build failure occurs.

Two options:

1. Modify port(1) to print notes before installation of a port
2. Add the information to the long_description of a port, which will be
   visible on 'port info'.

> > The script that finds out which subports exist has to open the port
> > to do so, and prints the list of subports to stdout.
> 
> but why would it consider the output from a ui_msg statement as a list
> of subports? It's never done that for me, and I'd call that a bug, no
> matter how not-done it is to use ui_msg in a port's common code.

Because it runs 'port -q info --line --subports' and parses the result.
The flags to info guarantee that only the list of subports is printed.
You violate this assumption by printing more output in ports. Don't.

-- 
Clemens