LINUX.ORG.RU
ФорумTalks

git is really stupid and made by stupid

 


0

3

gcc можно собирать вмести с binutils, newlib и прочими библиотеками и инструментарием GNU (например gdb) в так называемом combined tree, тоесть из сведённого в одно дерево исходников. Например если вы распаковали исходники gcc-7.2.0 и binutils-2.29.1 вы можете свести их в одно дерево (одну директорию) командами:

rsync -au gcc-7.2.0/ combined-gcc-7.2.0/
rsync -au binutils-2.29.1/ combined-gcc-7.2.0/

Это работает благодаря тому, что оба проекта используют единую базу инфраструктурного кода gcc и периодически синхронизируются между собой. Но если вы попытаетесь точно так же добавить ещё и код newlib-2.5.0.20170922 вы испортите combined-gcc-7.2.0 и в частности файл include/dwarf2.h

Почему это происходит? Потому что git не умеет сохранять даты модификаций файлов. В итоге git выставляет текущую дату и время в качестве даты модификации файла всякий раз, когда изменяет его содержимое после таких команд как git clone или git checkout.

В git репозитории проекта newlib файл include/dwarf2.h последний раз модифицировался аж в 2016-06-23, но в тарбале newlib-2.5.0.20170922 дата его модификации 2017-09-19:

https://sourceware.org/git/?p=newlib-cygwin.git;a=history;f=include/dwarf2.h
ftp://sourceware.org/pub/newlib/newlib-2.5.0.20170922.tar.gz

В git репозитории проекта binutils, после 2016-06-23 и до создания тага релиза binutils-2_29_1.1, этот же файл модифицировался три раза, последний раз 2017-07-02. Одно из изменений, отсутствующее в newlib-2.5.0.20170922 - добавление внешней функции get_DW_IDX_name

https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=include/dwarf2.h;h...

Но поскольку дата модификации include/dwarf2.h в тарбале newlib-2.5.0.20170922 неверная и якобы новее, rsync оставляет именно её вместо действительно более новой версии из binutils.

Проблема не новая, с Линусом уже перетёртая и я далеко не первый, кто назвал его решение глупым. Кстати, в Mercurial такой проблемы нет. В старых системах управления версиями (CVS, SVN) её тоже не было. Линус решил, что он самый умный и вот результат. Ну чем не Поттеринг?

★★★★★

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

system-root ★★★★ ()
Ответ на: комментарий от system-root

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

EXL ★★★★★ ()
Ответ на: комментарий от EXL

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

bbk123 ★★★★★ ()
Ответ на: комментарий от EXL

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

a1batross ★★★★★ ()
Ответ на: комментарий от KennyMinigun

Какой славный костыль. Тянет за собой и 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

Оба костыля делают примерно тоже самое и довольно медленно. В любом случае это надо делать авторам newlib и прочих GNU-тостей, использующих git, перед созданием тарбала, а не мне.

bbk123 ★★★★★ ()
Последнее исправление: bbk123 (всего исправлений: 1)

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

hateyoufeel ★★★★★ ()
Последнее исправление: hateyoufeel (всего исправлений: 1)

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

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

RedJohn ()
Ответ на: комментарий от hateyoufeel

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

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

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

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

baka-kun ★★★★★ ()
Ответ на: комментарий от baka-kun

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

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

system-root ★★★★ ()

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

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

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 3)
Ответ на: комментарий от a1batross

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

meson

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

d_a ★★★★★ ()
Ответ на: комментарий от RedJohn

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

d_a ★★★★★ ()
Ответ на: комментарий от kirk_johnson

ninja и meson

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

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

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от system-root

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

bbk123 ★★★★★ ()
Ответ на: комментарий от d_a

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

kirk_johnson ★☆ ()
Ответ на: комментарий от Iron_Bug

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

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

a1batross ★★★★★ ()
Последнее исправление: a1batross (всего исправлений: 1)

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

Зачем?

i-rinat ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

Iron_Bug ★★★★ ()
Ответ на: комментарий от a1batross

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

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

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от a1batross

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

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

kirk_johnson ★☆ ()

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

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

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

HeipaVai1o ()
Ответ на: комментарий от HeipaVai1o

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

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

stevejobs ★★★★☆ ()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

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

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

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от d_a

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

EXL ★★★★★ ()
Ответ на: комментарий от stevejobs

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

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от EXL

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

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

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

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

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

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

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

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

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

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

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

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

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от tailgunner

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

bbk123 ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

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

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от bbk123

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

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

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

stevejobs ★★★★☆ ()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от tailgunner

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

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

bbk123 ★★★★★ ()
Ответ на: комментарий от bbk123

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

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

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

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

Или rsync -auc

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

EXL ★★★★★ ()
Ответ на: комментарий от EXL

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

Вполне.

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

EXL ★★★★★ ()
Ответ на: комментарий от stevejobs

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

bbk123 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.