| Summary: | [Future EAPI] Support for multiple log (output) streams | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Michał Górny <mgorny> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | esigra |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
Not worth the effort. |
The distutils-r1 eclass recently started running phases for multiple implementations in parallel. This results in hard-to-debug, mixed output. Therefore, it started writing split output to additional log files in ${T}. Now, PMS doesn't provide any good way to point the user to those logfiles in case of failure. And the output is still quite ugly, with user being forced to tail the log files to e.g. get a better py.test output. Therefore, my idea is to provide a common mechanism for establishing multiple log streams from ebuild. For example, we provide a function like: log_open <var> <filename> [<title>] which: a) establishes a new log stream which will be written to ${T}/${filename} and output to the user at the same time, b) makes PM aware of it (under the title ${title} if provided), c) stores the new (next free) fd in var. In the simplest implementation, it would perform a task similar to 'tee', and provide the list of open logs in the die message. In a more complex one, it could also use curses to display the logs on split-screen.