port message

Bradley Giesbrecht brad at pixilla.com
Fri Jan 8 20:52:48 PST 2010


On Jan 8, 2010, at 8:31 PM, Ryan Schmidt wrote:

>
> On Jan 8, 2010, at 20:36, nox wrote:
>
>> At the core, portfiles are TCL scripts. And excluding anything  
>> except ui_msg, any called procedure except ui_msg would be to  
>> transformed into a no-op. This can't be done at runtime, and we  
>> can't possibly write a list of those procedures. So your idea is  
>> unrealisable.
>
> Maybe not in the form he suggested, but it would certainly be  
> possible to modify ui_msg so that in addition to printing a message,  
> it keeps it in an array, and prints them again at the end if in  
> debug mode.
>
> But I think we may be trying to solve the wrong problem. MacPorts  
> 1.9.0 will introduce logging, so I think this makes most of the  
> reasons one would use debug mode go away. The problem is not  
> "There's too much information in debug mode and I can't see the  
> stuff that's relevant to me"; the problem is "We ask users to run in  
> debug mode." With logging, we no longer need to ask users to run in  
> debug mode. So do we then really still need to change how messages  
> are printed?

When I'm working updating or creating a new portfile I use -v pretty  
much all the time because if something fails I want to see what stop  
me. So I almost always have to much output to see the ui_msg. It's the  
deps that I find a pain. Trying to look through the whole deps chain  
to see if there is anything I should do after install is not smooth.

Collecting into an array was my original suggestion months back and I  
think in -v or -d mode could be useful. I don't see how this could be  
all that difficult to do but things work the way they are so I'm not  
complaining. I thought if enough other people liked the idea it might  
return value to put a little time into collecting the ui_msg to print  
at end.

Let's all move along, we have better things to do.

// Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20100108/b172eaf9/attachment.html>


More information about the macports-dev mailing list