Системы сборки

Ты неосилятор. Аналогов cmake нет, всё остальное - убогое говно.

Пробывал cmake. По ощущениям громозкое говно мамонта

Это у вас что-то со вкусовыми рецепторами.

пробывал

дальше даже читать не стал

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

ну и set(name value) - уще то убожество.

С нетерепением жду релиза qbs.

Нельзя сделать сразу проект под несколько платформ (64 и 32 бита). Хотя может я неасилятор, кто подскажет, скажу спасибо.

Вызываешь для конфигурации проекта под x86

cmake -DENABLE_BUILD_X86

А в CMakeLists.txt проверяешь значение ENABLE_BUILD_X86 если true, то добавлешь к компилеру флажок -m32, если нет, то -m64 что там тебе надо.

Team Foundation Server

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

В смысле? Если ты меняешь конфигурацию сборки, то желательно удалить CMakeCache.txt, а лучше её вообще не менять (см. ниже).

Нельзя сделать сразу проект под несколько платформ (64 и 32 бита).

Идеология cmake: одна директория — одна конфигурация. Я делаю так:

projects/project/src
projects/project/gcc-release
projects/project/gcc-debug
projects/project/clang-release
projects/project/clang-debug

projects/project/gcc-release-32
projects/project/gcc-debug-32

А как там scons поживает? Не пробовал?

может я неасилятор

Есть такое. Советую сначала осилить русский язык.

А мне cmake нравится. Удобная штука: один раз набросал себе шаблон, а потом пользуешься им, немного модифицируя.

Autoconf/Automake

всё остальное ересь

Autoconf/Automake

Громоздко, медленно и хреново.

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

Вот мне тоже так показалось. Мне понравилось что он умеет генерить проекты для VS.

С нетерепением жду релиза qbs.

А в дорелизном состоянии qbs юзабелен?

А в CMakeLists.txt проверяешь значение ENABLE_BUILD_X86 если true, то добавлешь к компилеру флажок -m32, если нет, то -m64 что там тебе надо.

Вопрос не в этом. Я хочу чтобы сразу получались release и debug на 32 и 64 бита (того 4 варианта). Плюс под макосью можно делать жирный бинарь в котором 32 и 64 куском.

И еще я не хочу ничего знать про флажки. Нафига этот CMake нужен, если флажками можно махать из простого makefile.

Как только шаг в сторону - так обыкновенный make сразу на порядок удобнее.

А что такое обыкновенный make? Их же там over9000 разных диалектов. Да и эти «нестандартные» ситуации приводят к скрещиванию «обыкновенного» make с bash-скриптами со всеми вытекающими некроссплатформенными последствиями. Поэтому мне cmake удобнее и для нестандартных ситуаций.

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

В смысле? Если ты меняешь конфигурацию сборки, то желательно удалить CMakeCache.txt, а лучше её вообще не менять (см. ниже).

В смысле что в VS получается 4 конфига: Debug, Release, MinSizeRel, RelWithDebInfo из которых мне нужны только первые два. RelWithDebInfo под VS просто привет из 90х, поскольку pdb делается и для релиза.

Я просто думал что CMake'ом можно сделать Release|Win32, Release|x64... как в VS по умолчанию принято.

Идеология cmake: одна директория — одна конфигурация. Я делаю так:

Спасибо. Я правильно понимаю что если есть библиотека foo и программа bar, то мне надо сделать:

add_library(foo-release-32 SHARED ${FOO_SRC))
add_library(foo-debug-32 SHARED ${FOO_SRC))
add_library(foo-release-64 SHARED ${FOO_SRC))
add_library(foo-debug-64 SHARED ${FOO_SRC))

add_executable(bar-release-32 SHARED ${BAR_SRC))
target_link_libraries (bar-release-32 foo-release-32)
...

Да чего-то тянут с qbs, уже больше полгода, как представили...

RelWithDebInfo под VS просто привет из 90х, поскольку pdb делается и для релиза.

Разве в Release делаются pdb? Я всегда пользовался RelWithDebInfo.

Спасибо. Я правильно понимаю что если есть библиотека foo и программа bar, то мне надо сделать:

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

А как там scons поживает? Не пробовал?

Пробовал. Только оно не совсем то что я хочу. Scons это что-то типа кросс-платформенных autotools+make в одном флаконе. Мне удобнее чтобы на выходе из тулзы под виндой был VS solution, под маком XCode workspace, в линуксе makefile. Ну может еще потенциально eclipse.

Зачем тебе одновременно и релиз, и дебаг? Пока отлаживаешь, собираешь как-то так:

cmake . -DEBUG=1
make

cmake . && make && su -c "make install"

в VS получается 4 конфига

Да уж, забавные вы, вендузятники.

