Подготовка к 40-летию проекта GNU

При том что Autotools просто ./configure && make

В gmake нет нормального синтаксиса и без костылей и обвязок ты им проект сложнее hello world не соберёшь. autotools уже не make, а куча обвязок, мейкфайлы сгенерированные автотулзом непортабельные и работают только на паре с вызовом configure, да и нечитаемые.
Использовать же gmake напрямую можно, но даже банальный вынос каталога сборки в другой каталог окажется несовместим с gcc dependency tracking и придётся использовать костыли с awk чтобы это исправить. В итоге придётся или срать объектниками в каталог исходников, или отказываться от трекинга зависимостей хидеров и трекать только .c/.cpp

Так можно же сделать переменную:

src=src

main.o: $(src)/main.c
    $(CC) $(CFLAGS) $(src)/main.c -c -o main.o

Всё ок пока не хочешь добавить автоматический трекинг изменившихся .h файлов. У gcc нет опции чтобы добавить префикс пути туда, потому приходится это .d файлы патчить

А что такого, что он использует autotools?

Что замучаешься его собирать с необходимыми параметрами или добавлять поддержку новой платформы.

А по багам - не субъективно ли?

Когда я занимался поддержкой архитектуры RISC-V в Haiku, я столкнулся с множеством багов кодогенерации GCC, при этом если тот же код собрать с Clang то проблем не было. Примеры багов: некорректные смещения переходов если используется relax и symbol versioning, frame pointer иногда указывает не туда, битый код обращения к абсолютному адресу MMIO, не работает присваивание указателя на функцию из одной константной структуры в другую.

Возьми любой не самый свежий дебиан.

Превозмогаем трудности которые сами сделали. Может лучше подключить репозиторий с новыми пакетами? Или на крайний случай в Docker запускать?

я столкнулся с множеством багов кодогенерации GCC, при этом если тот же код собрать с Clang то проблем не было.

У меня было с точностью до наоборот: пару недель назад компилировал ядро 6.3. Собранное с clang 16 не грузилось.

Возможно, что в очередном rc ядра что-то исправили, пока не проверял.

При том что Autotools просто ./configure && make

Это если используется дистрибутив и архитектура предусмотренная авторами Autotools и собираемой программы. Если нет, то начинается сущий ад.

У меня было с точностью до наоборот: пару недель назад компилировал ядро 6.3.

Там же GCC-змов полно, так что не удивительно. Этот говнокод без -O2 и выше вообще не запускается. О стандартах Си там вообще не слышали.

То есть, это не clang виноват, что запутался в «GCC-змах», так?

Ага, за 40 лет некоторые вещи заменили, ну да, годы идут.

во всех случаях где была такая проблема эти решения были в той или иной мере неприменимы, а необходимость ставить целое другое окружение из-за того что cmake никак не могут доделать - лишь подтверждает что cmake говно. У меня цель была собрать приложение под эту систему, а не построить другую для него. cmake для такого подходит как выяснилось плохо, autotools хорошо.
Однако допустим, целью было бы только запустить приложение. Есть некая система, редкая, вероятно заброшенная, с ограниченными ресурсами, то есть собирать cmake там будет тяжко. На которой всё работает. Это может быть старая необновляемая vpsка с 5-10гб места и 512мб рамы, может быть старенький планшет/телефон с портом какого-нибудь линукса туда (Linux4Tegra, sailfish, maemo, meego дв или просто линукс в chroot) который ради этого обновлять, переносить на современную базу будет трудозатратно. На те же тегры например иксовые дрова привязанные к версии иксов и ломающиеся от даже минорных обновлений иксов. Запустить софтину в chroot/docker? На докер не хватит поддержки в ядре и места, на chroot просто места, в chroot придётся отдельно заводить opengl и прочее, если это вообще возможно, в случае всяких libhybris это не обязательно вообще возможно

Или кто-нибудь взял флешку с линуксом, а там какая-нибудь 16-18 убунта и ворчит что мой софт не работает - да, можно сказать - «поддерживать не будем», но это опять лишь скажет о cmake как о плохом инструменте. Если уж на то пошло и cmake хочет быть таким стандартным - так пусть станет стандартом который не будет ломаться каждые пару лет

Возмите тот же самый старый Debian в виртуальной машине и соберите там небходимый софт. Или кросскомпиляцию использовать.

в виртуальной машине

Может ещё в потактовом эмуляторе? Зачем так извращаться?

соберите там необходимый софт

