Comments 111
CMake — [средневековье] первая попытка уйти от низкоуровневых деталей make-а.
Зря вы, не разобравшись, списываете удобный инструмент.
Такой подход напоминает мне красивый фасад старого деревянного дома, который заботливо обшили свежим пластиком.
И все это следствия чуток кривоватой архитектуры, когда основная часть работы выполняется другими «помощниками».
Это называется unix-way: "Write programs that do one thing and do it well.". Cmake — это генератор. И у него хорошо это получается. Отслеживание зависимостей хорошо получается у make/ninja и других инструментов.
Под Linux все вроде бы хорошо, но если нужно построить тот же проект под Windows с помощью MSVC — а я предпочитаю нативный компилятор MinGW-шному, будут сгенерированы файлы для NMake
Cmake умеет генерировать не только nmake/make, но и проекты для MSVC (https://cmake.org/cmake/help/v3.12/manual/cmake-generators.7.html). Как-то так: cmake -G "Visual Studio 15"
Добавлю от себя, что на сегодняшний день CMake — единственный инструмент, который позволит вам написанием единственного билд-скрипта поддержать:
1. Windows + MSVC + Visual Studio
2. MacOS + Clang + XCode
3. Linux/MSYS + gnu toolchain (включая make) + (подставьте любую IDE, кроме перечисленных)
4. Какую-нибудь ninja или nmake — там есть и такие генераторы для любителей чего-то необычного
Во всех трех случаях, конечно, будут небольшие особенности (например, поддержка Debug/Release в MSBuild сделана не так, как у остальных), но все эти проекты будут успешно и совершенно одинаково собираться, одним и тем же способом тащить завиимости, запускаться и отлаживаться.
IMHO, если вы разрабатываете кросс-платформенный проект на C++, то на данный момент альтернатив CMake просто не существует.
1. Windows + MSVC + Visual Studio
2. MacOS + Clang + XCode
3. Linux/MSYS + gnu toolchain (включая make) + (подставьте любую IDE, кроме перечисленных)
4. Какую-нибудь ninja или nmake — там есть и такие генераторы для любителей чего-то необычного
Во всех трех случаях, конечно, будут небольшие особенности (например, поддержка Debug/Release в MSBuild сделана не так, как у остальных), но все эти проекты будут успешно и совершенно одинаково собираться, одним и тем же способом тащить завиимости, запускаться и отлаживаться.
IMHO, если вы разрабатываете кросс-платформенный проект на C++, то на данный момент альтернатив CMake просто не существует.
jam это который в Boost? Или есть еще какой-то с таким именем?
>Если говорить не о генераторах, а о нормальных билд системах
Смысл моего комментария состоял в том, что CMake — это именно генератор. И его основной смысл именно в этом. Билд-систем — завались. А вот сделать проект так, чтобы можно было его девелопить откуда попало можно только на CMake
Смысл моего комментария состоял в том, что CMake — это именно генератор. И его основной смысл именно в этом. Билд-систем — завались. А вот сделать проект так, чтобы можно было его девелопить откуда попало можно только на CMake
Мне нравился premake где-то лет пять тому назад, но с тех CMake стал чуть не стандартом де-факто (кого чаще всего видно в корне репозитория?), а premake до сих пор так и не вылез из состояния «вот-вот будет готово».
У CMake при всех его недостатках есть одно огромное преимущество — популярность. Теперь остальным инструментам недостаточно быть хорошими, придется предложить прямо какую-то киллер-фичу. А до тех пор люди будут готовы потерпеть синтаксис CMake ради того, чтобы проект в два щелчка открывался во всех популярных IDE на всех популярных ОС.
У CMake при всех его недостатках есть одно огромное преимущество — популярность. Теперь остальным инструментам недостаточно быть хорошими, придется предложить прямо какую-то киллер-фичу. А до тех пор люди будут готовы потерпеть синтаксис CMake ради того, чтобы проект в два щелчка открывался во всех популярных IDE на всех популярных ОС.
на данный момент альтернатив CMake просто не существует.
Возможно Вам стоит взглянуть на Sharpmake, продукт написанный и используемый внутри Ubisoft, недавно был опубликован на github. Не знаю можно ли тут выкладывать ссылку, легко гуглится. Хоть это и урезанная версия, например не содержит готовых настроек для консолей, но это из-за требований first party, что в прочем не мешает вам их добавить. В целом позволяет очень быстро генерировать огромные проекты под Visual Studio, XCode или makefile's, а главное очень гибкая и простая настройка т.к. все написано на C#, вы можете включить в генератор абсолютно любую логику, платформы и сборки.
Например на проекте в несколько миллионов строк кода, над которым я сейчас работаю, Sharpmake генерирует solution для Visual Studio под 5 различных платформ, debug|release|profile|retail + blob + fastbuild меньше чем за минуту на 8ми ядерном процессоре.
По первым трем пунктам Gradle вполне себе альтернатива — он все этом может.
А четвертый пункт для него не актуален т.к. он прдставлет собой полноценную билд систему, а не генератор.
А четвертый пункт для него не актуален т.к. он прдставлет собой полноценную билд систему, а не генератор.
Ещё забыли CMake в андроид проектах для C/C++ кода.
Был очень рад, когда `ndk-build` стало наконец можно выкинуть куда подальше и поддерживать весь список файлов/зависимостей/флагов/прочего в одном месте.
Был очень рад, когда `ndk-build` стало наконец можно выкинуть куда подальше и поддерживать весь список файлов/зависимостей/флагов/прочего в одном месте.
Зря вы, не разобравшись, списываете удобный инструмент.
Ну почему же не разобравшись? :) Не могу назвать себя продвинутым пользователем CMake, но писать несложные билд скрипты, а тем более пользоваться доводилось.
Просто те недостатки, которые, на мой взгляд, присущи CMake перевесили для меня его плюсы.
Это называется unix-way: «Write programs that do one thing and do it well.». Cmake — это генератор. И у него хорошо это получается. Отслеживание зависимостей хорошо получается у make/ninja и других инструментов.
Я ничего не имею против unix-way, но если мы говорим о системе сборки в целом, проектное решение в котором основную работу будет выполнять сторонняя тулза — мне несимпатично. Это жесткая зависисмоть на компонент, который развивается неазвисимо и поддерживается другой командой разработчиков. Такой подход делает архитектуру негибкой и в перспективе может тормозить развите проекта.
Никто не мешает внутри билд системы разбить ее на компоненты, каждый из которых будет хорошо выполнять свою работу, только разработчики всегда смогут договориться о взаимодействии компонентов внутри системы.
Cmake умеет генерировать не только nmake/make, но и проекты для MSVC (https://cmake.org/cmake/help/v3.12/manual/cmake-generators.7.html). Как-то так: cmake -G «Visual Studio 15»
Верно. Но строить здесь надо либо из самой IDE либо msbuild <имя проектного файла>. Снова зависимость на новую тулзу, снова другая команда для построение и снова это следствия архитектуры CMake.
на Windows потребует MinGW, но даже при его наличии откажется построить.
Вы просто не умеете его готовить.
Умею — кухня там довольно примитивная :) если сможете сконфигурировать NetBeans под Windows чтобы он не требовал MinGW и билдил проект произвольными командами — например, gradle assemble — расскажите обязательно, добавлю в плагин :)
без MinGW — можно указать путь к своему любимому tool collection:
билд проекта произвольными командами:
А еще у NetBeans killer feature — это кроссплатформенная удаленная разработка, то есть можно девелопить из любой хостовой ОС на удаленной машине с любой ОС лишь бы по ssh можно было достучаться.
P.S. картинки из интернета. Поверьте, MinGW и qmake тут совсем не обязательны.
билд проекта произвольными командами:
А еще у NetBeans killer feature — это кроссплатформенная удаленная разработка, то есть можно девелопить из любой хостовой ОС на удаленной машине с любой ОС лишь бы по ssh можно было достучаться.
P.S. картинки из интернета. Поверьте, MinGW и qmake тут совсем не обязательны.
А вот вам картинки не из интерента, а реальные :)
Прописываем команды gradle:
Это прекрасно работает на Linux.
Запускаем на Windows и видим:
Это при том что MinGW видится как доступный тулчейн:
Уточню что sh и bash доступны через PATH — из комплекта Виндового GIT-а.
Только спрашивается зачем NetBeans какие-то еще тулзы когда я уже явно указал ему что нужно запустить для постройки и очистки?
Подозреваю, что проблема вот в этом:
Вероятно, он зачем-то пытается еще выполнить какую-то, никому не нужную компиляцию проекта. Потому что если убрать эти дефолтные команды или изменить на gradle compileDebug он вообще отказываается строить даже под Linux.
Прописываем команды gradle:
Это прекрасно работает на Linux.
Запускаем на Windows и видим:
Это при том что MinGW видится как доступный тулчейн:
Уточню что sh и bash доступны через PATH — из комплекта Виндового GIT-а.
Только спрашивается зачем NetBeans какие-то еще тулзы когда я уже явно указал ему что нужно запустить для постройки и очистки?
Подозреваю, что проблема вот в этом:
Вероятно, он зачем-то пытается еще выполнить какую-то, никому не нужную компиляцию проекта. Потому что если убрать эти дефолтные команды или изменить на gradle compileDebug он вообще отказываается строить даже под Linux.
К сожалению, не имею опыта с gradle… Могу попробовать заставить его работать, если приведете ссылку на какой-нибудь «hello world» проект с инструкцией как его собрать из command line, я еще не встречал проект, который не собирался бы из NetBeans (challenge accepted). Это довольно мощный инструмент, изменить компилятор и команду сборки не должно быть проблемой, хотя я и не отрицаю возможных ограничений под Win.
Не возражаете если приведу проект «hello world» прямо здесь?
Это всего два файла будет:
build.gradle (в корневой папке):
и
src/main/cpp/main.cpp:
Нужно установить последнюю версию gradle (v5.2.1): gradle.org/install
Билдить из корневой папки (там где build.gradle):
Debug: gradle assemble
Release: gradle assembleRelease
Это всего два файла будет:
build.gradle (в корневой папке):
plugins {
id 'cpp-application'
}
и
src/main/cpp/main.cpp:
#include <stdio.h>
int main(void) {
printf("Hello, world!\n");
return 0;
}Нужно установить последнюю версию gradle (v5.2.1): gradle.org/install
Билдить из корневой папки (там где build.gradle):
Debug: gradle assemble
Release: gradle assembleRelease
Этот Ваш gradle вещь в себе не менее чем NetBeans под Windows.
Собрать hello world с полпинка из консоли у меня не получилось, но зато с полпинка получилось сделать тоже самое из NetBeans.
На этом умываю руки, ибо далее просто проблемы окружения.
Собрать hello world с полпинка из консоли у меня не получилось, но зато с полпинка получилось сделать тоже самое из NetBeans.
прилагаю картинку
На этом умываю руки, ибо далее просто проблемы окружения.
Ну gradle довольно внятно поругался что не смог найти в системе ни одного тулчейна для сборки: ни Visual Studio, ни MinGW, ни CLang.
Вполне законные требования, на мой взгляд :)
А Вы бы не могли еще выложить ваши настройки билд системы?
Какая версия NetBeans?
Система Windows 8 как я понял?
Вполне законные требования, на мой взгляд :)
А Вы бы не могли еще выложить ваши настройки билд системы?
Какая версия NetBeans?
Система Windows 8 как я понял?
mingw должен быть виден в системе из PATH, я gcc следующей же командой дернул из той-же консоли…
Product Version: NetBeans IDE 8.2 (Build 201705191307)
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
Java: 1.8.0_101; Java HotSpot(TM) 64-Bit Server VM 25.101-b13
Runtime: Java(TM) SE Runtime Environment 1.8.0_101-b13
System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
Почему gradle определил Win 8, я не знаю :)
Кстати, интерпретатор команд NetBeans потребовал только когда я попытался запустить встроенный терминал. То есть, Cygwin или MSYS не обязательны.
Product Version: NetBeans IDE 8.2 (Build 201705191307)
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
Java: 1.8.0_101; Java HotSpot(TM) 64-Bit Server VM 25.101-b13
Runtime: Java(TM) SE Runtime Environment 1.8.0_101-b13
System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
Почему gradle определил Win 8, я не знаю :)
Кстати, интерпретатор команд NetBeans потребовал только когда я попытался запустить встроенный терминал. То есть, Cygwin или MSYS не обязательны.
А еще интересно, какая у вас выбрана тема для подсветки синтаксиса?
И почему сам UI такой коричневый? Тоже тема?
И почему сам UI такой коричневый? Тоже тема?
Вот неплох Qt Creator, но настроить в нем работающий кит дикая проблема. То cmake подвисает, то ABI умудряется путать, то папку сборки наглухо отказывается перекэшировать под новый вариант сборки. Но если удалось можно радоваться.
Не увидел VS Code в качестве кандидатов в IDE.
Не увидел VS Code в качестве кандидатов в IDE.
Вы, навреное, все-таки говорите о полноценной версии Qt Creator-а для Qt проектов.
В моем случае я говорил именно о типе проекта generic + Gradle в качестве билд системы (кастомные шаги для построения проекта) — там кит не нужен.
С VS Code незнаком — посмотрю, спасибо.
В моем случае я говорил именно о типе проекта generic + Gradle в качестве билд системы (кастомные шаги для построения проекта) — там кит не нужен.
С VS Code незнаком — посмотрю, спасибо.
Не, с Qt в QtCreator проблем нет совсем. Оно спокойно ставится встроенными средствами и работает почти из коробки.
А вот попытка работать с Cmake проектом на Windows — тот еще квест. Даже однажды корректно заведеный кит не гарантируют его работу на соседне проекте.
Под линукс были проблемы с переключениями типов сборок и перекэшированием файлов проекта, поэтому иногда приходилось чистить папку сборки. Плюс настройки флагов cmake непонятно по каким правилам обновляются. В четвертой версии поддержку улучшили, но иногда моменты все же всплывают. А так пожалуй лучший из IDE которым доводилось пользоваться. CLion только у коллеги в пользовании видел и он как и прочие Idea IDE был довольно неповоротлив и тоже не имел какой-то фишки. Не то определения не мог скрафтить, не то какие-то базовые операции со строками не осиливал. Сейчас уже не вспомню.
Градлу так или иначе нужно указать какой компилятор использовать из списка уже установленных. Да и возможно дебаггер прикрутить. Так что считай тоже кит настроить.
А вот попытка работать с Cmake проектом на Windows — тот еще квест. Даже однажды корректно заведеный кит не гарантируют его работу на соседне проекте.
Под линукс были проблемы с переключениями типов сборок и перекэшированием файлов проекта, поэтому иногда приходилось чистить папку сборки. Плюс настройки флагов cmake непонятно по каким правилам обновляются. В четвертой версии поддержку улучшили, но иногда моменты все же всплывают. А так пожалуй лучший из IDE которым доводилось пользоваться. CLion только у коллеги в пользовании видел и он как и прочие Idea IDE был довольно неповоротлив и тоже не имел какой-то фишки. Не то определения не мог скрафтить, не то какие-то базовые операции со строками не осиливал. Сейчас уже не вспомню.
Градлу так или иначе нужно указать какой компилятор использовать из списка уже установленных. Да и возможно дебаггер прикрутить. Так что считай тоже кит настроить.
Не увидел VS Code в качестве кандидатов в IDE.
Возможно потому, что это не IDE, а текстовый редактор с поддержкой подсветки синтаксиса и плагинов.
И там среди "плагинов" есть кросс-платформенный билд майкрософтовского проприетарного IntelliSense в виде Language Server-а (который их изобретение, и туда лучше всех интегрирован). Пытался его прикрутить к Vim, но оказалось проще взять cquery. Современные "текстовые редакторы с плагинами" вполне себе конкурируют с IDE, разница только в сложности настройки и повышенных глюках. На Emacs, например, раньше был (ныне заброшенный) Semantic, многих его фич не видел в IDE.
А зачем прикручивать плагин от МС куда-то еще, если оно изначально заточено под одно ПО? Используйте другие аналоги: cquery, clangd и т.д.
Они конечно конкурируют, но в плане написания кода, когда дело доходит до отладки или анализа производительно — простых плагинов в редакторе будет не достаточно.
Они конечно конкурируют, но в плане написания кода, когда дело доходит до отладки или анализа производительно — простых плагинов в редакторе будет не достаточно.
Да посмотреть, вдруг оно будет лучше этих. Протокол то типа универсальный (хотя TypeScript в стандарте намекает).
Увы, инструменты IDE работают только в очень простых и типовых случаях. Вот взять профайлинг через perf в CLion. Он заточен под локальный запуск бинаря. А на практике мне было нужно профайлить запуски на сотнях машин с внешним шедулером и большими данными, а потом аггрегировать результат и рисовать картинку. Ещё, наверняка, и опции кастомные подбирал под задачу.
Взять отладку. В IDE никакой автоматизации обычно не наблюдал, хотя gdb отлично скриптуется. На практике я к gdb писал плагин, сокращающий излишние неймсейсы проекта, чтобы backtrace был читабельным.
Кмк, главная проблема IDE — она не мотивирует к изучению инструментов, которые лежат под ней, что потом выливается в потерю времени от неумения автоматизировать отладку/профайлинг. Вторая проблема — неприятный высокий input lag, но я давно смотрел.
Существуют некие современные «заменители» make-а: типа ninja и jam, но сути они не меняют — это очень низкоуровневые инструменты.
Самый главный заменитель make'а — это, наверное, все-таки gmake (GNU make). И я бы не сказал, что он уж очень низкоуровневый. На нем много чего хитрого наваять можно.
Ninja — это вообще промежуточная система сборки. Где-то читал, что автор рассчитывал в основном на генерируемые файлы сборки, а не на писанные вручную.
CMake — [средневековье] первая попытка уйти от низкоуровневых деталей make-а.
Они вроде как со SCons'ом появились почти ноздря в ноздрю.
Но, к сожалению, далеко уйти не удалось — движком здесь служит все тот же make для которого CMake генерирует огромные make-файлы на основе другого текстового файла с более выскоуровневым описанием билда.
Вовсе не обязательно. CMake может генерировать файлы под довольно широкий спектр сборочных систем — включая майкрософтовский MSBuild, майкрософтовский же nmake, ту же ninja и еще много подо что.
Основное преимущество CMake в том, что он позволяет выжать из нативной системы сборки все возможное (ну, по мере сил), но при этом не заморачиваться с ее тонкостями.
Из недостатков CMake —
SCons — [новые времена] самодостаточная, кросплатформенная билд система, написанная на Python. SCons одинаково хорошо справляется как с Java так и с C++ билдами. Зависимости хидеров для инкрементальной сборки отрабатываются корректно (насколько я понял создается некая база данных с метаданными билда), а на Windows «без бубна» работает MSVC.
У SCons ранних версий были проблемы с производительностью. Авторы захотели «надежно» отслеживать изменения файлов, поэтому вместо проверки даты-времени последней модификации они сравнивали хэш первых нескольких килобайт файла (ЕМНИП, первых двух или четырех). Потом, слава аллаху, сделали этот режим опциональным.
А еще у SCons, когда я его использовал, были нетривиальные требования к версии питона. С 3-й версией он вываливался с ошибкой, да и вторая подходила далеко не всякая.
Gradle [современность] — у меня уже был позитивный опыт использования Gradle для Java и Kotlin проектов и я возлагал на него большие надежды.
Т. е. в итоге вы остановились на том, с чем уже успешно работали. Ожидаемо, но хотелось бы увидеть сравнение билд-систем немного пошире и поглубже. :)
Как оказалось, в Gradle пошли дальше и реализовали возможность выкладывать C++ артефакты в Maven Repository!
Это здорово, если человек знаком с java и maven. А если у меня кровавый энтерпрайз, JRE на машине не установлен, никакого maven и в помине нет (зато есть subversion) — насколько мне поможет gradle?
Естественно, что всю низкоуровневую работу по конфигурированию компилятора и линковщика для работы с внешним компонентом Gradle берет на себя. Вам достаточно заявить о своих намерениях использовать такую-то библиотеку с такой-то версией из такого-то репозитория.
А если его понятия о том, с какими опциями собирать проект, не совпадают с корпоративными? Насколько сложно поменять опции компилятора и линкера?
Особенно это актуально для MSVC потому что по умолчанию в результате релизного билда Вы получите «жирный», не эстетичный бинарь с дебажной информацией и статически прилинкованной стандартной библиотекой.
Ну, статически прилинкованная стандартная библиотека не так уж жирна по нынешним меркам. Сколько там — килобайт двести? Это ж ни о чем. :)
Гораздо страшнее то, что в большинстве сторонних библиотек стандартная библиотека прилинкована динамически. В результате при попытке все собрать до кучи вылезает длинная простыня маловразумительных ошибок линкера.
Кстати, а как насчет сборки инсталляторов под винду и готовых пакетов (rpm, deb, etc) под линукс? В CMake что-то такое есть, но пощупать нормально так и не удалось.
Я не автор, но постараюсь ответить, поскольку сам в последнее время думаю о переходе с cmake на gradle.
Он умеет собирать из исходников и из удаленных репозиториев (по крайней мере git), выбор автором maven репозиториев обусловлен я думаю не в последнюю очередь м что для cpp не каких общепринятых репозиториев, кроме репозиториев от майнтенеров *nix ОС.
Это здорово, если человек знаком с java и maven. А если у меня кровавый энтерпрайз, JRE на машине не установлен, никакого maven и в помине нет (зато есть subversion) — насколько мне поможет gradle?
Он умеет собирать из исходников и из удаленных репозиториев (по крайней мере git), выбор автором maven репозиториев обусловлен я думаю не в последнюю очередь м что для cpp не каких общепринятых репозиториев, кроме репозиториев от майнтенеров *nix ОС.
Т. е. в итоге вы остановились на том, с чем уже успешно работали.
Не совсем. С make я знаком гораздо глубже чем мне самому хотелось бы :) доводилось писать на нем целую билд систему, состоящую из «модулей» подключаемых через include. Это был монстр, но работал исправно, хотя поддерживать его было затратно.
Наверное, именно поэтому я так обрадовался возможностям Gradle, когда с билдом можно «разговаривать» на более высоком уровне :)
Ожидаемо, но хотелось бы увидеть сравнение билд-систем немного пошире и поглубже. :)
Ну по билд системам можно и диссертацию написать при желании :) у меня же цель чисто в практической плоскости.
Это здорово, если человек знаком с java и maven. А если у меня кровавый энтерпрайз, JRE на машине не установлен, никакого maven и в помине нет (зато есть subversion) — насколько мне поможет gradle?
Вам достаточно поставить только JDK, остальное Gradle подтянет из сети при необходимости. Maven ставить не нужно, это просто тип репозитория. На локальном диске это обычная папка в которой лежат бинари с описаниями (версий, платформа и т.д.).
Локальный Maven репозиторий обычно создается в /.m2.
Вы можете сделать публиуацию в локальный репозиторий и посмотреть как это выглядит. Также можно тянуть билдовые зависимости из локальной репы.
А если его понятия о том, с какими опциями собирать проект, не совпадают с корпоративными? Насколько сложно поменять опции компилятора и линкера?
Самый простой способ поменять их прямо в билд скрипте (3-4 строчки).
Но правильный путь, на мой взгляд, написать плагин и использовать его во всех билд скриптах — усилий чуток побольше — зато, при необходимости что-то поменять в глобальных политиках нужно будет поправить только плагин.
Кстати, а как насчет сборки инсталляторов под винду и готовых пакетов (rpm, deb, etc) под линукс? В CMake что-то такое есть, но пощупать нормально так и не удалось.
Есть два плагина:
1) plugins.gradle.org/plugin/nebula.deb умеет собирать DEB и RPM
2) plugins.gradle.org/plugin/de.inetsoftware.setupbuilder а этот еще MSI под Винду
Но попробовать еще руки не дошли.
Что-тотвы buck и clion даже не упомянули.
CLion — платная, там вроде бы нет Community версии, но, наверное, хороша — ребята из JetBrains молодцы.
С Buck незнаком.
Вообще вариантов много еще можно найти. Помню когда-то любил кодить в SourceInsight, в Linux даже под wine запускал его :)
CodeBlocks
Geany,
Sublimate
и т.д.
Но мне пока что QtCreator понравился :)
С Buck незнаком.
Вообще вариантов много еще можно найти. Помню когда-то любил кодить в SourceInsight, в Linux даже под wine запускал его :)
CodeBlocks
Geany,
Sublimate
и т.д.
Но мне пока что QtCreator понравился :)
CLion поддерживает только CMake сборщик. Т.е. даже makefile не поддерживает, что делает его неудобным при работе с каким-нибудь уже готовым opensource проектом. Даже с CMake у него не все гладко (Давно попробовал открыть в нем базовый репо OpenCV — впечатления плохие остались). В общем очень странна такая его ограниченность, хотя я сам люблю другие продукты от jetbrains)
Makefile'ы он прекрасно поддерживает с помощью плагина: прекрасно armcc собираю проекты, gcc параллельно на CMake. По поддержке очень больших и хитровымученных кодовых баз CLion уступает QtCreator'у, но последний заметно отстает по анализу кода и навигации. Это исправляется со временем, но пока желания пересесть нет.
Популярные в опенсорс meson и autotools не рассмотрели. Популярные у корпораций bazel/buck/pants не рассмотрели. Лидер по IDE CLion не рассмотрели. Популярные у гиков Vim/Emacs/VSCode с YCM или LSP тоже обошли стороной.
Дело в том, что я не ставил целью исследовать все существующие в природе IDE, у меня к ним интерес чисто практический.
autotools — я не знаю, что именно курили ребята, когда работали над этой тулзой, но садистскими наклонностями они явно обладали :)
Если серьезно, то autotools опали мгновенно по требованию «кросплатформенность», но даже если бы существовал порт на Windows я бы ни в коем случае не использовал этот тихий ужас :)
autotools — я не знаю, что именно курили ребята, когда работали над этой тулзой, но садистскими наклонностями они явно обладали :)
Если серьезно, то autotools опали мгновенно по требованию «кросплатформенность», но даже если бы существовал порт на Windows я бы ни в коем случае не использовал этот тихий ужас :)
automake?
Даже гибче cmake, имхо, а делает то же: генерирует универсальный Makefile.
Даже гибче cmake, имхо, а делает то же: генерирует универсальный Makefile.
CMake делает не «универсальный makefile», а полноценный файл проекта для любой популярной IDE. Я выше уже написал…
У automake есть пара фатальных недостатков. :)
Во-первых, не кроссплатформенный: заставить его работать под виндой — это тот еще квест.
Во-вторых, сборка плохо параллелится: максимальная единица сборки — это подкаталог. Т. е. пока все файлы в подкаталоге не соберутся, сборка дальше не пойдет. Если в проекте множество мелких подкаталогов, теряются преимущества параллельной сборки.
Помнится, делал бенчмарки по сборке одного и того же проекта тремя системами: automake, scons и cmake. Билд-сервер был многоядерный (ЕМНИП 32 ядра), но сами ядра — не очень быстрые. Так что преимущества параллельной сборки были очень видны. Подкаталогов было не очень много (с десяток; в основном там собирались статические библиотеки). Результаты были такие:
— хуже всех — Automake. За счет того, что каждый подкаталог собирается отдельно, приходилось ждать, пока в каждом подкаталоге соберутся все исходники и слинкуются в библиотеку.
— второй по скорости — CMake (генерировались UNIX Makefiles). На «холодном старте» он проигрывал SCons из-за наличия фазы проверки системы и генерации мейкфайлов. Но и при пересборке проекта из-за пары изменившихся файлов он на пару-тройку процентов проигрывал SCons. Подозреваю, что это из-за ставшего слишком хитромудрым GNU make, который на каждое правило проверяет по десятку файлов.
— Лидером стал SCons. Помню, меня это тогда весьма удивило, потому как в то время на каждом углу писали, что scons очень медленный.
Во-первых, не кроссплатформенный: заставить его работать под виндой — это тот еще квест.
Во-вторых, сборка плохо параллелится: максимальная единица сборки — это подкаталог. Т. е. пока все файлы в подкаталоге не соберутся, сборка дальше не пойдет. Если в проекте множество мелких подкаталогов, теряются преимущества параллельной сборки.
Помнится, делал бенчмарки по сборке одного и того же проекта тремя системами: automake, scons и cmake. Билд-сервер был многоядерный (ЕМНИП 32 ядра), но сами ядра — не очень быстрые. Так что преимущества параллельной сборки были очень видны. Подкаталогов было не очень много (с десяток; в основном там собирались статические библиотеки). Результаты были такие:
— хуже всех — Automake. За счет того, что каждый подкаталог собирается отдельно, приходилось ждать, пока в каждом подкаталоге соберутся все исходники и слинкуются в библиотеку.
— второй по скорости — CMake (генерировались UNIX Makefiles). На «холодном старте» он проигрывал SCons из-за наличия фазы проверки системы и генерации мейкфайлов. Но и при пересборке проекта из-за пары изменившихся файлов он на пару-тройку процентов проигрывал SCons. Подозреваю, что это из-за ставшего слишком хитромудрым GNU make, который на каждое правило проверяет по десятку файлов.
— Лидером стал SCons. Помню, меня это тогда весьма удивило, потому как в то время на каждом углу писали, что scons очень медленный.
Для C++ проектов существует довольная жесткая зависимость на make и gcc.
NetBeans при настройке проекта с существующими исходниками позволяет указать как генерировать сборочный скрипт (CMake или autotools например), где и как собирать (хоть make, хоть ninja), что получается в результате сборки и как это запускать (например экзешник или тесты, или можно заливку в контроллер какой-нибудь задать например).
В плане парсера кода у него все более-менее нормально, но на каком-нибудь Boost Spirit парсер может не выдержать и тихо уйти в сторону.
Возможно автор поста подскажет, как закинуть плюсовый артифакт не в maven репозиторий, а в артифакторий JFrog?
Если конкретнее, то меня инересует что надо написать в теле maven{}:
Если конкретнее, то меня инересует что надо написать в теле maven{}:
publishing {
publications {
maven(MavenPublication) {
}
}
}Для публикации плюсового артефакта в локальную папку будет достаточно:
Если нужен удаленный репозиторий, тогда:
Если хочется добавить описание можно расширить:
Если сервак требует подписанные артефакты, тогда нужен плагин:
Для подписи нужно будет создать ключ и сконфигурировать доступ к нему.
plugins {
id 'maven-publish'
<..>
}
group = 'org.example.group'
version = '1.0'
publishing {
repositories {
maven {
url = "$buildDir/repo"
}
}
}
Если нужен удаленный репозиторий, тогда:
publishing {
repositories {
maven {
url = "https://..." // Адрес удаленного репозитория
credentials {
username <имя юзера> // Эти данные желательно выносить в проперти файл, чтобы не светить в скрипте
password <пароль>
}
}
}
}Если хочется добавить описание можно расширить:
publishing {
repositories {
maven {
url = "https://..." // Адрес удаленного репозитория
credentials {
username <имя юзера> // Эти данные желательно выносить в проперти файл, чтобы не светить в скрипте
password <пароль>
}
}
}
publications {
maven(MavenPublication) {
artifactId = ''
pom {
name = ''
description = ''
url = ''
licenses {
license {
name = 'The Apache License, Version 2.0'
url = 'http://www.apache.org/licenses/LICENSE-2.0.txt'
}
}
developers {
developer {
id = ''
name = ''
email = '
}
}
scm {
connection = ''
developerConnection = ''
url = ''
}
}
}
}
}Если сервак требует подписанные артефакты, тогда нужен плагин:
plugins {
id 'maven-publish'
id 'signing'
}
signing {
sign publishing.publications.maven
}
Для подписи нужно будет создать ключ и сконфигурировать доступ к нему.
Еще IDE codelite.org и пакетный менеджер conan.io ( docs.conan.io/en/latest/introduction.html#cross-platform-build-system-agnostic )
ps: Хочется посмотреть как с помощью gradle подключается хотя бы libSDL2 с mixer,image,net,rtf, и ttf
ps: Хочется посмотреть как с помощью gradle подключается хотя бы libSDL2 с mixer,image,net,rtf, и ttf
К сожалению, на данный момент в Gradle нет плагина для интеграции с pkg-config. Но сделать такой плагин задача тривиальная.
А вот как добавить libSDL2 в билд прямо в скрипте:
А вот как добавить libSDL2 в билд прямо в скрипте:
binaries.configureEach {
if (targetMachine.operatingSystemFamily.linux) {
compileTask.get().macros["_REENTRANT"] = "1"
compileTask.get().compilerArgs.add("-I/usr/include/SDL2")
linkTask.get().linkerArgs.add("-lSDL2")
}
}
В линуксе-то всё гладко, а в винде?
SDL2 тянет за собой SDL2_image который тянет libjpeg,libpng,libtiff, SDL2_mixer который тянет libogg,libvorbis,mpg123,opus, SDL_rtf и SDL2_ttf тянет freetype не говоря уже о zlib и подобном.
# sdl2-config --cflags
-I/usr/local/include/SDL2 -D_REENTRANT
# sdl2-config --static-libs
-L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags -lSDL2 -Wl,--no-undefined -lm -ldl -lpthread -lrt
SDL2 тянет за собой SDL2_image который тянет libjpeg,libpng,libtiff, SDL2_mixer который тянет libogg,libvorbis,mpg123,opus, SDL_rtf и SDL2_ttf тянет freetype не говоря уже о zlib и подобном.
В Винде пропишете эти флаги MinGW-шному компилятору в скрипте — принцип такой же как я написал выше.
Я к тому что, в принципе можно собрать любой системой сборки. Но на практике с gradle возни будет ничуть не меньше.
Это да, вот если бы начали развиваться плюсовые артефактории, тогда такие вещи решались бы легко и единообразно на любой платформе. У gradle есть потенциал для этого.
Не знаю как у других, но у меня от gradle постоянно чувство что КПД этой вундервафли близко в 0. То что makefile собирает 10сек, gradle умудряется маслать минуты, причем в первые разы еще норовит пару гигабайт подсосать из интернетов.
По идее лишнего тянуть не дожен, а когда все билд зависимости разрешены и запущен билд-демон — должен строиться быстро.
На самом деле, сравнение тут не совсем корректно: make это довольно тупая тулза которая делает только финальную часть работы. А основную за нее проделали вы руками (написали make-файл, поставили dev пакеты и т.д.) или какой-нибудь CMake.
А gradle это полноценная билд система и ей нужно сделать много работы чтобы подготовить для вас готовый билд на основе простого и понятно скрипта.
Как по мне, так лучше один раз написать простейший скрипт для gradle и подождать первый раз пока все подтянется-простроиться, чем сидеть с красными глазами в безумных make файлах :)
На самом деле, сравнение тут не совсем корректно: make это довольно тупая тулза которая делает только финальную часть работы. А основную за нее проделали вы руками (написали make-файл, поставили dev пакеты и т.д.) или какой-нибудь CMake.
А gradle это полноценная билд система и ей нужно сделать много работы чтобы подготовить для вас готовый билд на основе простого и понятно скрипта.
Как по мне, так лучше один раз написать простейший скрипт для gradle и подождать первый раз пока все подтянется-простроиться, чем сидеть с красными глазами в безумных make файлах :)
Лихо Вы замахнулись! Чтобы билдить C++ (с шаблонами, например boost) — систему сборки на java (gradle) приплели. А ведь так можно забыть, как напрямую использовать gcc для компиляции, что есть компиляция и линковка, неговоря о makefile'ах и всё что выше их. Почитайте-ка suckless
Почитайте-ка suckless
Этих ребят почитать — так вообще получается на C++ не надо писать. Только C. Для всего.
использовать gcc
makefile'ах и всё что выше их
Почитайте-ка suckless
Лихо Вы замахнулись! Чтобы билдить C++ (с шаблонами, например boost) — систему сборки на java (gradle)
По вашему выходит, что билдить C++ код можно только билд системой написанной на C++? :)
А ведь так можно забыть, как напрямую использовать gcc для компиляции, что есть компиляция и линковка, неговоря о makefile'ах и всё что выше их.
Система сборки и графическая среда разработки это всего лишь инструменты в арсенале разработчика. Перед основной работой есть смысл отобрать лучшие инструмены, разобраться как ими правильно и эффективно пользоваться, а потом можно и забыть некоторые несущественные детали и сосредоточиться на самой работе.
Почитайте-ка suckless
Давайте попробуем обойтись без повелительных наклонений :)
Прошу простить за характер комментария — писал "с пылу с жару". Проводя ретроспективу вижу проф. дефформацию — приходится писать код под пару плаформ — linux x86 + arm, windows, и эксперименты wasm для души, и под-тюнивать сборку под компилятор(ы), читать verbose вывод смотреть на во что разворачиваются плюсы и чего потом стоят, и забыл об удобстве инструментов и систем сборок.
Самый доступный способ сделать так, что бы просто и без вопросов можно быть набирать код и отлаживаться на всех платформах (ну, в разумных пределах, но как минимум Linux+macOS+Windows) – это взять CLion. Он даст и интеграцию с CMake и очень хорошую поддержку C++. Не бесплатно, но мы вроде тоже не за интерес работаем.
Отказываться от CMake очень неосмотрительно, так как он де-факто стандарт современной C++ разработки. В купе с тем же VCPKG можно очень быстро и просто подключить нужную библиотеку, обкатать идею, быстро и просто запустить юнит-тесты, подготовить бинарники к дальнейшей запаковки инсталлятором. Так же CMake позволит не думать об IDE в принципе, все возьмут то, к чему привыкли и будут работать. На всех платформах.
Отказываться от CMake очень неосмотрительно, так как он де-факто стандарт современной C++ разработки. В купе с тем же VCPKG можно очень быстро и просто подключить нужную библиотеку, обкатать идею, быстро и просто запустить юнит-тесты, подготовить бинарники к дальнейшей запаковки инсталлятором. Так же CMake позволит не думать об IDE в принципе, все возьмут то, к чему привыкли и будут работать. На всех платформах.
В генераторе шаблонного кода не нашел очень простую вещь: добавляем новый метод в заголовочном файле класса — нужно сгенерировать тело метода в cpp файле — не умеет.не помню точно, базовая ли это функциональность, но выход есть. Заходим в cpp, жмем ctrl+space и в подсказках будет генерация тел первыми строками.
В этом посте нужна фотка про петуханов, нетбинс, и Kokoko.
Как водится, комментарии к статье не менее (а то и более) информативны, нежели сама статья. Вот что значит качественно задеть за живое.
От себя ещё добавлю Code::Blocks, Anjuta.
От себя ещё добавлю Code::Blocks, Anjuta.
Не было бы статьи — не было бы и коментариев :) каждый находит то что ищет.
Я все еще ниасилил настроить Code::Blocks, чтобы он мог компилить хоть что-то. Виндовым гайдом не поделитесь?
Не собираю из-под Windows. А что, тамошний FAQ совсем не соотносится с реальностью?
Честно говоря не читал FAQ. Залез в настройки, прописал пути к компиляторам, попытался собрать hello world, не собралось, пошаманил, погуглил, забил.
Изначально хотел настроить SFML и собирать его из сорцов каким-то особенным компилятором. В то время он требовал какие-то определенные версии для сборки который не поставлялся с Code::Blocks и конфликтовал с уже поставленным MinGW. В общем забил на это грязное дело.
Изначально хотел настроить SFML и собирать его из сорцов каким-то особенным компилятором. В то время он требовал какие-то определенные версии для сборки который не поставлялся с Code::Blocks и конфликтовал с уже поставленным MinGW. В общем забил на это грязное дело.
а что там настраивать, все ставится из коробки, GCC идет в комплекте с CodeBlocks. Разве что в Path прописать путь к компилятору. А, еще один нюанс, рекомендую ставить в каталог, путь к которому состоит из латинских букв и не содержит пробелов. Видимо наследие тяжелого прошлого сказывается.
Qt Creator [...] монстр, заточенный под Qt, с дистрибутивом в гигабайт с гаком
Но речь идет о «легкой» версии среды для generic проектов. Его дистрибутив весит всего около 150 Мб и не тащит с собой вещи специфичные для Qt
У Qt Creator нет «лёгкой» версии (и нет «тяжёлой» весом в гигабайт и специфичными вещами). Есть просто Qt Creator, который может использоваться для разработки как с Qt, так и с «generic».
А вот загрузить его можно как отдельно, так и в составе установщика самого Qt (который и поставит специфичных вещей), но в обоих случаях сам Qt Creator будет весить одинаково. Ну и раз нужен только Qt Creator, то и грузить надо только его.
Вот полная версия: www.qt.io/offline-installers — 1.4Gb
Ссылка в статье на сам QtCreator без допов.
Ссылка в статье на сам QtCreator без допов.
Qt 5.12.1 for Linux 64-bit (1.4 GB)
Вы про эту ссылку? Как я и сказал, это установщик самого Qt (который в своём составе содержит и Qt Creator), а вовсе не "полная версия" Qt Creator. У Qt Creator нет никаких "полных" или "лёгких" версий.
Ссылки отдельно на Qt Creator, кстати, есть на этой же странице в соответствующей вкладке (на неё ссылку дать нельзя, к сожалению, потому что ребята из маркетинга и до этой страницы добрались со своими "оптимизациями").
Ссылка в статье на сам QtCreator без допов
Это не "допы", а сам Qt. И я в предыдущем комментарии тоже дал ссылки для загрузки только Qt Creator.
CMake… Modern CMake… More Modern CMake, это понятия, появившиеся за последние 3 — 4 года (кроме самого понятия cmake, конечно). Работа в режиме сервера, интеграция с пакетными менеджерами, поддержка в качестве файлов проекта «из коробки» для топ C++ IDE (я имею ввиду CLion, QtCreator и MS Visual Studio). Ну не тянет как-то на сердневековье. Безусловно gradle хорош, но не думаю, что это первое, что нужно брать или советовать людям для написания C++ кода.
Я думаю возможности CMake уже и так достаточно хорошо известны, нет смысла писать об этом, а о Gradle в качестве билд системы для C++ не так много информации.
В целом статья это скорее информация к размышлению, а не призыв к действию.
В целом статья это скорее информация к размышлению, а не призыв к действию.
Статья пример того когда человек описывает сложные инструменты, не поработав с ними как следует (а судя по описанию CMake — даже не прочитав описание)
Хм… ну что тут скажешь? :) Обменяемся любезностями тогда: а вот это пример коментария когда человеку совершенно нечего сказать по сути, но очень хочется хоть что-то написать (судя по содержанию даже не прочитав статью). :)
Вы подняли очень больную тему, можно даже сказать — холиварную, и SCons у Вас описывается более современным и лучшим решением чем CMake. А теперь представьте, что у Вас большой тяжелый проект. Что выбрать — СMake, который можно по итогу открыть как проект тем же креатором, и распараллелить его сборку хоть через increadibuild, сделав студийный олюшен, хоть distCC, или тормозный питоновский SCons, который по факту недоразумение, о котором на родном сайте написано:
When compared to scons, CMake is:
Faster
Requires less code for common tasks
Arguably more stable
Supports outputting to projects like Code::Blocks, Xcode, etc. which scons does not
When compared to scons, CMake is:
Faster
Requires less code for common tasks
Arguably more stable
Supports outputting to projects like Code::Blocks, Xcode, etc. which scons does not
Вот выше в коментариях человек проводил исследования по скорости разных билд систем:
Как я уже написал в статье — я предпочитаю монолитную систему сборки, а не «генераторы», даже если они неплохо генерируют мегабайты makefiles-ов, поэтому SCons в моем личном рейтинге оказался выше CMake.
Еще SCons, вроде бы, умеет кешировать собираемые файлы для ускорения параллельной сборки — подобно ccache, но для любых типов файлов.
По моим личным впечатлениям я бы не назвал его тормозным или «недоразумением», на вики вон пишут что его VMware использует, но мож баян :)
Но вот с интеграцией в IDE у него действительно все печально…
Поэтому мне больше понравился gradle :)
Ну вы бы хоть ссылку выкладывали или хотя бы цитировали целиком, а то выхватили из контекста только то что вам понравилось :)
github.com/scons/scons/wiki/SconsVsOtherBuildTools
— хуже всех — Automake. За счет того, что каждый подкаталог собирается отдельно, приходилось ждать, пока в каждом подкаталоге соберутся все исходники и слинкуются в библиотеку.
— второй по скорости — CMake (генерировались UNIX Makefiles). На «холодном старте» он проигрывал SCons из-за наличия фазы проверки системы и генерации мейкфайлов. Но и при пересборке проекта из-за пары изменившихся файлов он на пару-тройку процентов проигрывал SCons. Подозреваю, что это из-за ставшего слишком хитромудрым GNU make, который на каждое правило проверяет по десятку файлов.
— Лидером стал SCons. Помню, меня это тогда весьма удивило, потому как в то время на каждом углу писали, что scons очень медленный.
Как я уже написал в статье — я предпочитаю монолитную систему сборки, а не «генераторы», даже если они неплохо генерируют мегабайты makefiles-ов, поэтому SCons в моем личном рейтинге оказался выше CMake.
Еще SCons, вроде бы, умеет кешировать собираемые файлы для ускорения параллельной сборки — подобно ccache, но для любых типов файлов.
По моим личным впечатлениям я бы не назвал его тормозным или «недоразумением», на вики вон пишут что его VMware использует, но мож баян :)
Но вот с интеграцией в IDE у него действительно все печально…
Поэтому мне больше понравился gradle :)
Ну вы бы хоть ссылку выкладывали или хотя бы цитировали целиком, а то выхватили из контекста только то что вам понравилось :)
github.com/scons/scons/wiki/SconsVsOtherBuildTools
CMake is a principal competitor to both GNU Autotools and SCons. It is a build system generator, i.e. after running CMake, the user has a native Visual Studio file at his disposal, or a native Makefile, or nmake file, or whatever their preference is. Off-the-shelf build capabilities are comprehensive and proven for large scale software development. The implementation architecture is far more unified than GNU Autotools and it runs much faster. CMake has its own scripting language that runs on all platforms that CMake targets. It is Yet Another Scripting Language, which puts some people off, but it has the advantage of not introducing any additional language dependencies to a project.
When compared to scons, CMake is:
- Faster
- Requires less code for common tasks
- Arguably more stable
- Supports outputting to projects like Code::Blocks, Xcode, etc. which scons does not
But:
- Uses its own language, reinventing the wheel and not providing access to the extensibility and power of a real language.
- Arguably not as extensible as scons
- For terminal builds, still requires the use of 'make' (which, depending on your point of view, may or may not be a disadvantage) while scons is self-contained, all-in-one To sum up, my very subjective opinion is that scons is a better idea, but CMake has a stronger implementation
И вот снова Вы пишете про проблемы мейкфайлов.
CMake — генератор хоть мейкфайлов, хоть солюшенов для вижуал студии, хоть проектов для XCode. Это тулза другого уровня. Не смешивайте генератор билдскриптов и сами билдскрипты.
Мейк — это один конкретный частный случай. Мейк вообще может отсутствовать как шаг.
For terminal builds, still requires the use of 'make' (which, depending on your point of view, may or may not be a disadvantage) — Неверно. В среде Microsoft Windows Вы можете сделать солюшен, и с консоли набрать devenv --build project.sln (ну как-то так) и проект соберется студийным тулчейном с nmake, например.
Все эти вещи нужно проверять на больших проектах.
2 моих последних проекта — на СMake и SCons. Первый 10 000 000 строк кода(собирается 2 часа), второй — на SCons. Размер не известен, но билдится 6 часов.
В случае с первым работа тривиальна. Кто-то напрямую открывает Cmake как проект, кто-то экспортит в студию. В случа со вторым злые красноглазые разработчики педалят в notepad++, кто-то импортит проект в эклипс или вижуал студио код (или что еще умеет импортить папку) но всё равно не получает нормальной навигации по коду, билды запускаются из консоли а поиск ошибки это скроллинг длинного билдлога в поиске слова error. И весь бонус которые там есть, это какие-то захардкоженные в питон вещи, которые делают то, что могли бы делаться из простого батника.
CMake — генератор хоть мейкфайлов, хоть солюшенов для вижуал студии, хоть проектов для XCode. Это тулза другого уровня. Не смешивайте генератор билдскриптов и сами билдскрипты.
Мейк — это один конкретный частный случай. Мейк вообще может отсутствовать как шаг.
For terminal builds, still requires the use of 'make' (which, depending on your point of view, may or may not be a disadvantage) — Неверно. В среде Microsoft Windows Вы можете сделать солюшен, и с консоли набрать devenv --build project.sln (ну как-то так) и проект соберется студийным тулчейном с nmake, например.
Все эти вещи нужно проверять на больших проектах.
2 моих последних проекта — на СMake и SCons. Первый 10 000 000 строк кода(собирается 2 часа), второй — на SCons. Размер не известен, но билдится 6 часов.
В случае с первым работа тривиальна. Кто-то напрямую открывает Cmake как проект, кто-то экспортит в студию. В случа со вторым злые красноглазые разработчики педалят в notepad++, кто-то импортит проект в эклипс или вижуал студио код (или что еще умеет импортить папку) но всё равно не получает нормальной навигации по коду, билды запускаются из консоли а поиск ошибки это скроллинг длинного билдлога в поиске слова error. И весь бонус которые там есть, это какие-то захардкоженные в питон вещи, которые делают то, что могли бы делаться из простого батника.
И вот снова Вы пишете про проблемы мейкфайлов.
Нет, я говорил только, что архитектура монолитной билд системы мне нравится больше нежели концепция «генераторов».
Принцип работы CMake мне понятен, не расходуйте порох на объяснения :)
Все эти вещи нужно проверять на больших проектах.
Здравая мысль. Только кто ж захочет запилить огромный проект на две билд системы ради сравнения их производительности? Это попахивает большим количеством человекодней :)
2 моих последних проекта — на СMake и SCons. Первый 10 000 000 строк кода(собирается 2 часа), второй — на SCons. Размер не известен, но билдится 6 часов.
Такое сравнение, к сожалению, ни о чем. Если бы один и тот же проект в 10 000 000 строк билдился двумя разными системами и разница получилась бы в 4 часа, то это да, был бы серьезный косяк для SCons-а. При условии что тулчейн будет один и тот же.
В случа со вторым злые красноглазые разработчики педалят в notepad++, кто-то импортит проект в эклипс или вижуал студио код (или что еще умеет импортить папку) но всё равно не получает нормальной навигации по коду, билды запускаются из консоли а поиск ошибки это скроллинг длинного билдлога в поиске слова error.
Тут я с вами уже согласился — отсутсвие интеграции с IDE для SCons это серьезный недостаток.
Хотя помню работали с одной платформой, натаянута она была на Linux, а все ее сервисы использовали некую вариацию IDL — файлы с описанием интерфесов. C++ код по этим файлам генерился прямо во время построения. В качестве билд системы там был как раз CMake — билдилось все хорошо, но вот проектные файлы для Eclipse он генерил какие-то кривые — возможно, это было связано с использованием этих IDL.
Добавлю ещё 5 копеек
Перевод гигантских проектов с одной билд системы на другую, с сохранением параллельно старой и новой — довольно типичный случай, если вы аутсорсер портирующий какой-нибудь фотошоп с виндовса на линукс, и старый билд механизм будет жить до последнего, ведь кроме вас ещё кто-то работает над другими частями кода, но к сожалению scone->cmake ещё не делал, он как раз в процессе. Да и нередко выделяется время на оптимизацию времени сборки, которое впоследствии окупается. И именно портирование с Scons это большая боль. Потому что другие билд системы это обычно батник запускающий билд систему + до или после сопутствующие действия, типа цифровой подписи, упаковки в инсталлятор и т.п. и замена билдсистемы не влияет на весь процесс. Но в сконсе же эти сопутствующие действия надо выковыривать отдельно и выносить в скрипты, и замена билд системы выливается в правки во всем конвейере.
Перевод гигантских проектов с одной билд системы на другую, с сохранением параллельно старой и новой — довольно типичный случай, если вы аутсорсер портирующий какой-нибудь фотошоп с виндовса на линукс, и старый билд механизм будет жить до последнего, ведь кроме вас ещё кто-то работает над другими частями кода, но к сожалению scone->cmake ещё не делал, он как раз в процессе. Да и нередко выделяется время на оптимизацию времени сборки, которое впоследствии окупается. И именно портирование с Scons это большая боль. Потому что другие билд системы это обычно батник запускающий билд систему + до или после сопутствующие действия, типа цифровой подписи, упаковки в инсталлятор и т.п. и замена билдсистемы не влияет на весь процесс. Но в сконсе же эти сопутствующие действия надо выковыривать отдельно и выносить в скрипты, и замена билд системы выливается в правки во всем конвейере.
Это, конечно, интересно будет посмотреть лобовое сравнение перфоманса CMake и SCons в таком большом проекте.
На мой взгляд, производительность системы сборки, в основном, будет зависить от ее способности эффективно распараллеливать задачи.
Возьмем для примера три динамические библиотеки которые зависят друг от друга:
A -> B -> C — сначала нужно построить A, потому, что ее использует B, и только потом C потому, что она использует B.
Не могу утверждать какой makefile сгенерирует для такого случая CMake, но, вероятно, здесь будет происходить последовательная сборка с расспаралеливанием только внутри построения A, B, C. Учитывая, что каждая библиотека содержит несколько исходных файлов это будет эффективно, т.к. компиляция будет происходить параллельно, а возможно, что и с раскидыванием на разные ядра CPU.
Но Make не в состоянии понять высокоуровневую структуру билда, он будет параллелить только свои низкоуровневые задачи.
А вот полноценная билд система в состоянии понять, что зависисмости B на A и C на B возникают только на стадии сборки. А компилировать можно A, B и C параллельно и такая совместная компиляция может принести прирост производительности.
Возможно, выполнять такие действия до или после билда проще и удобней, но тогда, в какой-то степени, теряются преимущества инкрементальной сборки — т.е. они будут выполняться безусловно, даже если в системе ничего не изменилось. На мой взгляд, предпочтительней такие задачи все же делать частью билд процедуры. В gradle не трудно написать плагин для таких целей.
На мой взгляд, производительность системы сборки, в основном, будет зависить от ее способности эффективно распараллеливать задачи.
Возьмем для примера три динамические библиотеки которые зависят друг от друга:
A -> B -> C — сначала нужно построить A, потому, что ее использует B, и только потом C потому, что она использует B.
Не могу утверждать какой makefile сгенерирует для такого случая CMake, но, вероятно, здесь будет происходить последовательная сборка с расспаралеливанием только внутри построения A, B, C. Учитывая, что каждая библиотека содержит несколько исходных файлов это будет эффективно, т.к. компиляция будет происходить параллельно, а возможно, что и с раскидыванием на разные ядра CPU.
Но Make не в состоянии понять высокоуровневую структуру билда, он будет параллелить только свои низкоуровневые задачи.
А вот полноценная билд система в состоянии понять, что зависисмости B на A и C на B возникают только на стадии сборки. А компилировать можно A, B и C параллельно и такая совместная компиляция может принести прирост производительности.
Потому что другие билд системы это обычно батник запускающий билд систему + до или после сопутствующие действия, типа цифровой подписи, упаковки в инсталлятор и т.п. и замена билдсистемы не влияет на весь процесс.
Возможно, выполнять такие действия до или после билда проще и удобней, но тогда, в какой-то степени, теряются преимущества инкрементальной сборки — т.е. они будут выполняться безусловно, даже если в системе ничего не изменилось. На мой взгляд, предпочтительней такие задачи все же делать частью билд процедуры. В gradle не трудно написать плагин для таких целей.
Не могу утверждать какой makefile сгенерирует для такого случая CMake, но, вероятно, здесь будет происходить последовательная сборка с расспаралеливанием только внутри построения A, B, C.
Ошибаетесь.
CMake сгенерирует файл, который будет параллелить не зависящие друг от друга таргеты.
Другое дело, что кроме CMake нужно учитывать и ту билд-систему, под которую CMake генерит файлы. Например, если это будет ninja, то билд больших проектов будет чуточку быстрее, чем если это будет gmake. Просто потому, что ninja — проще, и не пытается найти на файловой системе кучу несуществующих файлов (полюбоваться, сколько всякого говна ищет по всему диску gmake, можно, проанализировав вывод gmake -d).
Да, возвращаясь к CMake. Если сгенерировать под виндой мейкфайлы для NMake, то мы автоматически получим однопоточную и жутко тормозящую систему сборки, ибо nmake параллелит плёхо. Но это не дефект CMake, а особенность целевой системы сборки (NMake).
Ошибаетесь.
CMake сгенерирует файл, который будет параллелить не зависящие друг от друга таргеты.
Почему ошибаюсь? Я как раз и говорил о ЗАВИСЯЩИХ друг от друга таргетах. Только зависимости бывают разными, если, например, одна библиотека зависит от другой — КОМПИЛИРОВАТЬ их можно параллельно, а СОБИРАТЬ (линковать), только когда зависимая будет полностью готова. А вот определить тип зависимости, думаю, под силу будет только целиковой билд системе.
Только зависимости бывают разными, если, например, одна библиотека зависит от другой — КОМПИЛИРОВАТЬ их можно параллельно, а СОБИРАТЬ (линковать), только когда зависимая будет полностью готова.
Тип зависимости в билд-системах бывает только один: зависимость.
А вот строить графы зависимостей разные билд-системы могут действительно по-разному, это да. Что касается CMake, граф зависимостей он генерирует качественный — т.е. пока линкуется одна библиотека, в параллель будут исполняться другие таргеты, которые от нее не зависят.
А вот определить тип зависимости, думаю, под силу будет только целиковой билд системе.
Ошибаетесь (2). CMake вполне себе полноценная билд-система в том плане, что он строит полное дерево зависимостей. Только в отличие от «целиковой» билд-системы, CMake полученное дерево зависимостей не начинает исполнять на конкретных файлах, а дампит в виде файлов сборки для более простых билд-систем.
Кстати, было бы действительно неплохо добавить в CMake режим сборки — скажем, в виде фейкового «генератора». Все равно там уже есть подпорки для системы сборки — режим -E, исполняющий некоторые команды кросс-платформенно.
Тип зависимости в билд-системах бывает только один: зависимость.
Хорошо, пусть будет просто зависимость. Сформулирую иначе: зависисмости можно обрабатывать по-разному. Например, для C++ можно выполнить дополнительную оптимизацию и начать опережающую компиляцию зависящей библиотеки. Определить возможность такой оптимизации, вероятно, сможет и «генератор» типа CMake-а, но не факт что у него получится сгенерировать соответствующий билд файл для нижележащей билд системы, в которой существуют свои ограничения.
Ошибаетесь (2)
Разъясняю свою масль (2): «целиковая» билд система выполняет полный цикл от конфигурирования билда, построения графа зависисмстей и до выполнения всех необходимых задач. А «генератор» ограничен воможностями нижестоящей билд системы и какой бы замечательный билд файл он не сгененрировал нижестоящая тулза может подпортить все дело. Вы сами же писали, что, к примеру, NMake будет строить в один поток и генерптор ничем помочь тут не сможет, он свою работу уже сделал.
Определить возможность такой оптимизации, вероятно, сможет и «генератор» типа CMake-а, но не факт что у него получится сгенерировать соответствующий билд файл для нижележащей билд системы, в которой существуют свои ограничения.
Для большинства испробованных мной билд-систем (UNIX Makefiles, Ninja, разные версии Visual Studio) полученная система сборки вполне «соответствующая».
А «генератор» ограничен воможностями нижестоящей билд системы и какой бы замечательный билд файл он не сгененрировал нижестоящая тулза может подпортить все дело. Вы сами же писали, что, к примеру, NMake будет строить в один поток и генерптор ничем помочь тут не сможет, он свою работу уже сделал.
На практике все не так уж плохо, как в теории. Большинство нижележащих билд-систем умеет собирать в параллель — причем CMake генерирует для билд-системы качественные файлы, позволяющие максимально эффективно использовать параллельную сборку. NMake, который не умеет в параллельную сборку — это эдакий курьез.
Но, как я уже писал, для CMake было бы неплохо добавить небольшой(?) дополнительный шаг, чтобы вместо генерации файлов для билд-системы пошла собственно сборка. И тогда, глядишь, для большинства пользователей вообще отпадет необходимость в генерации лишних файлов.
Пользуюсь GYP для сборки игры под Windows, macOS, iOS, и сервера под linux. Очень нравится, но автору статьи вряд ли подойдет. Гугл проект почти не поддерживает, но на гитхабе недавно появился форк, где энтузиасты во всю коммитят изменения. Изначально пытался пользоваться cmake, но по ряду причин он мне не подошел.
В качестве билд-системы — cmake, однозначно:
1. Кроссплатформенный, способен сгенерировать билд-файлы под любую билд-систему. Под windows это не обязательно однопоточный nmake, можно указать и что-нибудь вроде «Visual Studio 15 2017 Win64».
2. Способен сам же запустить то, что сгенерировал: «cmake --build .» вызовет хоть make, хоть nmake, хоть любую другую систему сборки.
3. Популярен, активно разрабатывается и поддерживается.
4. В современном виде — весьма мощен и удобен.
5. Очень ответственно относится к вопросам обратной совместимости.
1. Кроссплатформенный, способен сгенерировать билд-файлы под любую билд-систему. Под windows это не обязательно однопоточный nmake, можно указать и что-нибудь вроде «Visual Studio 15 2017 Win64».
2. Способен сам же запустить то, что сгенерировал: «cmake --build .» вызовет хоть make, хоть nmake, хоть любую другую систему сборки.
3. Популярен, активно разрабатывается и поддерживается.
4. В современном виде — весьма мощен и удобен.
5. Очень ответственно относится к вопросам обратной совместимости.
А минусы чего не пишете? Синтаксис у него страх и убожество, после qmake особенно тошнит.
Ну, qmake тоже не сахар. Пока весь проект можно описать переменными — все прекрасно, но если вдруг всплывает что-нибудь нестандартное или грабель какая — пока найдешь решение, облысеешь до самых подмышек.
А в CMake меня умиляет то, что некоторые модули работают не совсем стандартно. Например, модуль Threads — внезапно! — не выставляет переменную THREADS_FOUND. Некоторые модули выставляют в переменной DEFINITIONS голые дефайны, а некоторые (wxWidgets, например) зачем-то прихреначивают в начало -D. Со списоком библиотек, помнится, тоже были похожие глюки. А что самое забавное — в разных версиях CMake поведение может быть разное, ибо баги исправляются.
А в CMake меня умиляет то, что некоторые модули работают не совсем стандартно. Например, модуль Threads — внезапно! — не выставляет переменную THREADS_FOUND. Некоторые модули выставляют в переменной DEFINITIONS голые дефайны, а некоторые (wxWidgets, например) зачем-то прихреначивают в начало -D. Со списоком библиотек, помнится, тоже были похожие глюки. А что самое забавное — в разных версиях CMake поведение может быть разное, ибо баги исправляются.
С qmake есть проблема, что всякие нетривиальные штуки в нем плохо документированы. Например глобальный кэш переменных, или те же пользовательские цели для make. И еще сам QtCreator не очень хорошо парсит включаемые проекты (*.pri), особенно если там есть части, зависящие от токенов в CONFIG. Также если есть платформо-зависимые части, то QtCreator показывает их все в дереве проекта, независимо от текущей платформы. Ну это больше проблемы QtCreator, собирается оно нормально. Могли бы лучше интегрировать конечно.
(Пока что) ещё есть Qbs.
Чего-то никто не вспомнил о системе сборки Chromium (gn+ninja), хотя она тоже кросс-платформенная и очень эффективная. Может генерить проекты для MSVC и XCode, а также списки файлов + DEFINES для QtCreator. Основной язык Python, это одновременно и плюс и минус (минус потому что только Python, обычную команду из системы напрямую вызвать нельзя).
Насчет среды, пока ничего удобнее QtCreator для себя лично не нашел. К сожалению под Windows все портит отладчик, глючный и неудобный (cdb). Но под Mac все супер. Также и система сборки qmake — с одной стороны, дает достаточную гибкость и расширяемость (можно создавать свои цели для make), с другой — легкость сопровождения и поддержки. Ну и встроенная документация в QtCreator тоже не последнее дело. Вместо nmake под Windows используется собственная тулза jom.exe (многопоточный make). Под Mac можно добавить ключик -j для стандартного make, с тем же эффектом. Также можно определять произвольные компиляторы/трансляторы для любых исходников (например protobuf), и компилировать все за один проход.
Также у Qt заявлено в планах расширять поддержку CMake для QtCreator, к сожалению эта уродливая дрянь побеждает всех (они даже отказались от собственного qbs, увы).
Насчет среды, пока ничего удобнее QtCreator для себя лично не нашел. К сожалению под Windows все портит отладчик, глючный и неудобный (cdb). Но под Mac все супер. Также и система сборки qmake — с одной стороны, дает достаточную гибкость и расширяемость (можно создавать свои цели для make), с другой — легкость сопровождения и поддержки. Ну и встроенная документация в QtCreator тоже не последнее дело. Вместо nmake под Windows используется собственная тулза jom.exe (многопоточный make). Под Mac можно добавить ключик -j для стандартного make, с тем же эффектом. Также можно определять произвольные компиляторы/трансляторы для любых исходников (например protobuf), и компилировать все за один проход.
Также у Qt заявлено в планах расширять поддержку CMake для QtCreator, к сожалению эта уродливая дрянь побеждает всех (они даже отказались от собственного qbs, увы).
> они даже отказались от собственного qbs, увы
Ну, прошло уже два года, но Qbs еще живее всех живых. Развивается по-тихонечку (даже и без Qt company, они особо ничего и не развивали при жизни тут). ;)
Есть очень хорошая поддержка его в QtCreator, а недавно вообще запилили плагин и для VSCode. В дальнейших планах вроде как есть идеи запилить и для KDevelop, но это еще на воде писано.
Ну, прошло уже два года, но Qbs еще живее всех живых. Развивается по-тихонечку (даже и без Qt company, они особо ничего и не развивали при жизни тут). ;)
Есть очень хорошая поддержка его в QtCreator, а недавно вообще запилили плагин и для VSCode. В дальнейших планах вроде как есть идеи запилить и для KDevelop, но это еще на воде писано.
Sign up to leave a comment.
В чем набрать и чем собрать C++ проект