Разве в Release делаются pdb? Я всегда пользовался RelWithDebInfo.

В VS2010, если проект сделать самой студией, то pdb генерится и можно будет ходить по нему отладчиком. Правда удовольствие ниже среднего из-за оптимизаций. Не знаю как для EXE, для DLL делается по-умолчанию точно.

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

То есть из каждой директории мне надо сделать «cmake -DCMAKE_BUILD_TYPE=XXX -DYYY ../..»? Суровая партия.

из каждой директории мне надо сделать «cmake -DCMAKE_BUILD_TYPE=XXX -DYYY ../..»?

Нет. Тебе это надо в корне проекта делать. А cmake на основе твоего «CMAKE_BUILD_TYPE=XXX» сгенерирует правильный makefile и положит все файлы в нужную директорию. Только нафига так делать?

То есть из каждой директории мне надо сделать «cmake -DCMAKE_BUILD_TYPE=XXX -DYYY ../..»? Суровая партия.

Да. Но это делается один раз. А еще можно в директории сборки держать какой-нибудь settings.cmake со всеми нужными флагами и при наличии его подключать в корневом CMakeLists.txt.

Тебе это надо в корне проекта делать

Не в корне проекта, а в директории сборки, которая _должна_ отличаться от корня проекта.

Ну, это кому как. Мне удобнее в корне проекта. А директория сборки автоматом создается. В корне лежит общий CMakeLists.txt и всякие там README, в src лежат исходники и «дочерний» CMakeLists.txt, в src/include — заголовочные файлы. Делаю cmake -D... . в директории проекта, получаю нужный makefile.

Зачем тебе одновременно и релиз, и дебаг? Пока отлаживаешь, собираешь как-то так:

Прогнать тесты во всех конфигах нажатием одной кнопки.

а в релизе просто пользователь будет писать
Да уж, забавные вы, вендузятники.

Забавные вы, линуксоиды. Хотите заставить все человечество писать какие то команды.

Делаю cmake -D... . в директории проекта, получаю нужный makefile.

А профили как разделять при таком подходе? А мусор после сборки как удалять? Нет, это не правильно и топикстартеру такой вариант не подойдет.

А профили как разделять при таком подходе?

А зачем мне их разделять? Я же говорил: пока отладка, делаю «cmake -DEBUG=1 .», потом make и запуск столько раз, сколько нужно. А если не писать "-DEBUG=1", будет обычный «релиз» без отладочной информации.

А мусор после сборки как удалять?

F8 в mc ☺

Да. Но это делается один раз. А еще можно в директории сборки держать какой-нибудь settings.cmake со всеми нужными флагами и при наличии его подключать в корневом CMakeLists.txt.

Класс! Спасибо за помощь. Я действительно не понимал политику партии и пытался все упихать в одно.

А зачем мне их разделять?

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

делаю «cmake -DEBUG=1 .»,

Ты к cmake еще своих велосипедов прикрутил?

F8 в mc ☺

Ога, это конечно очень удобно делать, нормальные люди делают rm -rf build-release.

Два настроенных профиля держать всегда удобней.

Зачем?

Ты к cmake еще своих велосипедов прикрутил?

С чего бы это — велосипед? Обычный макрос для отладки. А в коде — проверка этого макроса и определение команды DBG, которая отладочные сообщения выдает.

нормальные люди делают rm -rf build-release

Ну так по желанию можно сделать отдельную директорию и оттуда писать cmake ..

Не эстетствуй: откуда хочется, оттуда cmake и запускается.

А делается это примерно так

# в корневом CMakeLists.txt
if (EXISTS "${CMAKE_CURRENT_BINARY_DIR}/settings.cmake")
	include(${CMAKE_CURRENT_BINARY_DIR}/settings.cmake)
endif()

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

Зачем?

Чтобы каждый раз не перенастраивать и не пересобирать весь проект. У меня в текущем проекте пересборка полная занимает две минуты.

Увидел багу -> пошел в build-debug -> нашел с помощью gdb -> пофиксил -> отправился назад в build-release и продолжаешь работать с оптимизированной сборкой

Обычный макрос для отладки

Такой уже есть. -DCMAKE_BUILD_TYPE=Debug

А в коде — проверка этого макроса и определение команды DBG, которая отладочные сообщения выдает.

Ты еще скажи, что всякие -g -O0 сам пишешь, а не полагаешься на cmake.

Не эстетствуй: откуда хочется, оттуда cmake и запускается.

Я говорю как проще.

Такой уже есть. -DCMAKE_BUILD_TYPE=Debug

Мне лень было читать документацию, чтобы понять, с каким флагом будет вызван gcc при таком раскладе. Что в коде писать: #ifdef что?

