[distcc] Getting distcc errors to the user

[Martin Pool]

On  3 Apr 2003, Wayne Davison <wayned at users.sourceforge.net> wrote:
> It was noted earlier that some distcc errors can get cached by ccache in
> its stderr cache file that should really not be saved (e.g. if a host is
> down and a command was run locally).  I was wondering if distcc should
> attempt to open up /dev/tty as the destination for these transient
> errors?  (If that fails, it could fall-back to using stderr.)
> 
> Another possibility (that Martin mentioned) is to have ccache somehow
> make the original stderr file-handle available to the "compiler" that it
> runs (distcc, in this case).  Martin: how were you imagining this
> working?  Would ccache set an environment variable to let distcc know
> about the alternate stderr variable (i.e. "REAL_STDERR_FD=3")?

Yes, like that.  ccache would do something like dup(2) to create it
pointing wherever stderr was before it was captured.

> The choice is interesting.  Opening /dev/tty has the advantage that it
> works without changing other programs (ccache or whatever else may come
> along).

> It also avoids putting the transient errors into some
> redirected output file where the user might not see them (e.g., if I run
> "gcc ...  2>errors", it would be nice if the "errors" file didn't
> contain the distcc warnings).

I disagree; I think they should go to stderr.  

If they want the errors somewhere else they can set DISTCC_LOG.  It
can even be set to /dev/tty if you really want.

> On the other hand, there might be times that this idiom would cause
> problems.

I think it will cause more problems than it solves.

I would prefer to, if we can detect we're being cached, always write
to distcc.log.

If tridge refuses to take a patch to ccache then I guess we can think
about it again.

Thanks for your thoughts
-- 
Martin