LINUX.ORG.RU

Вышла новая версия CMake 3.16.0

 , ,


1

4

Вышла новая версия популярной системы сборки CMake 3.16.0 и сопутствующих утилит CTest и CPack, облегчающих тестирование и сборку пакетов соответственно.

Основные изменения:

  • CMake теперь поддерживает Objective-C и Objective-C++. Поддержка включается добавлением OBJC и OBJCXX в project() или enable_languages(). Таким образом, *.m- и *.mm-файлы будут компилироваться как Objective-C или С++, иначе, как и ранее, будут считаться исходными файлами C++.

  • Добавлена команда target_precompile_headers(), указывающая список прекомпилированных заголовочных файлов для цели.

  • Добавлено свойство цели UNITY_BUILD, указывающее генераторам объединять исходные файлы для ускорения сборки.

  • Команды find_*() теперь поддерживают новые переменные, контролирующие поиск.

  • Команда file() теперь может рекурсивно выдавать список библиотек прилинкованных к библиотеке или исполняемому файлу с подкомандой GET_RUNTIME_DEPENDENCIES. Эта подкоманда заменяет собой GetPrerequisites() .

  • CMake теперь имеет встроенные команды true и false, вызываемые через cmake -E, а опция --loglevel теперь устарела и будет переименована в --log-level.

>>> Подробности

★★★★★

Проверено: cetjs2 ()
Последнее исправление: a1batross (всего исправлений: 2)

Где на этот cmake вменяемый туториал найти? Желательно, чтобы он не фокусировался на C, а чтоб о том, как собирать многоязычный проект с адскими зависимостями.

yvv ★★☆
()

где бы почитать про target_precompile_headers() и UNITY_BUILD с примерами

I_one
()
Ответ на: комментарий от yvv

По своему опыту скажу, что лучше не находить. Да, CMake становится лучше, документация у него наконец-то появилась, старые неудачные решения потихоньку выкидывают и именно поэтому я написал новость, но у него всё ещё упоротый DSL. И я просто не хочу тратить на него своё время и не советую другим, если у вас нет существующего проекта с CMake.

@I_one, в документации. Добавлю ссылки в новость.

a1batross ★★★★★
() автор топика
Последнее исправление: a1batross (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Qbs хоть и перестал Qt-эшниками поддерживаться, но его всё ещё развивают.

kachsheev ★★★
()
Ответ на: комментарий от RazrFalcon

Я развиваю для себя форк waf со всякими расширениями, которые наврядли примет автор, но то что может – засылаю обратно.

А так, meson лучшая альтернатива на сегодняшний день. Подчеркну, что альтернатива, поскольку тоже является генератором со своим DSL, но всё же более удачным. :)

a1batross ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

На самом деле, времени отнимает даже меньше, чем сколько пытаешься побороть очередную проблему CMake. Тем более в условиях, когда проблема со сборкой у тебя не воспроизводится. А waf не имеет зависимостей кроме Python и вообще распространяется вместе с исходным кодом, поэтому проблема однозначно в кривизне рук либо твоей, либо того кто собирает. :)

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

Имя хорошее, но оказывается я не один такой. :)

a1batross ★★★★★
() автор топика
Последнее исправление: a1batross (всего исправлений: 1)
Ответ на: комментарий от a1batross

И я просто не хочу тратить на него своё время и не советую другим, если у вас нет существующего проекта с CMake.

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

yvv ★★☆
()
Ответ на: комментарий от RazrFalcon

А что с альтернативами? meson?

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

При всех своих проблемах больше всего распространены только cmake и autotools. Все остальные - экзотика. Новые появляются и исчезают, эти пока остаются.

sena ★★
()
Ответ на: комментарий от a1batross

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

а месон - г-но, кстати.

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

anonymous
()

А я уже пользуюсь этой версией с выхода версии RC.

rumgot ★★★★★
()
Ответ на: комментарий от a1batross

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

anonymous
()
Ответ на: комментарий от RazrFalcon

A curated list

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

anonymous
()
Ответ на: комментарий от anonymous

Предлагаю высказать «cmake это просто, если ты не пилишь на нём говнокод в 1000 строк» в /usr/share/cmake/Modules. А это между прочим пишут те же люди, что и сам CMake.

a1batross ★★★★★
() автор топика
Ответ на: комментарий от sena

При всех своих проблемах больше всего распространены только cmake и autotools.

Ну вот meson это понимают и сделали cmake subprojects. Оно запускает сборку cmake (можно передавать параметры), парсит AST и строит по нему свой subproject.

Пробовал. Если нет зависимостей от custom_target-ов, и нет внутренних зависимостей то, в принципе, оно неплохо работает. Как минимум избавляет от необходимости переписывать сборку библиотек-сабпроджектов (ну или обходиться минимальными правками CMakeLists.txt)

SkyMaverick ★★★★★
()
Ответ на: комментарий от a1batross

/usr/share/cmake/Modules

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

если в проекте один такой модуль, то может ещё покатит, если десяток, то это уже непортируемо даже между дистрибутивами линукса. это надо просто игнорировать по возможности.

