инкрементальная сборка и отладка

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

SSD/xoreax incredibuild/etc. Но 26 секунд - это копейки.

конечно за все пакеты никто не даст гарантию, ведь их написали разные авторы

например сам QtCreator собирается с вызовом git, об этом в окне about написано (бинарник с ихнего сайта)
мне это удобно и допустимо, при необходимости могу найти нужный коммит, не мешает ничем
как там сделано, если собирать из tar не выяснял

тебе такие сборки неудобны, ок я понял

Нет, они его просто собирают $ qmake_qt5 IDE_REVISION=1398a3ced33b , где номер ревизии указывают скорее всего руками\автоматизированно. Но никаких автоматических обращений к гиту из скриптов сборки qt-creator нет.

В пакетах же дистров просто делают $ qmake_qt5 , не задают IDE_REVISION, поэтому его в окошке about не видно.

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

А точно там полный перезапуск? На оффтопике в студиях не факт что выполнялась пересборка и перезапуск. В большинстве случаев компилировался конкретный файл(ы) .c/.cpp и отладчик патчил существующий процесс. Если не везло, наменялось так что просто не пропатчишь - так и говорилось «не могу на ходу, перезапустись». Опция «инкрементальности» тут как-бы ни при чем, тут больше играла роль опция вида/формата отладочной информации(/Zi /Zi, «Edit and Continue»). Так что похоже больше вопрос к самому отладчику/среде на сколько они хорошо интегрируюются с билд системой(Студия очевидно очень хорошо интегрируется).

А точно там полный перезапуск?

Да. Я не про опцию «Edit and Continue», а про остановку и запуск отладки заново. Если поменялся один файл, то только он один и перекомпилируется\перелинковывается. Завтра проверю как ведёт себя MSVC с этим проектом.

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

За ублюдство с вызовом git'а в сборке я вообще бы руки отрывал.

Мне тоже не нравится. Но что делать, если нужно проставить версию компилируемого? Мы ведь отказались от cvs, subversion, так что теперь у нас не привычные просто инкрементируемые 1, 2,.. 123, 124,.., а АбраКадабра какая-то вместо версий.

Видимо комп медленный, надо кору поновее воткнуть.

slovazap:

С другой стороны да - если файл компилируется 13 секунд, процессор явно староват.

По-моему, это не процессор старый, а С++ разбухший до неприличного. Скоро ИИ понадобится, чтобы скомпилировать. (В Дебиане иногда сервер сборки не может осилить фаерфокс или хромиум.)

Мне, кстати, попался исходничек на где-то 100 КБ, который компилировался несколько минут с потреблением нескольких гигабайт оперативки. Всё никак не соберусь топик сделать: интересно, народ найдёт там виновного (одно дело запустить профайлер на своей тормозной проге, а другое - профайлить... компиляцию. Не слышал ещё, как это делать).

Вот сборка trojita под линуксом:

$ time make
[...cut...]
real    11m26.519s
user    10m6.788s
sys     0m44.432s
$

А вот ещё раз, ничего не меняя:

$ time make 2>&1 | tee ../build-log-2.txt
[  1%] Automatic moc for target AppVersion
[  1%] Built target AppVersion_automoc
[  1%] Automatic moc for target Common
[  1%] Built target Common_automoc
[  2%] Generating version_fake_file, trojita-version.h, trojita-git-version.h
[  2%] Built target version
Scanning dependencies of target Common
[  2%] Building CXX object CMakeFiles/Common.dir/src/Common/Application.cpp.o
[  2%] Linking CXX static library libCommon.a
[  4%] Built target Common
Scanning dependencies of target AppVersion
[  4%] Building CXX object CMakeFiles/AppVersion.dir/src/AppVersion/SetCoreApplication.cpp.o
[  4%] Linking CXX static library libAppVersion.a
[  4%] Built target AppVersion
[  4%] Automatic moc for target Composer
[  4%] Built target Composer_automoc
[  4%] Automatic moc for target Imap
[  4%] Built target Imap_automoc
[  4%] Automatic moc for target Plugins
[  4%] Built target Plugins_automoc
[  5%] Built target Plugins
[  5%] Automatic moc for target Streams
[  5%] Built target Streams_automoc
[  8%] Built target Streams
[  8%] Automatic moc for target UiUtils
[  8%] Built target UiUtils_automoc
[ 10%] Built target UiUtils
[ 32%] Built target Imap
[ 32%] Automatic moc for target qwwsmtpclient
[ 32%] Built target qwwsmtpclient_automoc
[ 33%] Built target qwwsmtpclient
[ 34%] Automatic moc for target MSA
[ 34%] Built target MSA_automoc
[ 36%] Built target MSA
[ 39%] Built target Composer
[ 40%] Automatic moc for target Cryptography
[ 40%] Built target Cryptography_automoc
[ 42%] Built target Cryptography
[ 42%] Automatic moc for target DesktopGui
[ 42%] Built target DesktopGui_automoc
[ 43%] Automatic moc for target IPC
[ 43%] Built target IPC_automoc
[ 44%] Built target IPC
[ 59%] Built target DesktopGui
[ 59%] Automatic moc for target be.contacts
[ 59%] Built target be.contacts_automoc
[ 59%] Automatic moc for target trojita_plugin_AbookAddressbookPlugin
[ 59%] Built target trojita_plugin_AbookAddressbookPlugin_automoc
[ 61%] Built target trojita_plugin_AbookAddressbookPlugin
[ 62%] Built target be.contacts
[ 62%] Automatic moc for target fake-dev-random
[ 62%] Built target fake-dev-random_automoc
[ 63%] Built target fake-dev-random
[ 63%] Automatic moc for target test_Composer_Submission
[ 63%] Built target test_Composer_Submission_automoc
[ 63%] Automatic moc for target test_LibMailboxSync
[ 63%] Built target test_LibMailboxSync_automoc
[ 64%] Built target test_LibMailboxSync
[ 64%] Linking CXX executable test_Composer_Submission
[ 65%] Built target test_Composer_Submission
[ 65%] Automatic moc for target test_Composer_responses
[ 65%] Built target test_Composer_responses_automoc
[ 65%] Linking CXX executable test_Composer_responses
[ 66%] Built target test_Composer_responses
[ 66%] Automatic moc for target test_Cryptography_MessageModel
[ 66%] Built target test_Cryptography_MessageModel_automoc
[ 66%] Linking CXX executable test_Cryptography_MessageModel
[ 67%] Built target test_Cryptography_MessageModel
[ 68%] Automatic moc for target test_Cryptography_PGP
[ 68%] Built target test_Cryptography_PGP_automoc
[ 68%] Built target crypto_test_data
[ 68%] Linking CXX executable test_Cryptography_PGP
[ 69%] Built target test_Cryptography_PGP