так я и ругаюсь что из-за того что cmake такой стандартный его придётся собирать тоже ради того чтобы собрать какую-то мелочь потому что его разработчики никак не могут успокоиться.
Я не говорю что это всё нерешаемо, там есть бустрап, можно всё собрать, можно заставить работать новый cmake, можно собрать тулчейн даже, но всё это не сравнится с простым ./configure&&make или waf configure&&waf но ты опять предлагаешь какие-то космической сложности варианты. Виртуальная машина? qemu-system-arm будет на x86 работать медленнее чем на реальном железе будь оно очень слабое. На большинстве arm железок/виртуалок виртуализация недоступна из-за отсутствия nested виртуализации, разве что в случае с x86 vpsкой я действительно могу вытянуть образ и собрать локально, да ещё и запустить образ ОС какого-нибудь meego в system виртуалке - задача настолько нетривиальная что хз даже с чем сравнить. Не, я понимаю chroot там, но докеры, виртуалки... ЗАЧЕМ ТАК СЛОЖНАААА?

Кросскомпиляцию не пробовали? С Clang это делается без проблем, тулчейны собирать не надо. Достаточно приложить sysroot.

Для этого как минимум надо собрать sysroot, а ещё возможно накидать в него костылей под нужную версию clang. Что опять говорит не в лучшую сторону о cmake - то есть ни с waf ни с autotools не было бы этой проблемы.

А вообще почему просто не сделать так чтобы система сборки не была на порядки сложнее софта который ей собирается? cmake тут по времени сборки впереди планеты всей и его использование вполне оправдано разве что в llvm-project из тех проектов, где я его видел, но тем не менее я постоянно вижу его в программах уровня около хелловорлдов

Для этого как минимум надо собрать sysroot

Зачем? По идее достаточно взять образ бинарного дистрибутива соответствующей версии.

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

Я тут негодую что cmake переусложнён и из-за какой-нибудь мелочи вроде glfw/raylib его приходится обновлять и иной раз просто запускать gcc/g++ вручную и игнорировать его как систему сборки вообще, такая система сборки просто не нужна. cmake не решает проблемы, а создаёт их

Проблемы создают пользователи устаревших дистрибутивов, а не CMake. Даже в Haiku таких проблем нет, пакеты систем сборок свежие.

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

Я если что предпочитаю Meson с которым таких проблем нет. Для простых пооектов сойдёт и Muon.

В gmake нет нормального синтаксиса и без костылей и обвязок ты им проект сложнее hello world не соберёшь.

Вызывающе неверная информация. Собираем codebase в 10ки MLOC используя gmake без всяких autotools (но, правда, не без своих «обвязок») по многу раз в день, и «не пищим». И это со всеми плюшками которые Вы только можете себе представить: инкрементальные билды, dependency tracking итд итп. Более того: в «локальных» билдах всё что незааффекчено локальными изменениями автоматически подбирается из релизных сборок. Как человек непосредственно вовлечённый в поддержку этих Makefiles - знаю о чём говорю. Всё это дело не за 5 минут было создано конечно, а эволюционировало в течение десятилетий. Но как это можно сделать лучше и удобней я, если честно, затрудняюсь представить. Сильно подозреваю что Вы «не котиков не любите, а просто готовить их не умеете». Ну, или у Вас модель разработки кардинально отличается от нашей.

с meson были кстати тоже сложности при сборке mesa под старые системы, приходилось вручную с десяток модулей питоновых тащить и комментировать проверки версий, но mesa уже не hello world, там возможно это и оправдано, но сам meson для простых проектов тоже сложноватый. Muon гляну потом

В Muon вроде можно вкомпилировать pkgconf и samu так что в итоге получится бинарник без зависимостей.

Вот тут хотелось бы по подробнее - как реализован трекинг зависимостей в инклудах? Остальное в мейкфайле вполне удобно и его в целом хватает

Что за эти сорок лет GNU реально дало опенсорцу?

Почти все проекты написаны людьми под GPL, большинство не в рамках проекта GNU. Тем более, весь софт это клоны уже существующих проектов под другой лицензией.

coreutils, GRUB и texinfo. За сорок лет!

Ну ты что…

Когда гнутые делают клоны всего и вся - это правильно, это настоящая свобода. Когда кто-то другой делает альтернативу гнутым утилитам (clang например) - значит они против свободы и ненужно.

Свободная лицензия только одна - GPLv3. А BSD проприетарная, потому что… ну металл тоже опасный, потому что из него делают оружие.

Чем тебе так не нравится GCC?