ещё раз повторю: чтобы не стрелять себе в ногу надо не стрелять себе в ногу. эти модули не для вашего хомяка, а для пакетов которые являются частью дистрибутива.

anonymous
()

Кстати. Может кто поделится мыслями. Будут ли документированы функции команды file (RPATH_CHANGE, RPATH_CHECK, RPATH_REMOVE, READ_ELF)?

rumgot ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

rumgot ★★★★★
()
Ответ на: комментарий от RazrFalcon

А как же карго? Или ты не только на растишке катаешь?

Довести бы до ума https://shakebuild.com/ - хорошая задумка, только вкурить сходу сложно. Или у меня руки из зопы растут…

q0tw4 ★★★★
()
Ответ на: комментарий от rumgot

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

anonymous
()
Ответ на: комментарий от anonymous

Проблема только в том, что без этих модулей CMake ничего из себя не представляет. Ни тебе ExternalProject, ни CMakeDependentOption, ни CheckЧтонибудь, ни лапши из Find*, которую героически Kitware пытались писать, но походу потихоньку забивают.

a1batross ★★★★★
() автор топика
Ответ на: комментарий от a1batross

а мне норм. монорепозиторий решает большинство «проблем симейка». не использую ни external, ни check, ни find, рад за всех кто там что-то переписывает или не переписывает, всем желаю удачи и машу рукой.

anonymous
()
Ответ на: комментарий от anonymous

Ну, похвально тогда. А ты можешь показать что за проект или он не открыт? Не троллинга ради, я прекрасно понял о чём ты. Просто интересно.

a1batross ★★★★★
() автор топика
Последнее исправление: a1batross (всего исправлений: 1)
Ответ на: комментарий от mittorn

Если очень-очень хочется python, то есть SCons. Но в нём,как минимум, есть свои заморочки с передачей ему переменных окружения - в некоторых случаях то ещё удовольствие. То есть по умолчанию он о них ничего не знает, имитируя «изолированную» среду.

grem ★★★★★
()
Ответ на: комментарий от grem

Автор Waf и вдохновлялся отчасти SCons. Вроде даже какие-то первые версии, когда проект ещё не имел такого названия, имели что-то общее с SCons. Но в итоге, проект не имеет к нему никакого отношения.

a1batross ★★★★★
() автор топика
Ответ на: комментарий от a1batross

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

anonymous
()
Ответ на: комментарий от a1batross

Эх, а ведь waf мог бы использоваться проектом kde, но не успел. Но пишут, что он лучше для крупных проектов, чем SCons, который более популярен в научных проектах.

grem ★★★★★
()

Какой же мерзотный этот CMake. Каждый раз, как с ним сталкиваешься, хочется вымыть руки с мылом.

Скоро он займёт почетное звание заменителя умирающего autotools по степени упоротости.

И ведь есть же в этом мире более удачные системы сборки, которые приятно использовать: Meson, Waf, QBS и какой-нибудь там Premake. Но нет, выиграет всеобщее использование обязательно самая мразотная и ублюдочная сборочная система. Что раньше autotools, что сейчас CMake.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Это удел линуксов и систем сборок. Но у autotools есть одно преимущество перед cmake - его можно запустить где угодно где есть sh и make. В то время как cmake придётся бутстрапить

mittorn ★★★★★
()

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

vertexua ★★★★★
()
Ответ на: комментарий от i82

Вспоминается xkcd про стандарты.

Уже был питонорождённый scons, теперь у нас питонорождённый meson.
Потом ещё какую-нибудь новую хрень придумают на питоне.
И апологеты новинки будут бегать и кричать, что всё остальное говно, юзайте *super_fkn_new_build_system_name*.

WatchCat ★★★★★
()
Ответ на: комментарий от RazrFalcon

Вроде можно обмазаться еще на уровень выше и юзать Conan для генерации CMake говна.

Надо бы еще https://bazel.build/ потыкать.

Я если что просто мимопроходил.

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

Нет. Cmake может генерить не только для различных make'ов или ninja файлы, но и файлы проектов для VS, XCode etc.

WatchCat ★★★★★
()
Ответ на: комментарий от yvv

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

Slackware_user ★★★★★
()
Ответ на: комментарий от vertexua

единственный существенный плюс - отсутствие поддержки всякого ископаемого и поддержка основных ос - Win32 Mac Linux BSD

Slackware_user ★★★★★
()

Сборку проекта любой сложности проще описать сразу в Makefile чем возиться с CMake. Хотя если не использовать своих модулей которые придётся таскать с собой то он удобен, наверное. Короче, сколько лет его знаю так я его и не понял :D

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от vertexua

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

SkyMaverick ★★★★★
()
Ответ на: комментарий от SkyMaverick

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

С поддержкой модулей и остальных костылей.

Все могут, а С++ не может. Я думаю ерунда, надо начать делать.

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

пакетный менеджер нужно делать частью языка

Ду-у-умаешь?.. меня почему-то не покидает ощущение какой-то наколеночности и нубскости этого подхода. Я один такой? Все эти нпмы и пипы. Преимущества есть, не спорю, но нутру всё равно не нравится. Мб это потому, что долгое время писал на сях.

PamidoR
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.