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

Изкаробки ничего это не умеет.
Если есть простые утилиты, которые могут это выяснить, то можно запустить их через system(detector_utilite), получить результат выполнения и дальше if-ами.

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

Ну не без этого. Но все же лучше, чем ничего. Вот, к примеру, на прошлой неделе я словил креш в коде черт знает какой сторонней библиотеки. Креш проявлялся только в релизной сборке. Что еще оставалось делать, кроме как собирать RelWithDebInfo?

Что еще оставалось делать, кроме как собирать RelWithDebInfo?

Да, только так. Более того, я в продакшен собираю пакеты _только_ с RelWithDebInfo, иначе концов потом не найдешь в случае чего. Символы, естественно, выделяются в отдельный пакет.

Да, ты неосилятор. CMake ты вообще не понял. Посмотри на то, как он используется в LLVM и Clang.

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

И как же «обыкновенный make» сделает проект для M$VS, XCode и Eclipse CDT разом из одного исходника? Сдается мне, что ты просто тупой.

Насчет «шаг в сторону» - смотри на LLVM, там тебе и кросс-компиляция со сборкой нативных версий некоторых бинарников, и TableGen, и сложная система тестов. И все на CMake.

А вообще, на хера ты собираешь в той же директории, где исходники?

И как же «обыкновенный make» сделает проект для M$VS, XCode и Eclipse CDT разом из одного исходника?

Кто сказал анонимоусу, что make должен что-то генерить?

А вообще, на хера ты собираешь в той же директории, где исходники?

Кто тебе это сказал?

Посмотри на то, как он используется в LLVM и Clang.

LLVM собирает только одну конфигурацию. Прочитай выше в чем был вопрос.

Я вообще после maven не могу смотреть ни на cmake, ни на make... я испорченный человек.

QT -= core gui

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

Но удобных FindLibrary из CMake и др. от этого все равно не появится. Как и CPack'a, который умеет упаковывать в кучу форматов (и CDash'a, и CTest'a тоже).

Ты что, тупой?

mkdir debug; cd debug; cmake -G"Unix Makefiles" ..; cd ..

mkdir release; cd release; cmake -G"Unix Makefiles ..; cd ..

maven может проект для Xcode создать? Нет? Давай, до свидания!

Ты дебил. Полный. Не программируй больше.

Но удобных FindLibrary из CMake и др. от этого все равно не появится. Как и CPack'a, который умеет упаковывать в кучу форматов (и CDash'a, и CTest'a тоже).

Ваша правда. Но вот насколько они нужны ТС это еще большой вопрос.

Ты что, тупой?

В интернете кто-то не прав, да? Эк тебе попу разворотило.

Есть экспериментальная qbs (часть проекта Qt), в которой не надо помнить ключи компилятора, можно сделать проект сразу под несколько платформ, инкрементальная сборка работает быстрее make (доли секунды вместо 5-10 секунд для сурьёзных проектов).

Но я не уверен, что она генерирует проекты для VS, Xcode и make, не слежу за развитием эксперимента, документации мало.

Я вообще после maven не могу смотреть ни на cmake, ни на make...

Это называется XML головного мозга (-:

maven вроде ни с чем кроме жабы не дружит =) может какой-нить jvm-ЯП тоже подцепит.

для сишки и крестов не годится...

не, XML тут ни при чём.

я вот ещё с аппетитом посматриваю на sbt, пока не пользовался. но это только scala/java. сишечка и кресты опять идут лесом.

дело не в ЯП, я думаю... думаю и для C/C++ можно было написать вменяемую систему сборки, но cmake для меня оказался слишком сложным и запутанным.

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

я вот ещё с аппетитом посматриваю на sbt, пока не пользовался. но это только scala/java. сишечка и кресты опять идут лесом.

А что, в sbt или maven нельзя сделать кастомное правило для генерации кастомной цели?

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

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

Но лично мне также интересно - насколько развито автоматическое редактирование через GUI?

Чтобы в идеале как у автора

• задание настроек без знания флагов компилятора: либо галочками, либо чтобы подходящие флаги предлагались вместе с кратким описанием, как это делает 'gcc --help=warnings'.
• типичная кроссплатформенная сборка также настраивалась через GUI и не требовала неожиданных действий типа ручного удаления CMakeCache.txt, будь то конфигурации под 32 и 64 бита, сборка под ARM с заливанием на устройство/без заливания или сборка под винду из линукса с переключением между mingw и clang.
• редактирование списка файлов, используемых при сборке

думаю, можно. не знаю. не копал. да и это не то уже будет.

да, там можно например тупо cmd-команду забить (есть plugins вроде)... по типу gcc blah.c -o blah, наверное... но тогда обо всех плюсах можно забить.

В sbt прикол вообще в том, что часть конфигов сборки можно писать на спец.языке конфигов (он похож на scala), а часть - на чистом scala. То есть особо изощрённый язык конфигов (как в случае с cmake) дополнительно учить не надо.

Написал программу на scala, и конфиг сборки тоже пиши на scala. :) В самых простых случаях можно тупо ничего не писать, само скомпилится - писать надо, если либы подключать, например...

я вот как-то мучился с cmake, пытался подключить cuda. нюанс скорее в кривости самой cuda... подключил, но всё равно это как-то выглядело криво через findCUDA (который в официальной поставке). И, кстати, с 5-й версией не взлетело (не копал, почему).

Вот типичный пример, что мне надо...

например, в /src все исходники, в /include все заголовки, хочу бинарники складывать в /bin (возможно отделив debug от release).

в cmake для этого каждый файл прописывал отдельно, кроме того, те файлы, которые с расширением *.cu - с ними дополнительные танцы были нужны.

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

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

Нет ничего невозможного!

