git is really stupid and made by stupid

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

Так они этого не делают. Я ведь не ради празного любопытства пытаюсь создать combined tree.

Или rsync -auc

Как флаг -c поможет определить какая из трёх версий include/dwarf2.h более новая?

Хорошо. Будем считать, что они все разные и это типа правильно и очень удобно(на самом деле нет). И что авторы всех этих несовместимых друг с другом мейков на самои деле не психически больны.

Но вот про скрипты я абсолютно не согласен. На каждый мейкфайл ты должна знать под какой мейк он написан. Спасибо GNU, что они сейчас везде, за исключением бздшников, которые по религиозным соображениям не хотят GPL-ный код.

А вот теперь про аутизмотулсы. Насколько я знаю, этот набор костылей требует m4 и sh. Если с m4 проблем нет, то у sh ровно та же самая проблема: каждый пишет его как хочет. Я уже не говорю о том как работают аутизмотулсы. Генератор ехал через генератор, называется.

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

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

Так они этого не делают

/me shrugged

Если они этого не делают, придется тебе. Если не хочешь/не можешь использовать git-subtree/git-submodules - придется вручную. И бесполезно жаловаться «это должны они».

Как флаг -c поможет определить какая из трёх версий include/dwarf2.h более новая?

Очевидно, что никак. Но если ты настаиваешь на использовании именно rsync, то вызывай команды в правильном порядке и используй -c.

А вот теперь про аутизмотулсы. Насколько я знаю, этот набор костылей требует m4 и sh. Если с m4 проблем нет, то у sh ровно та же самая проблема: каждый пишет его как хочет

autotools используют стандартизированное подмножество шелла.

Если они этого не делают, придется тебе. Если не хочешь/не можешь использовать git-subtree/git-submodules - придется вручную. И бесполезно жаловаться «это должны они».

Мне бесполезно использовать git-subtree/git-submodules с кодом gcc поскольку этого не делают сами разработчики. И мерджить их код в ручную я не могу по банальной причине - я не являюсь разработчиком всех этих проектов одновременно и поэтому недостаточно хорошо знаком со всем его нутром. Если разработчики заявляют об официальной поддержке combined tree, они должны позаботиться о том, чтобы не разработчики могли такой combined tree относительно легко создать.

Очевидно, что никак. Но если ты настаиваешь на использовании именно rsync, то вызывай команды в правильном порядке и используй -c

Я не наставива, я лишь не нашёл ничего лучше. И флаг -c тут не нужен, даже если бы git не портил дату модификации файлов.

Твоя проблема с актуализированными версиями дат высосана из пальца.

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

rsync'ая сорцы в combined-tree ты рано или поздно столкнёшься с какими-нибудь проблемами сборки в лучшем случае, а в худшем всё соберётся, но работать будет с heisenbug'ами из-за смешивания кода.

Если бы разработчик этой newlib поставлял сорцы вообще в каком-нибудь формате архива без сохранения даты файлов или ручками делал touch *, то Git здесь был бы ни при чём, но проблема бы осталась.

А потому что полагаться на даты файлов, как это делаешь ты, это всё равно что стрелять себе по ногам.

Если живущий в каком-нибудь Петропавловске-камчатском (у них там уже 4 декабря) вот прям сейчас зальёт тебе тарбалл сорцов, которые ты скачаешь сидя в Тель-Авиве и попытаешься их собрать, то есть шанс, что твой make вообще уйдёт в while(1) пока у тебя не наступит завтра.

Не помню, решили этот баг с make или нет, но я с таким сталкивался.

Почему остальные разработчики должны подстраивать под git годами если не десятилетиями прекрасно живущие проекты?

Я уверен, что остальные разработчки давным-давно забыли про Combined Tree и у них отпало это множество проблем, как класс.

Ээээ... то есть если бы эти файлы действительно обновились, то все тоже сломалось бы?

Нет конечно, не сломалось бы. Осталась бы действительно самая новая версия этого общего, для нескольких проектов, файла.

Не говоря уже о том, что CVS и SVN централизованные системы.

Почему ты забыл про Mercurial?

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

А ты забавный. В твоём rsync есть искуственный интеллект?

В GIT'е есть множество других актуальных проблем и недостатков:

• Нет понятия докачки/дозагрузки из-за чего на нестабильных мобильных соединениях работа с GIT'ом превращается в ад.
• Нет возможности добавить пустые каталоги в репозиторий и определить/запланировать этим действием будущую структуру проекта.
• Проблемы с восстановлением БД при различных факапах. Несколько раз натыкался на повреждение базы и полную неработоспособность и невозможность восстановления репозитория из-за, скажем так, внезапного отключения электричества при работе с репозиторием. Спасала только децентрализация и привычка отправлять коммиты в удалённые репозитории сразу после их создания.
• Достаточно неочевидная работа с несколькими подпроектами как с помощью Git submodules, так и с помощью Git subtrees. Можно было сделать куда как проще.
• Невозможность редактирования COMMIT_MSG отдельно от самого коммита, в итоге в крупных проектах везде очепятки и не слишком подробные сообщения, которые можно было бы исправить и дополнить полезными заметками, но с переписыванием всей истории никто не хочет заморачиваться

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

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

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

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

