On further thought, I assume this issue actually hits everyone - it's
not just Ninja getting in the way, but lit as well. (which also means
we'd probably need to fix both Ninja and lit to resolve this issue -
but everyone should at least be a little invested in fixing lit).
On Sun, Jan 6, 2013 at 12:18 AM, Sean Silva <silvas at purdue.edu>
wrote:> Nope. An easy solution (both here and for clang) is for ninja to set
> an environment variable (`NINJA_ISATTY`?), and add some magic to
> LLVM's "isatty" to return true if it sees it.
I'm a little unsure what you mean by "LLVM's 'isatty'"
- isn't that
just a system call LLVM would be making? (I suppose we probably have a
wrapper somewhere to handle platform-specific issues, maybe that's
what you're referring to)
> (for matters of correctness, it would actually be best if ninja sets
> the environment variable only when *it's* stdout/stderr isatty (also
> taking into account this environment variable), so that everything
> works "as expected" if you pipe ninja itself to a file or
recursively
> invoke ninja for some reason)
Sure enough. For all I know Ninja may already have something that
indicates this that we just need to leverage. (& potentially use as
inspiration for fixing lit too).
- David
>
> -- Sean Silva
>
> On Sun, Jan 6, 2013 at 1:16 AM, David Blaikie <dblaikie at gmail.com>
wrote:
>> I'm just wondering if anyone's using Ninja (which buffers
output from
>> subcommands, such as lit/FileCheck/etc) & has thought about/found a
>> way to force FileCheck to use colour in spite of Ninja's buffering.
>>
>> Thanks,
>> - David
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev