make VERBOSE=1

Вообще этот ублюдочный CMake нарушил негласное соглашение между разработчиками, когда make V=1 выводит весь VERBOSE и сделал вместо V=1 – VERBOSE=1.

То же ядро Linux и даже ndk-build в Android внезапно отлично работают с привычным всем make V=1.

Спасибо!

А опцию V=1 (ну или V=0 видимо) должен поддерживать тот кто пишет Makefile или оно как то из коробки идет?

Судя по по тому что cmake перешел на VERBOSE это должен делать автор…

Use ninja. (cmake -GNinja)

А опцию V=1 (ну или V=0 видимо) должен поддерживать тот кто пишет Makefile или оно как то из коробки идет?

Первое. Из коробки у make есть такая фича, как dry-run, задаётся флагом -n: make -n тоже выводит список команд. Но сам понимаешь, там может быть проблема в том, что make’у для дальнейшей сборки потребуются сгенерированные файлы.

Да.

Ковыряюсь в этом cmake, ощущение премерзейшее… ;-(

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

лучше при конфигурировании задать -DCMAKE_VERBOSE_MAKEFILE=ON

Есть ещё Meson, можешь его попробовать вместо CMake, он гораздо адекватнее, но больше Linux-only решение.

RedHat на него делает ставку, а не на CMake: git is really stupid and made by stupid (комментарий)

а стоит ли гнать коней? сейчас этих систем как грязи и все имеют свои закидоны

если собирается что-то простое, то не сложно самому написать makefile, если это нечто будет распространяться и не требуется сборка на не-linux, то я скорее выберу autotools, хотя бы в силу его распространённости

Моя бы воля, я бы оставался на gnu make. Но проект на cmake, это не я решаю - хотя за время потраченное на разбирательство с этой фигней я бы уже нормальный Makefile написал два раза.

Но у них там в т.ч. под виндой это все на VS должно собираться и вааще…

Я сейчас страдаю с подключением SWIG. Страница документации https://cmake.org/cmake/help/v3.12/module/UseSWIG.html афигенно лаконична, страница в SWIG http://www.swig.org/Doc3.0/SWIGDocumentation.html#Introduction_build_system устарела и еще более лаконична.

Наверное, стоит. Иначе в противном случае CMake станет стандартом и укоренится.

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

+много. Поиск пакетов сделан приятно, но остальное оставляет ощущение какой то студенческой поделки (то что касается swig например)

Коллеги, imb - кто то знает как для

SWIG_LINK_LIBRARIES(...)

указать путь поиска библиотек для линковки (хочется добавить текущую директорию)?

link_directories

на нее похоже не действует;-(

ЗЫ А нет, действует но как то странно - путь указывается от директории проекта. Может и не так все плохо…

Да, в общем еще один нубвопрос - как в путь линковки добавить текущую директорию (там где происходит сборка)?

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

CMAKE_BINARY_DIR? The path to the top level of the build tree.

О, работает! Спасибо;-)

Поиск пакетов сделан приятно, но остальное оставляет ощущение какой то студенческой поделки

вот не верю, для сборки на и для x86 это всё более-менее работает, но при cross-compile это превращается в ад, если автор озаботился добавление параметров конфигурирования ещё можно жить, но если он всё отдал на откуп cmake - ад, приходится изучать все эти потроха что бы найти переменную которую надо переопределить

есть ещё вариант каждый раз создавать toolchain-файл и указывать его при конфигурировании, но в зависимости от версии cmake это может работать так себе, собственно как и поиск зависимостей средствами cmake

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

По CMake есть одна единственная книга, и она же исчерпывающая* https://crascit.com/professional-cmake/. Автор обновляет её под новые версии, правда начиная с некоторого времени отказался продавать её в Россию, но первую версию можно скачать на либгене. Даже так это существенный прорыв, потому что до него длительное время по CMake вообще ничего не было и все лепили по наитию и полутора статьям в блогах, что объясняет огромное число проектов с отвратительной сборочной системой.

* кроме совсем уж обскурных вещей типа скриптования ctest и cdash, в которых кажется не шарят даже сами майтейнеры CMake.

вот не верю

Это было первое впечатление нуба;-)

Спасибо за книжку. Но ИМНО если ты должен читать книжку 400+ стр что бы разобраться с автоматизированной системой сборки - что то пошло не так.

По GNU Make у меня валяется текст на 360Кб, это 100 с небольшим страниц, и этого в общем за глаза (половина как справочник).

Первое впечатление - многие вещи в cmake сделаны контринтуитивно. Юзер не должен биться в падучей пытаясь понять как пробросить опцию сборки через cmake в то-что-реально-будет-собирать-проект. Должна быть какая то простая как табуретка концепция с простым как табуретка интерфейсом а не вот такое спагетти:

The variable SWIG_MODULE_<name>_REAL_NAME will be set to the name of the swig module target library. This variable is useless if variable UseSWIG_TARGET_NAME_PREFERENCE is set to STANDARD.

Вот отличные руководство https://cliutils.gitlab.io/modern-cmake/chapters/features/cpp11.html

А вот тут можно подчерпнуть много интересного https://github.com/lefticus/cpp_starter_project

Для меня CMake решил кучу проблем сборки. Большая часть из них - это управление зависимостями. FetchContent существенно облегчает жизнь, особенно когда зависимость имеет хорошо написаный CMakeLists.txt.

Ну, если, конечно, нет обязательного требования юзать СМаке то я бы юзал QBS . :)

Почему?

• Потому что он очень прост, даже маленькая ляля разберется.

• Не нужны зависимости, аля питон и прочее (ну, окромя Qt, но и тут никто не мешает статикой все собрать).

• Легко можно посмотреть что оно собирает, т.е. вывести полностью командную строку.

