оно еще есть разве?

ну, как сейчас - не знаю

давно не смотрел

Да, можно и не в оперативке. Т.е хранить все эти вещи которые рассчитываются и не пересчитывать.  Всё это так или иначе просто подстава аргументов в компилятор, сгенерировать это один раз. Когда новые, то просто писать поверх. Ладно новые пересчитывать, для пакетов которые создают конфликты и тд. Но скажем ты обновляешь те же самые пакеты, то просто берётся прошлый результат и подставляется для компиляции новых исходников

окей, но нахера ему читать ебилды для просчета зависимостей, это ж лежит в edb

одно писали и не дописали, другое писали люди которые ни в architect ни в математику

а ты уверен, что ты видел read(), а не stat()?

я видел куски текста ебилдов

@mva_name ты думаешь я не писал портагодевам чо не так с портагом? :)

это было год назад и на винте с 20Мб/с потолок

emerge -- не компилятор! Мы о проблеме ДО компиляции, ДО выбора пакетов

например, чтобы экспандить PYTHON_COMPAT=python3_{6,7,8}

Так почему бы не держать дерево flag=options. Что бы на стадии выбора пакетов, просто не сгенерить список, и не подставлять тупо

так, сходи посмотри сколько всего лежит в /var/db/pkg

Зачем это ебучее дерево

интересно, а можно идею ccache применить для решателя зависимостей?

Ну сколько, не сотни тысяч же

так, а оно не хранит это сохраненным отдельно? как HOMEPAGE/SRC_URI, там тоже часто шелл-интерполяцию юзают

я тебе к тому, что посмотри сколько всего портаж УЖЕ сохраняет и кеширует

у того же apt/dpkg есть /var/cache/apt/pkgstate.bin или что-то такое, так вот, после его удаления первый запуск aptitude идёт дольше. Построение кэша зависимостей вроде бы.