LINUX.ORG.RU

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

 


1

4

Добрый вечер, граждане!

Есть одна проблема, но сначала вводная:
в наличии две совершенно идентичных виртуальных машины, с одной и той же ОС, установленной из одного и того же исошника. Для чистоты эксперимента, доступа к интернетам нет, обновляться не с чего. Всё, что можно поставить - на этом исошнике.

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

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

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

Так вот, вопрос как раз в этом: какого черта они различаются, и как это вылечить?

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

Изменить процедуру приёмки не представляется возможным. Вдоль, бочку и бежать оттуда не предлагать ;)

Заранее благодарен за различные подсказки.

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

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 3)
Ответ на: комментарий от aol

а дифф - там всего по одной строке. так что результат диффа - файлы различаются ;)

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

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

только если ты в один поток собираешь. Если в два и более, возможны варианты.

Тебе, конечно, нетрудно будет привести пример?

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

собрал CMake 3.1.0-rc2 на каждой машине из исходников. контрольные суммы его бинарей совпали.

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

facepalm.mkv.tar.bz2

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

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

Снова разница в Мейкфайлах? У меня подозрение на магию в CMakeLists.txt, к примеру сами исходники там могут искаться всякими aux_source_directory(). Советую кусками вырезать код из скриптов сборки и сравнивать результат, пока не найдётся виновник.

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

подозрение на магию в CMakeLists.txt

да. всё идет к этому. сейчас собрал марбл с ветки KDE/4.13 - там всё честно, все суммы совпали. сейчас мучаю ту самую sok2012-plasma-active или как там её, в которую мы вливали свои изменения. если на ней не воспроизведется, значит, у нас кто-то «разработал» магию ;)

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

ветка sok-2012-plasma-active на git://anongit.kde.org/marble - прОклятая :-D с неё не получается собрать бинари с одинаковыми контрольными суммами на разных контуперах.

Всем спасибо за участие! :)

//симейк всё равно - говнецо. я его не полюблю :-D

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

//симейк всё равно - говнецо. я его не полюблю :-D

Ложечки нашлись, но осадок остался? Ты ж отпишись когда найдёшь где собака порылась.

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

Не поверите, но для сертификаии софта и\или приемке его госструктурами вы должны представить к каждому файлу сорцов документашку и контрольные суммы получающихся бинарей (как и контрольные суммы каждого файла сорцов)

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

Ложечки нашлись, но осадок остался?

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

Тут всё еще усугубляется тем, что между облюбованной нами веткой sok-2012-plasma-active и веткой KDE/4.13 пропасть в почти три года. Разгребать всё это, довольно-таки муторно.. Боюсь всё закончится переносом наших правок на новую ветку. В апстрим их проталкивать некому, Деннис с непроизносимой фамилией сразу не согласился, а наши потом стухли и не настаивают.. :(

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

Мы у себя в проекте решили отказаться от Marble в пользу QtLocation для карт и геопозиционирования. Что у вас за задача такая, что вы на ветке 3-х летней давности сидите?

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

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

Немного деанона: товарисч SCAD принимал это судьбоносное решение, и если ему будет не лень сюда пару абзацев накласть, может, что и добавится к объяснению мотивов использования марбла. )

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

Дык. Только что отмазались от написания подобной херни для древнего как говно мамонта проекта на delphi на +300 файлов. Доказали начальнику, что писать по нему документацию (с учетом того, что проект писался силами 4х программистов разной умственной категории в течение 6 лет) мы будем больше года. Сошлись с заказчиком только на описании модуля расчета параметров вместо всей программы.

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