Ты еще скажи, что всякие -g -O0 сам пишешь, а не полагаешься на cmake.

Сам пишу. Откуда он знает, что мне нужно обязательно писать

-Wall -Werror -O3

Или там тоже какие-то инструкции на этот счет есть?

Что в коде писать: #ifdef что?

По стандарту в Release сборке определяется NDEBUG.

Сам пишу. Откуда он знает, что мне нужно обязательно писать

В Release так и будет кроме -Werror, который можно добавить руками. А в Debug, естественно, будет -O0.

в Debug, естественно, будет -O0

А мне неестественно. Я же не программист. И gdb/valgrind/etc пользоваться не умею.

qmake?

Я тоже не программист, а математик, однако понимаю, что Debug сборка сделана для отладки и собирать её с оптимизацией — глупо.

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

Бред. Как только проект начинает зависеть от какой-либо библиотеки, про make можно забыть. Подходит он только когда нужно собрать проект из десятка файлов, без зависимостей и без каких-либо условий в makefile.

ну и set(name value) - уще то убожество

Нет.

С нетерепением жду релиза qbs.

Глянул qbs. Очень похоже на scons в том смысле что это не генератор, а полностью автономная система сборки, которая сама конфигурит исходники, строит зависимости, дергает компайлер и.т.п. Возможно, подход он правильный и нужный, но мне больше нравится когда генерируются родные для системы makefile/solution/workspace. В последнем случае можно и из IDE собрать и, если требуется, автоматически. Хотя если в qbs вкрутят генераторы, может быть интересно.

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

Да-да. Щаз. Если конфигурация системы хоть немного отличается от той на которой сидит девелопер, то начинается реальный бред. Именно поэтому вместо того чтобы использовать CMake findXXX ребята из Kitware тупо кладут все third-party исходники в дерево VTK с соответствующими CMakeLists для них.

qmake

Не. Он совсем Qt прибитый и не скриптуемый. Хотя со времен Qt3 много что могло поменяться. Как оно сейчас?

А в дорелизном состоянии qbs юзабелен?

Что значит юзабелен? Посмотреть и заценить можно. Надеятся, что будет работать без багов - нет!

Вопрос не в этом. Я хочу чтобы сразу получались release и debug на 32 и 64 бита (того 4 варианта).

CMake, как и любая другая программа, делает не то что пользователь ХОЧЕТ, а то, что пользователь ПРИКАЗАЛ делать. Не больше и не меньше!

Напиши уже скрипт, который будет продергивать CMake/make для нужного тебе числа конфигов и не морочь голову.

QT -= core gui

больше наш проект не зависит от Qt.

Не очень понятно, что подразумевается под скриптованием.
ЕМНИП, сейчас он поддерживает if-ы и foreach-и.

А что такое обыкновенный make? Их же там over9000 разных диалектов.

Я не такой знаток make, чтобы различать диалекты.

Да и эти «нестандартные» ситуации приводят к скрещиванию «обыкновенного» make с bash-скриптами со всеми вытекающими некроссплатформенными последствиями.

Из CMake bash и прочие системнозависимые команды тоже можно вызвать, было бы желание. Проблемка токлько в том, что в CMake для этого прийдется больше печатать.

Я не такой знаток make, чтобы различать диалекты.

Всё что отлично от примитивного

a.1: b.2
   command -i b.2 -o a.1

различается в различных мейках

Из CMake bash и прочие системнозависимые команды тоже можно вызвать, было бы желание.

Можно, но не нужно, так как доступ к файловой системе есть и без этого.

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

Раскажи это программерам с гугла, которые андроид со всеми библиотеками и програмами собирают с помощью make.

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

Посмотреть и заценить можно.

Уже, см выше.

...не то что пользователь ХОЧЕТ, а то, что пользователь ПРИКАЗАЛ делать...

Reset уже все растолковал. Я не понимал CMake'овой идеологии на предмет многих платформ/конфигов.

онимаю, что Debug сборка сделана для отладки и собирать её с оптимизацией — глупо.

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

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

-DCMAKE_BUILD_TYPE=RelWithDebInfo

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

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

Тут соглашусь, в CMake «стандартные» библиотеки подключаются на порядок удобнее. Но это не значит, что с помощью make невозможно сделать тоже самое. Если у меня стоит выбор между CMake и make, то я не задумываясь выберу первый. Но это не значит, что мой выбор идеален. У CMake достаточно недостатков, но, увы, ничего лучше нету.

Не очень понятно, что подразумевается под скриптованием.

Например посмотреть есть ли в системе Intel MKL/IPP и использовать их. Если система на AMD, то пользовать OpenBLAS/ATLAS. Скажем в premake и cmake с этим никаких проблем.