git is really stupid and made by stupid

возможно мне кажется, но сборка сорцов фряхи падала, если в процессе менялось время через ntp.
все эти ваши завязки на atime или модификации — полная дичь времён мейнфреймов.

Это ещё что, make вот при каких-то там обстоятельствах падает в бесконечный цикл, если видит дату «в будущем времени».

Ну с этим ещё можно как-то бороться. А как свести gcc + binutils + newlib + что-то ещё из GNU, если почти всё из этого живёт в git и старый код может неожиданно стать новее нового?

Его давно пора похоронить. Вот чем иксы переписывать впустую, лучше бы занялись утилитами разработки. :)

На уот:

https://github.com/rosylilly/git-set-mtime

Какой славный костыль. Тянет за собой и Go и Ruby и всё это из-за упёртости Линуса Бенедикта Паттеринга. У меня есть костыль получше, но всё равно костыль:

#!/bin/sh

repository_files=$(git ls-files)
amount=$(echo "$repository_files" | wc -l)
count=0

for file in $repository_files; do
        echo -ne "\033[99DFixing modification time: $((++count)) of $amount repo files."
        touch --no-create --date="$(git log -1 --format=%ci $file)" $file
done

Я что-то не понимаю, зачем завязывать сборку на atime? У GNU вообще бывают решения не через жопу? Или это их фишка?

до создания тага

Фу ты мерзкий.

Я что-то не понимаю, зачем завязывать сборку на atime?

Только не atime, а mtime.

У GNU вообще бывают решения не через жопу?

При чем здесь гну? Это стандартное решение во всех системах сборки, контроля версий и резервного копирования.

Это стандартное решение

общепринятое, ещё когда «деды код писали», эту дичь что, стандартизировали?

Ээээ... то есть если бы эти файлы действительно обновились, то все тоже сломалось бы? А виноват git? LOL. Не говоря уже о том, что CVS и SVN централизованные системы.

P.S. Выставь ключ, чтобы rsync по содержимому сравнивал, и не ной.

похоронщики - стройтесь в очередь. вас тут навалом ещё со времён появления make и автотулзов. впрочем, это никак на него не влияет, к счастью.

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

ninja и meson.

meson

Это который пишут два школьника-неосилятора cmake? Один из них вроде даже сидит на лоре.

Ты ещё его тред про раутер не видел. Или видел.

ninja и meson

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

я как раз занимаюсь тем, что выпиливаю подобные говна из пакетов. и всё становится намного проще и изящнее.

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

Ты невнимательна. Прочти ещё раз исходное сообщение, обрати внимание на словосочетание «combined tree». Это официально поддерживаемый способ сборки gcc вмести с сопутствующми программами и библиотеками. Не тупи так больше.

У тебя есть какие-то альтернативы применительно к combined tree?

Ага. Его в иксы и системд пропихнули, как дефолтную систему сборки. И, по-моему, у Грега, были мысли в ядро это протолкнуть.

git submodules.

Не знаю, что такое combined tree, но есть git-subtree: https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt

На них*. У всех этих мейков самая большая проблема. Их много. То что синтаксис ублюдочный это уже другой вопрос. Конечно, инопланетные поделия ещё хуже. Поэтому принципиально другое тоже не нужно.

Аутизмтулсы это другая история. Когда компиляторы были ещё более несовместимы друг с другом надо было запускать кучу тестов. Сейчас, к счастью, таких проблем нет.

Например если вы распаковали исходники gcc-7.2.0 и binutils-2.29.1 вы можете свести их в одно дерево (одну директорию) командами

Зачем?

Не тупи так больше.

а я и не туплю. у меня опыт программирования просто дох-я лет. тупишь ты. ты пытаешься собрать. не собирается. ты как баран бьёшься, причём ещё и обвиняешь в этом гит.

практика же показывает, что «официально поддерживаемый» - это ещё не означает «реально работающий». но нубам это неизвестно, конечно. поэтому столько баттхёрта на ровном месте.

У всех этих мейков самая большая проблема. Их много.

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

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

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

P.S. GnuMake портирован везде.

Дебилы наговнокодили а виноват Git. Чудесно, просто чудесно.

Дебилы наговнокодили, а виноват GNU. Чудено, просто чудесно.

ну то есть, гнутых дебилов насильно гитом заставляют пользоваться, так что ли?

в других местах за такую систему сборку увольняют

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

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

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

Как пакетный менеджер свяжан с ОС? В OpenBSD нет pip или что?

На эту систему сборки сделал ставку RedHat. Всё лучше, чем угрёбищный CM*ke.

в других местах за такую систему сборку увольняют

Бедная сборка. Ее уволили, где ж она себе работу найдет.

Нельзя ли пруфов о ставке RedHat? А то жалование одного птушника с ЛОР как-то не подходит для «ставки».