file(GLOB MY_SOURCES src/*.cpp)

автоматическое редактирование через GUI

Зачем?

А можно вот так:

aux_source_directory(. SOURCES)

Кстати, вот еще удобная штука:

if(NOT DEFINED PROCESSOR_COUNT)
  set(PROCESSOR_COUNT 2) # by default 2 cores
  set(cpuinfo_file "/proc/cpuinfo")
  if(EXISTS "${cpuinfo_file}")
    file(STRINGS "${cpuinfo_file}" procs REGEX "^processor.: [0-9]+$")
    list(LENGTH procs PROCESSOR_COUNT)
  endif()
endif()

Зачем?

Работал в паре с одним человеком над первым проектом, взялись за второй. Напарник больше склоняется к вебу и был необходим для проекта, т.к. имел опыт работы с mysql. Я присоединился позже, т.к. возникли проблемы с C++ и конкретно в тонкостях QtCreator, которым он пользовался по моему совету (qmake как система сборки).

Если бы пересборка происходила через консоль, на каждый добавленный файл пришлось бы дописывать скрипты (с граблями, которые пару часов уж точно могут отнять), то когда разрабатывать? Да и человек просто не согласится делать вручную то, что в вебе и XCode издавна делается автоматом.

Вообще, сборочная система без GUI означает почти нулевой приток молодёжи в эти проекты, нулевую применимость в образовании для демонстрации чего-либо, кроме самой системы сборки и невозможность работы в сжатые сроки/в составе разношёрстной команды/с привлечением программистов с опытом в БД, графике или моделировании, но без опыта устранения проблем целевой платформы.

Ох уж эти вантузятнечки...

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

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

Ты намекаешь на переход на слаку?

maven вроде ни с чем кроме жабы не дружит =) может какой-нить jvm-ЯП тоже подцепит.

И ещё он не шибко дружит с теми jar'ками, которых нету в репах мавена.

А на кой нужна такая молодежь? Пусть идут раздавать листовки, ну или там в макдональдс. Где там еще нынче дебилы нужны?

А на кой нужна такая молодежь?

M$ без нее загнется ☺

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

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

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

Вангую, что вы вообще не представляете как работает нормальный GUI (про дефолтный гуй git, например, речь не идёт). Просвящайтесь, читайте Алана Купера, знакомьтесь с другими программистами и прекратите писать слово «дебилы», а также все его производные из-под анонима. Вы слишком напряжены.

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

вы вообще не представляете как работает нормальный GUI

А где есть нормальный GUI для управления конфигурациями проектов? В MSVS с кучей окошек фиксированного размера разбираться куда менее удобно по сравнению с CMakeLists.txt файлами.

эх, когда-нибудь обязательно освою. C/C++ всё же нужны, кто бы там что не говорил

Заодно и кресты надо бы освоить.

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

Ты вообще ни хрена не знаешь про программирование.

Меня это устраивает, но есть тонкости, я тут порассуждаю немного, а заодно и kamre отвечу.

Система сборки проекта - это второстепенная программа, утилитка по сути. От программиста требуются знания того же C++ при работе с программой на плюсах, но вряд ли стоит называть его «дебилом» (как тут забаненный анонимус пишет) за неумение разобраться в утилитке. Отсюда несколько следствий.

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

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

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

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

Дабы не быть голословным, вот мои наработки по автодополнению qmake (это QtCreator, наработки размещены в плагине ProjectExplorer, так что ничто не мешает переиспользовать их для остальных поддерживаемых систем сборки типа cmake/autotools/qbs).

Скриншот. На нём:

1. редактор запрашивает флаги gcc через 'gcc --help=warnings'
2. редактор запрашивает пути поиска библиотек у тулкита (здесь gcc) и окружения, ищет по путям динамические библиотеки
3. ищет статические библиотеки
4. ищет пакеты посредством 'pkg-config --list-all'

Т.е. доступные варианты плюс краткая справка по ним без заглядывания в документацию и мучительной отладки скриптов сборки. А вот для нормальной диагностики пока ничего не придумал.

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

Дебил. Система сборки - часть семантики кода. А для C++ - очень важная часть.

вряд ли стоит называть его «дебилом» (как тут забаненный анонимус пишет) за неумение разобраться в утилитке

Неумение разобраться = дебилизм. По определению. Мразь не должна программировать.

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

Дебил. При добавлении файла не надо делать ВООБЩЕ НИЧЕГО.

Вот собственно я и спрашиваю, какие есть наработки в GUI для cmake?

CMake работает со всеми IDE, дебил.

Вполне устроило, только разработка походу сдохла.

4.2, сейчас активно пилится версия 5.

Один человек-проект

Неправда, контрибьюторов больше

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

А попытка реализовать кастомную логику на cmake обычно приводит к запутанному говонокоду, по сравнению с которым даже bash кажется хорошим решением

4.2, сейчас активно пилится версия 5.

Я посмотрел premake-dev. Как я понял, там что-то очень сильно поменяли на нижнем уровне, поэтому надо переделывать почти все actions для 5го релиза.

Неправда, контрибьюторов больше

Буду рад ошибаться на сей счет. Повторю, что мне лично premake очень и очень понравился. Прежде всего тем что он прост как грабли и делает свою работу. Особенно порадовало ядро на lua, что позволяет много чего сделать независимо от платформы прям не отходя от кассы. Клево то что выхлоп не зависит от платформы. Например можно сказать premake4 xcode под линуксом и это будет работать на маке. В CMake есть проблемы если я его пускаю из-под cygwin с генерацией VS, потому как он дергает компилятор.

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

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

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

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

Пользователей не так уж мало, просто они в основном сидят тихо и пилят свои корпоративные форки :)

Неправда, контрибьюторов больше

Хо-хо. Сэр, да вы и есть один из контрибьюторов!