make percentage

[Devoter]

Сперва небольшая преамбула. Все хоть раз да собирали пакеты из исходников (./configure && make && make install), и почти все пакеты во время компиляцию выдают всяческую малопривлекательную информацию, особенно поймут меня пользователи gentoo. Да, есть всякие утилитки, типа genlop, но удобство его использования достаточно относительно.
Сама же идея состоит в следующем:
Весь вывод процесса компиляции вести на отладочную консоль или в файл, а вместо малопонятных символов выводить строку с процентом выполнения сборки пакета. И тут возникает вопрос - как же это вообще можно сделать?
На оригинальность подхода не претендую, на точность - тоже - однако смысл такой - после выполнения конфигурирования, создается Makefile (готовый), если его распарсить и определить, грубо говоря, не дискретные единицы компиляции, другими словами, в простейшем случае, разобрать на файлы, которые нужно скомпилировать. Чтоб было немного понятней, приведу пример:
Нужно скомпилировать файлы interface.cpp, widget.cpp и main.cpp, чтоб в итоге получить program.
Парсер должен определить, что необходимо скомпилировать 3 файла, для каждого подсчитать его процентную долю, то есть, где-то 33,3%. Потом надо переформировать файл так, чтобы выдавались какие-то сигналы после того, как каждая доля скомпилируется. Затем команда make на консоль будет выводить просто строку прогресса, остальное - в логи. Что касается качества данного подхода - то он не так уж и плох, если учесть, что большинство пакетов содержат достаточно большое количество отдельных модулей, а каждый модуль, в среднем, компилируется не так уж долго, то получим, что прогресс будет отображатсья достаточно точно.
Конечно, парсер должен быть достаточно сложным, потому как программы бывают написаны на разных языках, да и надо учитывать не только время компиляции исходных текстов, но и время сборки объектных файлов. Короче говоря, задача непростая. Если я не вполне ясно выразился - скажите или подправьте. Ну и интересно: если уже подобные решения (cmake, если только), и есть какие идеи по этому поводу.

[/dev/random]

Проблема в том, что задача выполнима только на этапе формирования мейкфайла. Именно так действует, к примеру, cmake.

Обратите внимание, что во многих написанных вручную мейкфайлах присутствует ручной рекурсивный вызов make внутри правил, вместо нормально оформленных зависимостей между правилами (или вместе с ними). Такой вызов может быть запрятан весьма глубоко, и обнаружить его парсером без выполнения может быть невозможно. Например, распространённый вариант: проект содержит подпроекты, и для них из мейкфайлов головного проекта вызывается ./configure && make.

Это не говоря уже о том, что бывают и весьма экзотические системы сборки, вообще не использующие мейкфайлов.

[sash-kan]

во многих написанных вручную мейкфайлах присутствует ручной рекурсивный вызов make внутри правил, вместо нормально оформленных зависимостей между правилами (или вместе с ними).

хм. даже и не знаю, как вам намекнуть.
попробую так:

Код: Выделить всё

all: config.h
        $(MAKE) $(AM_MAKEFLAGS) all-recursive

да-да, аутомыйк, он самый.

p.s. но наивность топикстартера, проистекающая, видимо, из малоинформированности, конечно, на лицо.

[/dev/random]

Код: Выделить всё

all: config.h
        $(MAKE) $(AM_MAKEFLAGS) all-recursive

Это как раз _нормальный_ пример, замечательно парсящийся и даже особым образом распознаваемый самим make.
Я имел в виду что-то вроде этого:

Код: Выделить всё

.PHONY: configure-build-libiberty maybe-configure-build-libiberty
maybe-configure-build-libiberty:
@if gcc-bootstrap
configure-build-libiberty: stage_current
@endif gcc-bootstrap
@if build-libiberty
maybe-configure-build-libiberty: configure-build-libiberty
configure-build-libiberty:
        @: $(MAKE); $(unstage)
        @r=`${PWD_COMMAND}`; export r; \
        s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
        test ! -f $(BUILD_SUBDIR)/libiberty/Makefile || exit 0; \
        $(SHELL) $(srcdir)/mkinstalldirs $(BUILD_SUBDIR)/libiberty ; \
        $(BUILD_EXPORTS)  \
        echo Configuring in $(BUILD_SUBDIR)/libiberty; \
        cd "$(BUILD_SUBDIR)/libiberty" || exit 1; \
        case $(srcdir) in \
          /* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
          *) topdir=`echo $(BUILD_SUBDIR)/libiberty/ | \
                sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
        esac; \
        srcdiroption="--srcdir=$${topdir}/libiberty"; \
        libsrcdir="$$s/libiberty"; \
        rm -f no-such-file || : ; \
        CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
          $(BUILD_CONFIGARGS) --build=${build_alias} --host=${build_alias} \
          --target=${target_alias} $${srcdiroption}  \
          || exit 1
@endif build-libiberty

[sash-kan]

замечательно парсящийся
…
Я имел в виду что-то вроде этого

что-то не пойму, чем «$(MAKE)» парсится хуже «$(MAKE)».

особым образом распознаваемый самим make

нельзя ли поподробнее?

[/dev/random]

замечательно парсящийся
…
Я имел в виду что-то вроде этого

что-то не пойму, чем «$(MAKE)» парсится хуже «$(MAKE)».

Тем, что:
* $(MAKE) может быть окружена if'ами (как здесь). Их значение может быть неизвестно на этапе вычисления количества правил для расчёта процентов.
* $(MAKE) может быть выполнена в цикле по списку файлов, не заданному в мейкфайле, а определяемому на этапе выполнения.
* Может вообще запускаться внешний скрипт, вызывающий make (хотя такого извращенства я а практике ещё не встречал)
* Ну и т.д.

особым образом распознаваемый самим make

нельзя ли поподробнее?

Секция info make 'MAKE variable'

[Devoter]

Не отрицаю, с Makefile'ми знаком на базовом уровне, но не могу понять, почему, например, нельзя попытаться имитировать выполнение всех мейков, только не вызывать реально gcc и make, а парсить глубже. Понимаю, что не везде осуществимо, но речь и не шла о 100%-ом качестве метода. Все же лучше, чем ничего.

[Portnov]

почему, например, нельзя попытаться

Можно, разрешаю.