colorgcc perl скрипт с выходом в не-tty включен запись в файлы зависимостей C

Хорошо, вот моя проблема. Я написал сценарий сборки в bash, который выводит выходные данные в tee и сортирует разные выходные данные в разные файлы журнала (поэтому я могу суммировать ошибки/предупреждения в конце и получить некоторую статистику по построенным файлам). Я хотел использовать сценарий colorgcc perl (colorgcc.1.3.2), чтобы раскрасить выход из gcc и нашел в других местах, что это не будет работать конвейер в тройник, так как скрипт проверяет, если он пишет на что-то, что не является tty.Отключив эту проверку, все работало, пока я не сделал полную сборку и не обнаружил часть кода, который мы получаем из другой группы, строит файлы зависимостей C (мы не контролируем этот код, изменение его или процесс сборки для них на самом деле не вариант).

Проблема в том, что эти .D файлы имеют следующий вид:
filename.o filename.d : filename.c
dependant_file1.h
dependant_file2.h (and so on for however many dependencies there are)


Этот вывод из GCC записывается в.D файл, но, так как он достаточно близок к предупреждению/сообщению об ошибке colorgcc выводит цветовые коды (считаю, что это проверка Дляfilename:lineno:message, но не на 100% уверен, может быть filename:messageпроверить в то GCCOUTвремя как цикл). Я пытался отредактировать regex, чтобы попытаться не соответствовать этому, но мой perl-fu, по общему признанию, довольно слаб. Таким образом, в конечном итоге я получаю цветовой код в каждой строке для этих файлов зависимостей, что, очевидно, приводит к сбою сборки.

В итоге я просто заменил check for ! -t STDOUTна check for a NO_COLOR envar, который я установил и снял в скрипте сборки для этих каталогов (эмулирует предыдущее поведение no color для non-tty). Это отлично работает, если я запускаю полный сценарий, но не делает, если я cd в каталог и просто запустить make (очевидно, установка и сброс вручную будет работать, но это боль, чтобы сделать каждый раз). У кого-нибудь есть идеи, как предотвратить написание цветовых кодов в файлы зависимостей?

1 ответ

  1. Вот как я с этим справился. Я добавил следующее К colorgcc для поиска ввода gcc для флага для создания .d файлов и просто непосредственно вызвал компилятор в этом случае. Это было вставлено вместо оригинальной проверки TTY.

    for each $argnum (0 .. $#ARGV)
    {
    if ($ARGV[$argnum] =~ m/-M{1,2}/)
    {
    exec $compiler, @ARGV
    or die("Couldn't exec");
    }
    }

    Я не знаю, является ли это правильным «perl» способом выполнения такого рода операции, но это, кажется, работает. Компиляция внутри каталогов, которые строятся .D файлы больше не вставляет цветовые коды и сборки исходного файла делают (как терминал и мои файлы журнала, как я хотел). Я думаю, что иногда ответ больше хаков вместо » Эй, вы пытались сдаться?».