Прямо сейчас взял собрал последний релиз clang/lld 16.0.1 на Haiku без проблем. Что нужно чтобы собрать последний GCC я даже боюсь представить. Там одна команда конфигурации на несколько строк. И непонятно насколько сложно перенести патчи для Haiku.

LLVM делался в первую очередь чтобы избавиться от GCC.

Всяким гуглам и прочим мракобесам очень не нравится, когда они вынуждены зависить от GPLv3 компанента.

LLVM делается в первую очередь чтобы была современня качественная компиляторная инфраструктура написанная в понятном стиле, а не нечитабельный говнокод GCC основанный на технологиях 1970-ых.

как реализован трекинг зависимостей в инклудах?

Да я думаю - как и у всех: пост процессинг результатов «-MF».

Ну да, все пытаются гнутым насолить. Иначе и быть не может.

вынуждены зависить от GPLv3 компанента.

А почему вообще кто-то должен зависеть от GPLv3 компонентов? Это ж натуральный вендорлок, только в сторону «хороших».

мракобесам

И вообще, кто тебе разрешал вешать оскорбления на людей? Вот уж истинная швабодка, ничего не скажешь. Совсем не секта.

Свободная лицензия только одна - GPLv3. А BSD проприетарная

Я на всякий случай напомню, что это твои личные фантазии. FSF признаёт BSD (2- и 3-пунктные) свободными лицензиями.

это твои личные фантазии

Пруфов бы.

А то вот, ты, наверное, снова пропустил. Но это другое, видимо.

Ичё надо сделать? Почистить систему? Хорошо. В ближайшие выходные - займусь. Хотя... было-бы от чего чистить... разве что от пакетов ненужных. А так - только хомяк! Давайте действительно, дружно, очистим хомяк от накопившегося говна!?

очень не нравится, когда они вынуждены зависить от GPLv3 компанента.

В лицензиях «не копенгаген».
Почему?

А то вот, ты, наверное, снова пропустил.

Какая трогательная непосредственность. Ты предлагаешь мне копаться в ответах на свой наброс и при этом не трогать сам наброс?

Давай уж так. Либо ты принципиальный, и я сношу всю ветку. Либо перестаёшь провоцировать людей и тут же их «сдавать».

Пруфов бы.

Да пожалуйста.

Можно к юбилею залудить какой-нибудь свой опенсорсный проект, маленький, но полезный. Или статью написать «Как перейти на LibreOffice без потерь». Или пару-тройку грамотных багрепортов на любимые проекты оформить.

Время до 27 сентября ещё есть. :)

наброс

Типичная ЛОРовская черта - любые вопросы и любую критику называть набросом. И чего это линуксоидов не любят?..

сношу всю ветку

Прямо с сообщения @mordod?

Дружище, не спорь и «приспосабливайся» (в хорошем понимании этого суждения).
В компании «курящих» не прилично говорить о вреде курения.
Можно и так - «С людьми нужно говорить на том языке, который они понимают».

ИМХО лучше о разработке речь вести.
Всем польза!

Примеры такого кода привести можете?

любую критику

попытка приписать кому-то свои фантазии о проприетарной BSD

Слив засчитан.

Типичная ЛОРовская

Может, тебе действительно лучше воздержаться от посещения такого ресурса?

Слив засчитан.

Твой что ли?

Может, тебе действительно лучше воздержаться от посещения такого ресурса?

Жду, когда кто-нибудь из модераторов окончательно бомбанёт и забанит меня.

Наговоришь на бан — забаним.

А вариант «просто не посещать ресурс» не для тебя, да? Тебе и к уходу обязательно надо скандал устроить? К тому же думаю, что с вероятностью 80% пройдёт месяц, и ты вернёшься под другим ником, толку-то…

Иногда в постах говорю, что форум «Базар» (да все форумы).

Почему так?

Потому что, много постов от тех кто «не в теме».

Пользы для других от таких постов никакой нет, потому-то они «мусор».

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

ИМХО никогда в постах не говорю о том в чем не разбираюсь.

Это и есть костыли. Впрочем это бы решалось если результаты -MF можно было бы настраивать, но это не сделано

дело даже не в зависимости от GPLv3 компонента, а в том, что держать свой форк нереально, так что если хочень чтобы компилятор с твоими патчами обновлялся - придётся всё апстримить, а это уже много возни, это тебе не PR на гитхабе кинуть

https://github.com/haiku/haiku/blob/master/src/system/boot/platform/riscv/FwCfg.cpp#L29

Что за адрес *(uint64*)0x10100010 (257MB)?
Он в исходниках всего лишь один раз появляется.