Костыль для твоей хероты:

$ git clone https://github.com/mirror/newlib-cygwin newlib-2.5.0.20170922
$ cd newlib-2.5.0.20170922/
$ git checkout newlib-snapshot-20170922
$ rev=HEAD; for f in $(git ls-tree -r -t --full-name --name-only "$rev") ; do echo "$f" ; touch -d $(git log --pretty=format:%cI -1 "$rev" -- "$f") "$f"; done;
$ rm -Rf .git*
$ cd ..
$ tar -czf newlib-2.5.0.20170922.tar.gz newlib-2.5.0.20170922/

Не знаю, как это сделать быстрее, не знаток UNIX-утилит и Shell-оболочек. Может спецы оптимизируют. Если лень ждать, вот тебе готовый tarball, который ты можешь попробовать заюзать с combined tree в этом GCC. Даты в нём выправлены «по Git'у».

http://esxi.z-lab.me:666/~exl_lab/software/newlib-2.5.0.20170922.tar.gz

По-хорошему, надо сделать баг-репорт команде разработчиков Newlib в RedHat, раз тебе интересна такая возможность сборки.

Git умеет менять даты файлов в генерируемых tarball'ах по DateTime создания тега. Проблема в самой Newlib и в её откровенно странном подходе к версионированию.

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

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

Да. Можно через системные API, можно вообще притвориться ФС (какой-то из инструментов ClearCase так делал, tup из свободных).

Из документации git archive

git archive behaves differently when given a tree ID versus when given a commit ID or tag ID. In the first case the current time is used as the modification time of each file in the archive. In the latter case the commit time as recorded in the referenced commit object is used instead. Additionally the commit ID is stored in a global extended pax header if the tar format is used; it can be extracted using git get-tar-commit-id. In ZIP files it is stored as a file comment.

И действительно, если сделать

$ git archive --prefix=newlib-2.5.0/ -o newlib-2.5.0-20170922.tar.gz newlib-snapshot-20170922
$ tar -tvzf newlib-2.5.0-20170922.tar.gz | grep include/dwarf2.h
-rw-rw-r-- root/root     12666 2017-09-19 23:36 newlib-2.5.0/include/dwarf2.h

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

Нет, судя по всему они их делали так же.

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

Да нет же, я вижу в этом определённую логику: библиотека релизнулась под датой «20170922», пусть тогда и все её файлы имеют дату 20170922. Это вполне себе объяснимый подход.

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

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

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

Как определяет, что файл надо перекомпилировать, не нашёл.

Да. Можно через системные API, можно вообще притвориться ФС (какой-то из инструментов ClearCase так делал, tup из свободных).

А между запусками демона они что делают? Или считают, что у всех пользователей демон запущен постоянно?

Спасибо конечно, но ты опоздал. Выше я уже написал аналогичный костыль.

По-хорошему, надо сделать баг-репорт команде разработчиков Newlib в RedHat, раз тебе интересна такая возможность сборки.

Да. Правда я не до конца уверен, что и этот костыль всегда работает правильно. Ведь если они синхронизируют изменения общего кода вручную, есть небольшая дельта по времени, когда изменение из gcc взято, но ещё не закомичено в newlib, а за это время в gcc или в binutils или в другом gdb этот же файл опять изменился. В итоге даже если смотреть на дату синхронизирующего коммита получим слегка старую ревизию файла как новее самой новой. Вероятность этого конечно низкая, но всё равно она есть. Хотя для релизов и даже снепшотов наверное будет работать правильно и так.

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

Git умеет менять даты файлов в генерируемых tarball'ах по DateTime создания тега.

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

Проблема в самой Newlib и в её откровенно странном подходе к версионированию.

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

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

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

можно вообще притвориться ФС, какой-то из инструментов ClearCase так делал

Это сам ClearCase делал. По моему кроме ClearCase так больше никто не умеет.

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

я как раз занимаюсь тем

Это шиза типа тулкитофобии только ещё хуже.

Да нет же, я вижу в этом определённую логику: библиотека релизнулась под датой «20170922», пусть тогда и все её файлы имеют дату 20170922. Это вполне себе объяснимый подход.

Что значит пусть? Это что DOS 6.22, что все её файлы имеют время модификации 6:22? Это ведь не для красоты нужно. Для красоты пусть лучше gitk перепишут во что-то человеческое.

А между запусками демона они что делают? Или считают, что у всех пользователей демон запущен постоянно?

Про «всех пользователей» не понял. Как работает конкретно tup, просто не знаю. В Mercurial был плагин, ускорявший hg diff на больших репозиториях (за счет того, что отслеживал изменения) - он запускал демона при первом вызове.

Про «всех пользователей» не понял.

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

