Is it worth persevering with Macports_Framework?

[Jordan Hubbard]

On Feb 14, 2013, at 12:46 AM, Rainer Müller <raimue at macports.org> wrote:

> The message classification currently happens through a handful of procs
> such as ui_error, ui_warn, ui_msg, ui_notice, ui_info, ui_debug. These
> add the prefix for errors and warnings and decide whether to print the
> message at all based on the verbose, debug or quiet flag, -v -d -q,
> respectively.

Right, that part is already well-segregated and easy to extend.  I think Ian's more concerned with:

> Yep. I think port(1) is quite good in that respect already, but messages arising from
> builds are not.  Port(1) puts "--->" and "Error:" prefixes on key lines of  output.

Which would actually be somewhat more difficult, but not at all impossible, to wrap.  Given that all of MacPorts' phases eventually invoke a known set of pre/post/action hooks, which can themselves (and frequently do) call system() and other process execution primitives, it seems the easiest thing to do would be to (in the "wrapper" case only) invoke any and all hooks with one level of sub-process interaction at the end of a pipe or pty.  That sub-process can then do whatever sub-process invocation of its own it likes and you don't need to care, you just read off the other end of the pipe/pty and decorate the output as appropriate for that particular phase.   I say "pipe or pty" since I'm not sure if a pipe would catch any and all types of subprocess I/O, but it probably would (and would be a lot simpler than doing the PTY allocation) so I'd try that first and just keep PTYs as a fall-back idea.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130219/983720f5/attachment.html>