Любителям CMake посвящается

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

В конторе работают дебилы. Отправляй им уже сгенерированные CMake makefile-ы - дебилы должны страдать.

то есть, без вариантов?

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

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

Он тебе правильно сказал. Пусть принимают вместе со сгенеренными мейкфайлами. Если системы такие одинаковые, до такой степени.

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

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

Вообще CMake создаёт зависимости в виде ациклического графа, про какой порядок сборки речь? Или он разные мейкфайлы генерирует?

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

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

Они берут deb-src скармливают его у себя в такую же сборочную среду и получают свой deb. Далее они берут и сравнивают потроха моего и их пакета (не все, а только so-шки и бинари)

Так что, в этом свете предстоит нехилый финт ушами, чтобы провернуть твоё предложение...

Разве в бинари не пишут какой-то timestamp времени сборки?

разные link.txt и еще какие-то.

Ничего себе, идиоты!

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

разные link.txt и еще какие-то.

Чем именно они различаются, порядком линковки обьектников или чем-то ещё? Если так, то стоит отправить багрепорт. Кстати, какая версия CMake?

Autotools конечно же несомненно лучше CMake (лет'с зе срач бегин :) ), но система сборки тут не при чём, как минимум компилятор добавляет таймстампы при сборке, и они естественно одинаковыми не будут. Как вариант, можно их обнулять или выставлять в нужное значение после сборки бинарника

Версии виртуальных машин стопудово одинаковые?

// а еще, я нихрена не понял, на кой черт собирать в виртуальной машине???

И попробуй отключить всю оптимизацию в CFLAGS.

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

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

Так что, в этом свете предстоит нехилый финт ушами, чтобы провернуть твоё предложение...

Остальное ты просил не предлагать.

не за что. Тебе может никакой инфы и не дало, но это ни о чём и не говорит(кроме того, что это крайне печально).

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

да, стопудово. они созданы с нуля и для инсталляции использован один и тот же исо.

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

Разве в бинари не пишут какой-то timestamp времени сборки?

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

пончик, ты, наверное думаешь, я первым делом на лор попёрся? ты сильно ошибаешься.

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

А зачем тебе физическая тачка на каждый чих? chroot делай. или тебе еще и нужны разные архитектуры?

// оптимизации-то попробовал отключать?

оптимизации-то попробовал отключать?

пробовал. не помогает.

Отправляй им уже сгенерированные CMake makefile-ы

Абсолютные пути, прописанные в сгенерированных Makefile, придадут страданиям особо утончённый привкус.

абсолютную идентичность сред сборки (чего у ТС явно нет).

в том-то и дело, что есть.

я их собственными руками готовил и уверен в их идентичности. тем более, через них таким макаром уже не один десяток проектов прошел без проблем. но все они были либо на qmake, либо на autotools

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

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

Ну вот есть у тебя хеш-код ревизии, компилятора и всего остального (к примеру на нашем проекте это собрано в хеш-код манифеста в repo). И есть собранный бинарь. Как проверить, что бинарь собрался честно из этой ревизии?

Вообще у ТС система инвариант, соответственно ожидается тот же бинарный выхлоп. Если конечно в тулчейне не используются таймстампы, нарушающие инвариантность, в чём я сомневаюсь.

абсолютную идентичность сред сборки (чего у ТС явно нет).

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

Идентичные системы сборки дают идентичные результаты.

при чем тут то, что ниже гипервизора?

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

P.S.: есть другие компоненты со схожим набором (тоже куте, qml плагины), но сборочная среда - qmakе - вышеозвученной проблемы нет, так что, склонен подозревать cmake.

qmake вызывает другой компилятор?

Ну вот есть у тебя хеш-код ревизии, компилятора и всего остального (к примеру на нашем проекте это собрано в хеш-код манифеста в repo). И есть собранный бинарь. Как проверить, что бинарь собрался честно из этой ревизии?

Нужно раскрутить систему ровно с такими же компонентами и собрать бинарь. Я угадал?

Идентичные системы сборки дают идентичные результаты.

совершенно верно. и я бы усомнился в их идентичности, если бы это была не единственная проблема!

На одной и той же машине две компиляции (с очисткой между ними) дают одинаковые бинарники или разные?

там нет другого компилятора :) ровно один.

на одной и той же - одинаковые даже после полной очистки.

я бы усомнился в их идентичности, если бы это была не единственная проблема!

Мммкей... кто-то из коллег просто решил над тобой подшутить %)

Ну, тогда шайтан.

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

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

Версия CMake действительно протухшая. Так или иначе стоит понять причину. Порядок линковки действительно неопределён в CMake-скриптах, но он должен быть в моём понимании псевдослучайным, а не случайным. Пусть не в вашем проекте, но если проблема всё ещё существует (на дворе уже CMake 3.x), стоит сообщить разработчикам или починить самому.

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

Предлагаю накатать простой helloworld, который скомпиляется просто из командной строки (без всяких cmake, qmake и даже просто make). На нем и проверить — совпадут ли контрольные суммы.

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

там выше писал, проекты на autotools и qmake такую проверку проходят на ура.

Тогда сразу переходи к helloworld'у на cmake.

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

А то, может, это какое-нибудь культе-шмульте говно мудрит, а ты проблему не в том месте ищешь?

Помню в своё время тоже занимался сравнением link.txt, но проблемы со случайным порядком линковки не наблюдал. Возможно это давно исправлено.

Это не тебе вопрос

действительно.. но я внес уточнение :)

таймстампы тоже никто в объектники не вкомпиливает )

Не, это просто CMake говно. Оно мне вообще иногда зависимости своим «ацикличным графом» в неправильном порядке выставляло. Так, что нифига не линковалось. Надоело трахаться с этим непотребством, перешел на QMake.

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

Если интересно, это проект marble, который мы по неволе расширяем. Но там всё сложно. ;)

Директори на машинах одинаковые? Собирается не в дебаге? Линкер очень любит пихать абсолютные пути к библиотекам.

нет, в релизе. но пути одинаковые везде - машины идентичны )

Уже катали - все ок. Собирается корректно. КС все время одинаковые, но вот с marble такая фигня не проходит. В mail-list marble тоже писали, ответа нет: http://blog.gmane.org/gmane.comp.gis.marble.devel