• Если что то работает не так, то легко пофиксить прям на лету в самом QBS, т.к. там JS.

• Баги фиксятся более менее быстро, главное вовремя о них сообщить :)

• Поддерживает уже дохренища архитектур и компиляторов. Сам их детектит и нн нужны никакие тулчейн файлы.

• В кросс платформу вообше без проблем, в том числе и голое железо.

• Интеграция с QtCreator, в кооором также все эти тулчейны и архитектуры уже поддерживаются.

Ще ни вмэрла (с) , или как там спивкують :))

Здесь писали, что вроде, собирались отказаться от qmake в пользу cmake. Или это QBS не касается?

По GNU Make у меня валяется текст на 360Кб, это 100 с небольшим страниц, и этого в общем за глаза (половина как справочник).

Безусловно, если таргет - GNU[/Linux], то можно великолепно срезать углы на этой скриптоте, никто не спорит. Да хоть build.sh написать, если устраивает время сборки. В противном случае приплюсуй сюда мануал по msbuild и заодно мануал по ninja, когда выяснится что msbuild еле ползает и надо продублировать сборочную систему на ninja, и сравни снова.

PS. Конкретно скрипты для свига в CMake не щупал, если они действительно полное говно, которое никто не адаптировал со времён CMake 2.x, то этим никого не удивишь, напоминаю что всегда есть вариант их не использовать и обернуть вызовы свига в таргеты самостоятельно, собственно как ты бы делал с GNU Make, заодно показать всем как надо.

PPS. По топику вроде тебе уже ответили, но позволю просуммировать для поисковых машин - если генерил сборочную систему для GNU Make, то достаточно make VERBOSE=1, если для ninja, то ninja -v, если для msbuild то /clp:ShowCommandLine. Для GNU Make это поведение генератора из коробки и крутить в CMake для этого ничего не надо, для двух остальных это вообще никак не связано с CMake.

В противном случае приплюсуй сюда мануал по msbuild

Тоже верно.

всегда есть вариант их не использовать и обернуть вызовы свига в таргеты самостоятельно

Маловероятно что до этого дойдет, но не исключено. Правда для этого придется занырнуть в этот смаке и перетащить на него пару своих проектов джаст фор фан а не потому что дядя приказал.

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

Маловероятно что до этого дойдет, но не исключено. Правда для этого придется занырнуть в этот смаке и перетащить на него пару своих проектов джаст фор фан а не потому что дядя приказал.

Кейс кодогенерации во время сборки на самом деле весьма частый в самых разных проектах, и часто он сделан криво (i.e. фейлит в многопоточке). Т.ч. умение быстро по месту заворачивать кодогенератор в таргет и встраивать его в нужное место в графе завимостей, и делать это неглючно -- бесценно. А прочее, как то синтаксис описания таргетов и конфигурация транспайлера, если он нужен -- чистая вкусовщина и выгибоны на местах :)

Ну кодогенерацией то мы занимается, но она у нас в основном вообще на питоне сделана… правда сам процесс кодогенерации обычно однопоточный, я не очень представляю нафик там много потоков? Вот код который на выхлопе, это да.

Я имел ввиду -- фейлится многопоточная сборка из-за гонок из-за грубой силой сделанной кодогенерации. Или не фейлится, а начинает на ровном месте пересобирать заново 95% объектов, что на больших проектах считай что смерть.

А… ну да, это немножко о другом. С таким я не сталкивался (у нас нет таких проектов).

Но ИМНО если ты должен читать книжку 400+ стр что бы разобраться с автоматизированной системой сборки - что то пошло не так.

Вот книжка от автора Meson https://meson-manual.com/

Для других систем сборки всё примерно также…

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

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

Проблема cmake только в том что он в этом первопроходец на пути от уродов типа autocrap к нормальным системам сборки, и сам в процессе изменился до неузнаваемости (то что называют modern cmake), а так он божественен был и ещё более божественен стал.

итоге эволюции стал еще страшнее autotools, то есть изначальные цели сделать красиво полностью провалились. В итоге у нас 2 работающих системы кроссплатформенной сборки. Единственный плюс cmake это генерилка крепа для ninja, что сейчас стали часто хотеть для C++-проектов.

И стал бы немного ещё более божественным, если хотя бы имелись:

• интроспекция по кеш-переменным и вывод справки, хотя бы уровня –help в configure, ДО генерации СС. Ибо натурально приходится шерстить всю кодовую базу, выясняя что хотел сказать автор.

• дамп всех таргетов, включая (особенно) интерфейсные после генерации СС. Ибо то же самое что см. выше.

• линковка в режиме whole archive. Да, OBJECT-тартеты её заменяют, но это изрядно более низкоуровневая штука без транзитивного использования.

• экспорт таргетов при установке должен быть принудительным и из коробки. Ибо былинно печёт от разработчиков, чьи поделия нельзя зацепить через find_package.

Единственный плюс cmake это генерилка крепа для ninja, что сейчас стали часто хотеть для C++-проектов.

Ninja многие хотят, так как работает под виндой (в частности, поставляется с VS, но можно невозбранно стянуть с pypi, например) и лучше параллелит, чем msbuild (CPU в потолок).

Или это QBS не касается?

Просто QBS сообществу отдали, так сказать, в свободное плавание. Никто от QBS не отказывается, кто на нем сидел - тот и сидит… Активно туда коммитим, в след версии 1.17 будет ппц как много изменений и исправлений (штук 50 наверно наберется)… :)

Спасибо!

Мне тоже QBS нравится, а по работе приходится в CMake’е ковыряться.

Страшнее autocrap быть ничего не может, даже лапша низкоуровневого питона scons не так отвратна. А современный cmake, повторюсь, действительно красив. Таргеты и их свойства, всё остальное само.