Зависит от системы. Некоторые считают хеш-суммы, некоторые следят за изменениями.

Зависит от системы. Некоторые считают хеш-суммы, некоторые следят за изменениями.

А чо из открытого считает суммы?

P.S. Scons вроде умеет.

О Scons и речь.

Зависит от системы. Некоторые считают хеш-суммы, некоторые следят за изменениями.

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

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

Я не выбирал, я на эту проблему наткнулся на практике. При этом сам git я не использовал, а лишь скачал тарбол.

Невозможность редактирования COMMIT_MSG отдельно от самого коммита

Это как раз фича.

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

Если бы это было стандартным решением, сломались бы не только гнутые мегаподелки.

А чо из открытого считает суммы?

Сейчас проверил:

Gradle считает какие-то хеши, пофиг на время.

QBS, так же как и make, ориентируется на время.

Meson, так же как и make, ориентируется на время.

Если бы это было стандартным решением, сломались бы не только гнутые мегаподелки.

А где здесь «сломались гнутые мегаподелки»? Git?

Прости, как ты собираешься из трех файлов include/dwarf2.h найти самый свежий, если кто-то (не будем показывать пальцем, хотя это был git) похерил время правки?

Чей хеш в ветке выше, того и старше.

Идея Combined Tree изначально ущербна.

Что, если новый include/dwarf2.h будет содержать правки, которые сломают сборку других проектов в combined tree? И даты файов, и Git, и Hg тут вообще будут ни при чём.

То есть здесь ещё и версии инструментов нужно тщательно подбирать, чтобы оно хоть как-то было работоспособно.

Куча проблем, а полезного выхлопа ноль.

Чей хеш в ветке выше, того и старше.

То есть к трем файлам на руках нужно раздобыть какую-то дополнительную информацию по sideband каналу? И метаданных самих файлов нам недостаточно?

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

Что, если новый include/dwarf2.h будет содержать правки, которые сломают сборку других проектов в combined tree?

Значит будет regression и поломана обратная совместимость. Ответственный за коммит получит по шапке, и в следующий раз постарается не сломать билд.

Я сейчас посмотрел, проект newlib вообще не от GNU. То, что они там сделали кривую совместимость с combined tree для GCC, не значит абсолютно ничего. С таким же успехом они и вовсе могли на него забить, и чего?

Если разработчики заявляют об официальной поддержке combined tree, они должны позаботиться о том, чтобы не разработчики могли такой combined tree относительно легко создать.

Разработчики какого проекта заявляют? GCC или Newlib?

Что, если новый include/dwarf2.h будет содержать правки, которые сломают сборку других проектов в combined tree?

Не будет, потому что все эти проекты периодически синхронизируют общий код, в том числе и этот include/dwarf2.h

Я так и не понял, причем тут Git. Если ты тарболы скачал, то там время правильное. Если ты один тарбол заменил слитым из Git кодом, то сам виноват.

Я сейчас посмотрел, проект newlib вообще не от GNU.

И что? А если завтра кто-то сломает stdlib.h?

Я так и не понял, причем тут Git.

Насколько я понял ТС, тарболы создаются из слитого из git кода. То есть с заведомо поломанным временем файлов.

Я сейчас посмотрел, проект newlib вообще не от GNU.

Не важно кто разработчики. Важно, что newlib - часть GNU. Например тот же gcc configure имеет флаги, связанные с этим newlib.

Если я возьму tarball самого нового GCC и tarball самого старого newlib, потом смешаю их в combined tree, всё будет компилироваться и работать?

Насколько я понял ТС, тарболы создаются из слитого из git кода. То есть с заведомо поломанным временем файлов.

Так и есть.

Нет, это важно.

Сорцы Newlib вообще на серверах RedHat и не входят в GNU. Я специально зашёл в репозиторий и на офф сайт бибилиотеки и посмотрел в README и в документацию. Нигде там не нашёл упоминания про combined tree или про то, что сперва нужно скачать gcc и потом развернуть исходники newlib в дерево gcc.

Если проект GNU GCC взял эту библиотеку в свою экосистему, и завязал на combined tree, то они и должны tarball'ы редхата выправлять ручками, чтобы этот combined tree работал.

Ты скачал tarball с сайта RedHat, которые, похоже и слухом не слыхивали про этот Combined Tree от GNU, а виноват, внезапно, git?

Ты скачал tarball с сайта RedHat, которые, похоже и слухом не слыхивали про этот Combined Tree от GNU, а виноват, внезапно, git?