Как пакетный менеджер свяжан с ОС? В OpenBSD нет pip или что?

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

Не путай пакетный менеджер дистрибутива и пакетный менеджер модулей языка.

Не путай пакетный менеджер дистрибутива и пакетный менеджер модулей языка.

я и не путаю. пистон вообще фтопку. «пакетный менеджер языка» - это проблема языка, а не дистрибутива. и именно поэтому не нужно тащить это УГ в зависимости пакетов. в дистрибутиве должны использоваться только штатные тулзы, желательно стандартные.

ты как баран бьёшься, причём ещё и обвиняешь в этом гит.

Твоя упёртость достойна не менее сочных эпитетов. Гит портит дату модификации файлов и это ломает создание combined tree. Это факт, а факт, как известно - самая упрямая в мире вещь.

практика же показывает, что «официально поддерживаемый» - это ещё не означает «реально работающий».

Вот именно из-за git это и не работает. Невозможно корректно создать combined tree из тарболов исходников разных проектов с общим базовым кодом, у которого неправильная дата модификации.

но нубам это неизвестно, конечно. поэтому столько баттхёрта на ровном месте.

В данном случае батхерт лишь у тебя. Я не услышал от тебя ничего рационального.

Как это поможет при создании combined tree из тарболов? Да и мерджить репозитори разных проектов, в которых одни и те же изменения приходят разными коммитами (ручная синхронизация базового кода) - то ещё удовольствие.

Ага, и чо? Сделать врапер, который из условного cpm вытягивает зависимости и делает пакет — дело техники. В генте так сделано для хацкеля и других языков. В C, как всегда, разброд и шатание.

Может быть это более правильное решение.

Как это поможет при создании combined tree из тарболов?

Я не заметил в условиях задачи обязательного использования именно тарболлов.

мерджить репозитори разных проектов

Наверное, в этом и правда мало удовольствия, но я не понимаю, зачем бы тебе делать это.

Впрочем, если git-subtree не облегчает твою жизнь, просто не пользуйся им. Синхронизируй всё вручную.

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

так давным-давно сделано уже везде, кроме говнокодеров, которые с начала 90х привыкли руками папки в папки копировать, а версии на «рабочем столе» хранить в виде папок с названиями «версия1», «версия2», «версия3». Хочешь в версию3 влить изменения? Да не беда, по имейлу или скайпу просишь у васяна его папочку, а потом сливаешь с заменой файлов

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

Впрочем, если git-subtree не облегчает твою жизнь, просто не пользуймя им. Синхронизируй всё вручную.

Синхронизировать должны разработчики или создать условия для простой автоматической синхронизации теми, кто их код компилирует. Например при помощи rsync -au

Впрочем, если git-subtree не облегчает твою жизнь, просто не пользуймя им. Синхронизируй всё вручную.

Синхронизировать должны разработчики

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

или создать условия для простой автоматической синхронизации теми, кто их код компилирует. Например при помощи rsync -au

Или rsync -auc

1. Все приложения GNOME-стека переходят на Meson:
https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

2. Базовые библиотеки, вроде: GTK, GDK, GStreamer, GLib переходят на Meson:
https://git.gnome.org/browse/gtk /tree/meson.build | https://cgit.freedesktop.org/gstreamer/gstreamer/tree/meson.build | https://git.gnome.org/browse/glib/tree/meson.build

3. systemd, PA и этот новый редхатовский PipeWire переходят на Meson:
https://github.com/systemd/systemd/blob/master/meson.build | https://github.com/PipeWire/pipewire/blob/master/meson.build

4. Графический стек из X.Org, Wayland, Libinput и Mesa сотрудники RedHat'а переводят на Meson:
https://github.com/mirror/xserver/blob/master/meson.build | https://github.com/wayland-project/libinput/blob/master/meson.build | https://github.com/mesa3d/mesa/blob/master/meson.build

Достаточно для пруфа или продолжишь шлангование?

Достаточно для пруфа

Вполне.

или продолжишь шлангование?

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

Шланги это те, кто обзывается «птушниками» :-(

Изначально это был один проект - GNU. Затем он разделился на несколько проектов, но некоторый общий код и инфраструктура сборки остались общимм и они продолжают всё это между собой синхронизировать. Посмотри соответствующие коммиты в binutils или newlib. Тут врядли применимы категории правильно и неправильно, это исторически сложившаяся практика. Но факт в том, что это ломает combined tree исключительно из-за неправильного поведения git. Почему в отношении git я использую слово «неправильно»? Потому что лишь git не умеет сохранять дату модификации файлов и лишь он выбивается из стандартного поведения всех остальных систем хранения версий, включая очень похожий на него Mercurial. Почему остальные разработчики должны подстраивать под git годами если не десятилетиями прекрасно живущие проекты?