Как определяет, что файл надо перекомпилировать, не нашёл.

Там скорее всего по хешу, далеко не залезал, на touch <file> Gradle внимание не обращает, а ссылка это как пример демона в системе сборки.

Watch плагин тут: https://plugins.gradle.org/plugin/com.bluepapa32.watch на изменения состояния файлов/дерева можно вешать всякие обработчики.

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

При использовании *notify? Нет.

Если это только один из методов, тогда всё нормально.

*notify - метод ускорения обычной работы: через хеши или даты модификации.

Выше я уже написал аналогичный костыль.

А да, сорри, не заметил.

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

И столько же приключений из-за combined tree.

Кстати, а разве сам GCC не перешёл на GIT? Как он там строит tarball'ы сквозь него?

P.S. Как я понял, GCC ещё не перешёл, но они уже два года собираются:
https://gcc.gnu.org/ml/gcc/2015-08/msg00140.html
https://news.ycombinator.com/item?id=10097221
https://www.reddit.com/r/linux/comments/3hurzd/gcc_discusses_moving_to_git/

Лучше любители combined tree страдать будут, чем все остальные.

О каких страданиях всех остальных ты говоришь?

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

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

В любом случае, эта не та проблема в Git, которую кто-то и когда-то будет решать.

Отправь фич-реквест в сам Git, если тебе это так нужно.

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

P.S. Насколько я вижу, в hg эта фича идет third-party плугином.

P.P.S. И авторы HG против такой фичи: https://www.mercurial-scm.org/pipermail/mercurial/2015-August/048617.html

Это ведь не для красоты нужно.

Для чего ещё, кроме Combined Tree это нужно?

Проще просто перейти на Mercurial. Проблема в том, что проекты вроде gcc, binutils, newlib и т.п. не перейдут. Причём вовсе не по техническим причинам, а лишь потому, что git моднее, а Бенедикт известнее.

А еще потому, что Mercurial их тоже не сохраняет. Откуда ты это вообще взял?

Ха. Так в мире IT всегда выигрывает достаточно ущербненькое решение, когда нормальному отведено место вечного забвения.

Иначе популярность того же CMake и не объяснишь.

Ну и у Mercurial тоже есть недостаток: его ещё не переписали на Python 3.

Хм, и правда.

hg clone — даты потеряны
hg archive — даты потеряны
hg checkout — даты потеряны

bbk123, ну что? Остаёмся на SVN?

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

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

И для Mercurial таки есть расширения, добавляющие эту функциональность.

То есть, ни одна DVCS mtime не сохраняет (без сторонних плагинов). Теперь, попробуй понять почему.

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

В квотезы

Ты мне расскажи почему, если такой умный.

то у sh ровно та же самая проблема: каждый пишет его как хочет

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

и я пока не видела ни одной системы, где бы sh вызывал проблемы с make или автотулзами. бывает, что внешние утилиты типа grep или awk по-разному реализованы, а разработчик их запихнул в скрипты. но это не проблема шелла.

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

Ты мне расскажи почему, если такой умный.

Потому что DVCS подразумевает нелинейную работу с коммитами.

Всё сложно...

Как минимум: не понятно откуда именно нужно брать дату последней модификации файла. Во-первых, тот же гит сохраняет две даты: author date (когда автор создал коммит на своей машине) и commit date (когда коммит последний раз изменялся, сюда входят рибейзы, применения на другие ветки, git am и так далее). Во-вторых, нет никакой гарантии, что в ветке даты будут идти по порядку. В реальной жизни в более-менее сложных проектах и проектах с более чем одним разработчиком они будут перемешаны.

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

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

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

Потому что DVCS подразумевает нелинейную работу с коммитами.

DVCS подразумевает лишь отсутствие единого репозитория. Причём же тут mtime?

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

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

Уровень твоего самомнения просто поражает.

Ты собираешь под эмбеддед на самой железке? Держишь там все средства разработки, исходники?

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

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

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

Наверное, тебе поэтому так мало платят.

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

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

Я видел твои резюме. Если это действительно высокие зарплаты в екб, это печально.

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

200 тыщ

С опытом работы в 20 лет? Это очень, очень грустно.

С опытом работы в 20 лет? Это очень, очень грустно.

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

я ещё раз говорю: пистон - полное дерьмо. и это никак не зависит от моей зарплаты.

Как минимум, это очень медленно. И нет места под интерпретатор, который весит 30mb со всей стандартной библиотекой и прочем.

А вообще детский сад. Такой максимализм.

Главное, не нервничай. Твое мнение относительно пистона никак не отменяет того факта, что все крупные проекты его в той или иной мере используют (даже линуксовое ядро).