Слыхивал и ещё как слыхивал. Они используют общую инфраструктуру с gcc. Более того, эта инфраструктура имеет явный механизм интеграции с newlib (configure --with-newlib). Не хотели бы они этого, сделали бы так же, как всякии mpfr, mpc, gmp и прочии isl, которые никакой общий код с gcc не разделяют.

Тогда ты будешь сам себе злобный Буратино. Возьми самое новое ядро Linux и самый старый gcc, а теперь скомпилируй певое вторым. Вот так же и твой пример.

Насколько я понял ТС, тарболы создаются из слитого из git кода. То есть с заведомо поломанным временем файлов.

Тогда почему не работает только у ТС?

Кстати, glibc combined tree не поддерживает, хотя он точно GNU-тый и тоже libc.

Тогда почему не работает только у ТС?

Кто сказал? Я тоже вижу, что в архиве newlib файл предыдущей ревизии имеет слишком свежую дату модификации.

Почему только? У тебя работает? Собери мне gcc-7.2.0+binutils-2.29.1+newlib-2.5.0.20170922 из combined tree стандартными средствами.

А как это собирают авторы GCC?

Таг. Я вот сейчас сделал так:

$ git clone https://github.com/mirror/newlib-cygwin
$ cd newlib-cygwin/
$ git archive --prefix=newlib-2.5.0/ -o newlib-2.5.0.tar.gz newlib-2_5_0
$ tar -tvzf newlib-2.5.0.tar.gz | grep include/dwarf2.h
-rw-rw-r-- root/root     12232 2016-12-23 09:33 newlib-2.5.0/include/dwarf2.h

Более того:

$ git archive --prefix=newlib-2_3_0/ -o newlib-2_3_0.tar.gz newlib-2_3_0
$ tar -tvzf newlib-2_3_0.tar.gz | grep "include/dwarf2.h"
-rw-rw-r-- root/root     12230 2015-12-22 08:32 newlib-2_3_0/include/dwarf2.h

Дата файла в tarball-е меняется. Скорее всего это не дата последнего изменения файла, а дата установки тега. Но оно работает.

Видимо разработчики RedHat каким-то особенным образом делали эти TarBall'ы.

Ох, бл*джд, да там у них форменная наркомания.

2.5.0 и 2.5.0.20170922 это вообще разные версии. В репозитории ~280 веток и 650 (!) тегов, в которых номера версий вида:

newlib-1_14_0
newlib-1_15_0
newlib-1_16_0
newlib-1_17_0
newlib-1_18_0
newlib-1_19_0
newlib-1_20_0
newlib-1_9_0
newlib-2000-02-17
newlib-2_0_0
newlib-2_1_0
newlib-2_2_0
newlib-2_3_0
newlib-2_4_0
newlib-2_5_0

Смешаны с какими-то непонятными Snapshot'ами вида:

newlib-snapshot-20150323
newlib-snapshot-20150423
newlib-snapshot-20150526
newlib-snapshot-20150623
newlib-snapshot-20150723
newlib-snapshot-20150824
newlib-snapshot-20150924
newlib-snapshot-20151023
newlib-snapshot-20160104
newlib-snapshot-20160226
newlib-snapshot-20160527
newlib-snapshot-20160923
newlib-snapshot-20170228
newlib-snapshot-20170323
newlib-snapshot-20170421
newlib-snapshot-20170519
newlib-snapshot-20170623
newlib-snapshot-20170720
newlib-snapshot-20170818
newlib-snapshot-20170922

Как тут понять, какой версии какой снэпшот принадлежит?! Как разрабы вообще выставляют тут версии: ftp://sourceware.org/pub/newlib/ по Git'у?

Какой ужас и бардак.

И вы ещё хотите, чтобы они кропотливо и придирчиво следовали Combined Tree? Бгг.

Релизы и снепшоты. В чем проблема-то?

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

А почему Дженту вынуждено поддерживать 12 несовместимых версий автотулзхов?

Combined tree - не единственно возможный способ сборки. Можно собирать и раздельно. Более того в большинстве дистрибутивов даже gcc разделён на несколько пакетов. Тем не менее combined tree всё ещё официально поддерживается и имеет свои преимущества.

В том, что непонятно, каким снепшотам и какой дате, какая версия библиотеки соответствует.

и имеет свои преимущества.

Назови хоть одно?

Некоторые считают хеш-суммы, некоторые следят за изменениями.

Как можно следить за изменениями, не используя ни время правки, ни хеши? Сделать собственные копии? Это ещё дольше хешей. Держать запущенным демона, который отслеживает все операции записи?

gcc сразу собирается тем же binutils которые есть в combined tree и с тем же libc (newlib). gcc поддерживает трёхпроходную bootstrap сборку самого себя, а combined tree позволяет интегрироваться в существующий bootstrap не изобретая своего. Ну и иногда проще запустить один configure && make && make install чем несколько.

Держать запущенным демона, который отслеживает все операции записи?

У Gradle есть watch-плагин, который может мониторить изменившиеся файлы и демон, который сильно сокращает время сборки.

https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:how_does_the...