[... для кучи ZZZ: ...]

[ 70%] Automatic moc for target ZZZ
[ 70%] Built target ZZZ_automoc
[ 70%] Linking CXX executable ZZZ
[ 70%] Built target ZZZ

[...cut...]

[ 97%] Automatic moc for target trojita
[ 97%] Built target trojita_automoc
[ 97%] Automatic moc for target trojita_plugin_ClearTextPasswordPlugin
[ 97%] Built target trojita_plugin_ClearTextPasswordPlugin_automoc
[ 98%] Built target trojita_plugin_ClearTextPasswordPlugin
[ 98%] Linking CXX executable trojita
[ 99%] Built target trojita
[ 99%] Automatic moc for target trojita_plugin_QtKeychainPasswordPlugin
[ 99%] Built target trojita_plugin_QtKeychainPasswordPlugin_automoc
[100%] Built target trojita_plugin_QtKeychainPasswordPlugin

real    0m43.447s
user    0m36.024s
sys     0m4.700s
$

Да-с. Проекту исполнилось недавно 10 лет (судя по первому коммиту), а процесс сборки какой-то совсем сырой. Похоже, там всё перелинковывается. Но зачем?

По крайней мере, можно отключить сборку тестов: -DWITH_TESTS=OFF.

Мне, кстати, попался исходничек на где-то 100 КБ, который компилировался несколько минут с потреблением нескольких гигабайт оперативки

svgpp?

профайлить... компиляцию. Не слышал ещё, как это делать

-ftime-report?

Мне, кстати, попался исходничек на где-то 100 КБ, который компилировался несколько минут с потреблением нескольких гигабайт оперативки. Всё никак не соберусь топик сделать: интересно, народ найдёт там виновного

виноват очевидно разработчик
а по мнению slovazap - «Так что свое видение разработчик должен свернуть в трубочку и засунуть себе поглубже, а сборку сделать по-человечески.»
)

Но что делать, если нужно проставить версию компилируемого?

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

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

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

АбраКадабра какая-то вместо версий.

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

Нужно использовать теги. Установка тега как-раз включает соображалку: а что собственно я тегирую? Был ли это успешно проходящий автотесты билд? Или, может, отдаваемый тестировщикам? Или фиксирую коммитом насранные в рабочей копии изменения, что бы поотлаживаться? Для последнего случая преимущество тега перед автоматическим безусловным взятием номера ревизии в том, что тегирование приобретает определенность, изменения фиксируются коммитом. Понятно, что такой тэг может быть и номером коммита, но это, повторюсь, не делается автоматически системой сборки. Это атоматизированный процесс отладки.

если нужно проставить версию компилируемого?

Не нужно. Есть официальная версия X.Y.Z, зашиваете её в CMakeLists.txt откуда она попадает в код, doxygen и т.д. через configure_file. Никаких коммитов вам зашивать не нужно.

Мы ведь отказались от cvs, subversion, так что теперь у нас не привычные просто инкрементируемые 1, 2,.. 123, 124,.., а АбраКадабра какая-то вместо версий

Не надо путать версию и номер/хэш коммита.

Так в том то и дело, что компилируется не официальная версия, а промежуточная (snapshot), которую можно идентифицировать только по хешу коммита. И вот последнее под вопросом: как обойтись без git в этом случае?

По номеру билда, проставляемую тем что его собирает (CI вероятно) через флаг сборки. А вообще же, в современном мире снапшоты не нужны, нужны частые релизы.