Как я могу определить неудачную команду при использовании make -j
При использовании make -j в файле со многими целями, когда одна из них терпит неудачу, может быть немного сложно определить конкретную команду, вызвавшую ошибку. Особенно, когда на выходе много.
Могу ли я убедить gnu make напечатать что-то вроде этого (желательно в конце вывода):
This particular command failed: "frobniz -foo" with output "frobniz only takes -foo options on a thursday"?
На данный момент я прибегаю к использованию make -j -Otarget внутри tmux с его историей поиска, чтобы я мог найти этот «неудачный» вывод:
Makefile:41: recipe for target 't4' failed
Увы, цель 't4' имеет около 40 команд с большим количеством выходных данных, поэтому мне нужно больше искать, чтобы найти реальную команду, которая не работает. Это управляемо, но чувствует себя неуклюжим.
Я тоже пробовал remake, но у него вроде нет вариантов для этого.
Обновлено: Очевидно, я должен был поместить здесь некоторый код, позвольте мне исправить это; Это одна цель из 16, каждая из которых имеет около 40 команд. Пример Ниже были сокращены до 4 команд.
t4:
sso -dump FAIL:B -path /instadm-bin/ktkopdat.start -ttarget "AA" ht1
sso -dump FAIL:B -path /instadm-bin/ktknyadm -ttarget "BB" ht1
sso -dump FAIL:B -path /instadm-bin/multiadm -ttarget "CC" ht1
sso -dump FAIL:B -path /instadm-bin/ktkslet.start -ttarge "DD" ht1
Допустим, я запускаю make -j, а вторая строка выше не работает. Сбой и команда видны в выходных данных make, но смешаны с большим количеством других выходных данных.
Что make выполняет для генерации ошибки: sso -dump FAIL:B -path /instadm-bin/ktknyadm -ttarget "BB" ht1 - происходит сбой со статусом -1.
Теперь make должен знать, какая команда завершилась неудачно, поскольку в этот момент он может прервать процесс. Эта информация очень ценна для меня, но тем не менее она скрыта в мешанине вывода множества параллельных процессов. Обратите внимание, что я мог бы, конечно, перезапустить make без опции -j, чтобы необходимая информация отображалась внизу вывода, но я бы не хотел повторять длинную сборку больше раз, чем необходимо.
Ответы 1
Я не уверен, что вы подразумеваете под 40 команд с большим количеством вывода. Было бы полезно, если бы вы привели пример.
Если вы имеете в виду, что у вас есть 40 логических строк рецепта (без использования обратной косой черты для объединения 40 физических строк в одну логическую строку), то, как только одна из этих команд завершится ошибкой, make прекратит сборку этого рецепта и больше не будет запускать команды, поэтому неудачная команда всегда будет последней.
Если вы имеете в виду, что у вас есть длинный сценарий оболочки, состоящий из 40 физических строк, объединенных в одну логическую строку с использованием точек с запятой и обратной косой черты, то make не может вам помочь, потому что make не знает, какая команда завершилась неудачно.
Make вызовет один экземпляр оболочки и передаст этой оболочке всю строку логического рецепта, а затем дождется выхода оболочки с кодом выхода 0 или не-0. Если код выхода равен 0, make предполагает, что рецепт выполнен успешно; если код выхода не равен 0, make предполагает, что рецепт не удался. У make нет способа узнать, было ли вызвано более одной команды, какие команды были вызваны, какие из них могли завершиться неудачей, какие из них выдали какой вывод и т. д. Вся эта информация известна только оболочке, а не make.
Использование -O — единственное, что может помочь вам сделать это проще, сохраняя выходные данные и команду вместе. Вам все равно придется вернуться к выводу, чтобы найти неудачную команду. В GNU make нет средства, которое бы "обобщало" ошибки в конце прогона. Обратите внимание, что make в настоящее время не имеет возможности сохранить вывод команды: обычно он не сохраняет вывод команды. Можно добавить новую функцию для сохранения вывода ошибок при использовании -O.
Извините, я был неясен. Я отредактировал, чтобы уточнить. Я имел в виду 40 строк логических рецептов, и, как вы упомянули, неудачная строка остановит создание этой конкретной цели. Но в это время выполняется много других целей (из-за опции
-j), поэтому неудачная команда редко будет падать на дно.