Собирать релиз с дебаг-инфой, возможно выгруженной в отдельный файл.

dbg-пакетам уже лет 100.

Но не вся инфа выгружается.

Какая не выгружается?

Не знаю какая именно. О том, что не вся, написано даже в доках по GCC. Ну и размеры билдов разные.

Ясно.

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

Для венды делаю так:
- номер сборки = хэшу коммита из которого собрана версия, когда происходит крэш, требую его назвать
- при сборке генерируется дебаг инфа отдельно в .pdb
- помимо этого в msvc генерирует .map и .cod файлы, содержащие адресса функций и ассемблер + исходники.
Эти, сгенерированные при сборке, файлы я естественно храню для каждого релиза, и когда получаю крэшдамп и номер сборки то беру нужную мне дебаг-информацию и нахожу где упало.

для gcc наверное как-то так:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html...
http://stackoverflow.com/questions/866721/how-to-generate-gcc-debug-symbol-ou...

-g при сборке должен быть включен всегда. Это и есть весь твой бест-практик. Нормальный пакетный менеджер при упаковке отрежет отладочную информацию и упакует нестрипанные бинарники и исходники в отдельный пакет с тем же n-v-r, что и у основного, который нужно будет доустановить желающим для post-mortem отладки с коркой в gdb.

Вот, а как сказать cmake'у не просто вырезать инфу, а собирать из нее отдельный пакет?

Почему не делать сборку не в Release, а в RelWithDebInfo? CMake так умеет.

Вот, а как сказать cmake'у не просто вырезать инфу, а собирать из нее отдельный пакет?

это не по части cmake-а, это дебовские утилиты умеют, к примеру

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

Настоящему индейцу надо только одного

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

Вот, а как сказать cmake'у не просто вырезать инфу, а собирать из нее отдельный пакет?

Это забота не CMake, а сборщика пакетов. В Debian (debhelper) в debian/rules добавляются строчки:

override_dh_strip:
        dh_strip $@ --dbg-package=package-dbg

и при сборке он генерирует package-dbg с нестрипнутыми бинарниками.

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

У меня система собрана с -g

если без splitdebug, то ты лох

Это я тоже знаю. Но у нас генерируются 2 пакета, и rpm, и deb. И оба средствами cmake, а точнее cpack. И вот хорошо бы через него сделать.

Почему?

хотя бы потому, что бинари стрипаются по дефолту, не?

не

не

Интересует бест-практик. Как вообще люди делают? Собирать релиз с дебаг-инфой, ... выгруженной в отдельный файл

Вот так и делают.