Когда Kbuild/Kconfig перепишут на meson?

Где при сборке ядра _необходим_ питон?

Про какие скрипты на питоне в ядре ты говоришь?

... но для этого предварительно нужно ядро собрать, на что могут уйти часы.

Ты на i386 собираешь? :)

Даже во времена 1.3.20 на i386dx40 c 8Mb RAM ядро собиралось порядка 40 минут, правда на 4Mb RAM оно собиралось часа 3 или 4.

Завязка на питон сборки ядра - неразумная идея.

Переписывание напоминает процесс колоризации старых фильмов.

Где при сборке ядра необходим питон?

Я не утверждал, что он необходим для сборки. Но в 5.10.7 сейчас 118 *.py файлов.

Ты на i386 собираешь? :)

Нет, но у меня на Void пакет с ядром собирался где-то 5 часов при включенной параллельной сборке. Но комп слабый, да.

Завязка на питон сборки ядра - неразумная идея.

Ну, рекурсивную сборку на Makefile вряд ли можно назвать более разумной идеей.

Я не утверждал, что он необходим для сборки. Но в 5.10.7 сейчас 118 *.py файлов.

Это все тулзы, которые в сборке не используются.

И половина из них хочет питон2, а другая питон3.

find -type f -name \*.py|xargs head -3| less

make -j99 на дохлой машине будет работать дольше чем сборка в 1 поток.

Сборка не рекурсивная. Она отражает структуру каталогов. Древовидная структура каталогов тебе кажется неразумной идеей? Ты видать с RT-11 никогда не работал :)

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

Поставь себе ccache и пережди одну сборку. Тебе же не нужно эти часы сидеть за компом и смотреть, пока он работает. Если понадобится ядро снова собрать, с кешем будет уже намного быстрее, в районе единиц минут, если не десятков секунд.

Можешь ещё попробовать заменить gcc на свой скрипт-пустышку, который не делает ничего.

Я не понимаю, почему meson до сих пор не переписали на Си, плюсах или расте. Или были попытки?

Нет, наоборот cmake вкорячили в pip.

А кэш этот не может создать проблем?

Я знаю, что compile_commands можно создать с помощью scripts/clang-tools/gen_compile_commands.py, но для этого предварительно нужно ядро собрать

Что проще - улучшить 1 небольшой скрипт, или отрефакторить стабильно и хорошо работающую билд систему гигантского проекта, к которой привыкло тысячи людей и роботов?

Завязка на питон сборки ядра - неразумная идея.

А завязка git на perl вас не смущает?

Нет. Не смущает. В perl-e уже давно нет революционных изменений.

Новость была, уже скоро, в 2031 году прекратят поддержку Perl5 и будет лишь Perl7 с немного поломанной совместимостью.

При чем тут cmake

Сможет.

Завязка на питон сборки ядра - неразумная идея.

Можно рядом с конкретной версией ядра класть уже сгенерированный мезоном build.ninja/ms project/make файл

Рано - мезон слишком быстро развивается. Надо подождать годика два.

И половина из них хочет питон2, а другая питон3

Да, притом что третий давно уже вышел. Могли бы уже к одному виду всё перевести.

Сборка не рекурсивная.

Разве? Давно я не смотрел, как там сборка устроена. Но если они правда устранили рекурсию, то без костылей явно не обошлось.

Ты видать с RT-11 никогда не работал :)

Так когда она вышла и использовалась, я еще не родился:)

Поставь себе ccache и пережди одну сборку

Про ccache знаю, но это не поможет, если поменять конфиг. Ведь сгенерированный конфиг.h неявно подключается в кучу файлов, так что толку от ccache…

Можешь ещё попробовать заменить gcc на свой скрипт-пустышку

О, не додумался до этого. Потом проверю, сейчас не у компа.

Что проще - улучшить 1 небольшой скрипт, или отрефакторить стабильно и хорошо работающую билд систему

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

класть уже сгенерированный мезоном build.ninja

Он будет разным в зависимости от конфига ядра, так что не вариант.

но это не поможет, если поменять конфиг

Ты конфиг по пять раз на дню менять собрался?

Да, было бы неплохо.

Не на отрыжку CMake же Linux переводить.

заменить gcc на свой скрипт-пустышку, который не делает ничего

Не, это так просто не сработает, ведь ещё нужно .o.d файлы генерировать.

А не хочешь сам meson переписать на Си?

Уже начал. Пока только парсер реализовал.

Держи в курсе ;)

Meson не умеет более одного тулчейна в одном проекте. А в процессе сборки ядра используется два компилятора, CC и HOSTCC.

Удивительно но факт. Make и ninja не имеют ограничений на применяемые в сборке компиляторы, а cmake и meson имеют.

Умеет. Можно запускать родной и кросс-компилятор в одном проекте.

См. https://mesonbuild.com/Cross-compilation.html

– Mixing host and build targets

Недайбох.