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 ()

Ответ на: комментарий от vertexua

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

А если проект писан не на одном языке? Вот как выше спросили смесь С с Fortran?

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

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

Само понятие «система сборки» – это уже имбецилизм прошлого века. Ты ещё что-то там на вонючий autotools гнал, а сам дрочишь просто на другое говно, но всё равно на говно. Это всё равно что сравнивать cvs и svn, вместо того чтобы просто использовать git. Думается, что «системы сборки» специально придумали в качестве коллектора для кретинов. Просто чтобы они трахались с ними, и не лезли в код. Весьма умное решение. Столлман таким вгонял толпы школьников в депрессию, которые мнили себя мамкиными кулцхакерами.

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

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

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

Само понятие «система сборки» – это уже имбецилизм прошлого века.

Ваши предложения? Чем собирать монстурозный проект на 100500млн строк из 10ти языков?

yvv ★★☆ ()

Эх, добавили бы нативную поддержку верилога, а то тулы cadence с поддержкой msie и многопоточной элаборации/компиляции приходится интегрировать через custom_target’ы и разруливать ад зависимостей на большом проекте.

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

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

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

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

Оптимизировать под 95% окупается. Тогда быстро развивается экосистема.

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

Более того что чаще всего проекты не состоят из микса языков в одинаковых ролях. Обычно есть основной код и завёрнутые библиотеки. Вот для этого придумали горы врапперов.

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

вменяемого аналога с затягиванием зависимостей по конфигу

начнутся вскукореки про монорепы. это же исходники надо конпелировать - слишком сложно для с/с++. давай лучше готовый curl.dll с warez.org - вот это было бы норм.

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

слишком сложно. а сборочные скрипты откуда? а субмудуль оно само сделает? это думать надо. не, давай curl.dll скомпиленый visual studio 2015, збс будет экосистема.

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

На QMake далеко не уедешь.

В смысле? Нормальная такая тяговая лошадка. И очень компактная по записи. Да, парсер можно было бы сделать более вменяемым.

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

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

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

Ваши предложения? Чем собирать монстурозный проект на 100500млн строк из 10ти языков?

Моё предложение – продолжать говорить школьникам и умственно отсталым, что системы сборки, любые, – говно для имбецилов. И когда нарисуется какой-нибудь вася с традиционным вскукореком: «а что ваще», – продолжать это делать.

Лично мня радуют все существующие системы сборки – нужно же как-то занимать кретинов, чтобы не лезли в код.

П.С.: самый прикол в том, что любой вася, у которого подгорает от систем сборки начинает придумывать свою или искать другую. Цикл длиною в жизнь. Провести отсталого от школьной скамьи до могилы так, чтобы он этого не заметил, и при этом что-то о себе мнил – идеальное решение. Вива, системы сборки. А я пока займусь кодом. Спасибо за внимание.

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

Тогда, действительно, в сторону waf посмотри. Замастерить его еще тяжелее, чем CMake, и документацию еще нужно разобраться, как вкуривать, но поглядывая на примеры и исходники более-менее реально. Да и Наги специфичный чувак…

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

Фактически, это три в одном: на верхнем уровне ты описываешь свои таргеты и из чего они состоят. Только в отличие от add_custom_* на таргеты вешаются «фичи». Затем второй уровень, эти фичи трансформирует в низкоуровные таски (что-то ближе к рулям ниндзи и мейка), и собственно, на самом нижнем уровне сам шедулятор этих тасков.

То есть, он дает доступ ко всем уровням и достаточно хорошую интроспекцию / рефлексию проекта, чего не хватает(ло?) в CMake: часто хотелось: а дай мне все таргеты с таким проперти, чтобы их как-то трансформировать.

Из минусов - интегрируется с IDE только через кастомные таски (то есть надо вызывать из командной строки), но сейчас почти все умеют в compile_commands.json, поэтому киллер-фича CMake, где он генерирует солюшен, уже не так актуальна. Да и у тебя, для верилога, наверное не работало.

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

Не вариант, как раз интеграция с IDE и ctest это то, ради чего с cmake и связались, чтобы все программные тесты можно было вытащить как подпроект из сборки микросхемы, и отгрузить в виде bare metal SDK самого первого. А уже его некоторые потребители хотят вообще в винде собирать.

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

🤷‍♂️ мое дело предложить. Cmake умеет для верилога v?proj генерировать или в чем интеграция заключается? Ещё как-то не очень понял про программные тесты. Я в создании fpga совсем мало знаю 😐

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

В смысле?

С кросс-платформенностью там плоховато и с подключением сторонних библиотек.

DSL у QMake по степени упоротости может потягаться с CMake’овским. Чего, например, стоит захаркоженный стиль кодирования 1TBS:

static 
{
   something
}

# ^ Parse Error ('static') Unterminated conditional

static {
   something
}

# ^ Ok

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

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

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

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

Сок, так сок. Ещё круче.

Ну ещё из полезных тулзов могу порекомендовать Conan.

В твоём случае, я бы сделал низкоуровневую часть на чем удобно, а то, что спускается в downstream - пакетировать конаном. Кроме того, что подпроект пересобирать не надо, он ещё может под cmake таргеты делать.

Его под embedded тоже пытаются пользовать, например include os. Да и вообще для корпоративной разработки штука приятная. Я с его помощью blinky делал ☺️ бутстрапил gcc-arm, openocd и ещё утащил у modm инициализацию. Поинт был как раз в использовании привычных тулзов (vs Code в моем случае), причем с полноценным пониманием всех define и навигацией по коду и дополнением (да, для blinky это тоже важно 😁), а не какой-то стремный Arduino ide… И все это прозрачно и однообразно и на линуксе, и на винде.

С другой стороны, если уж у вас куча всего понаписано под cmake, лучше не трогать, пока совсем не припрет…

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

Но у autotools есть одно преимущество перед cmake - его можно запустить где угодно где есть sh и make

И это далеко не единственное преимущество.

  • Простота кросс-компиляции: configure –host=$(то-что-написано-в-начале-твоего-gcc). Не надо писать на каждый чих тулчейн-файл.
  • configure, созданный autoconf, всегда имеет опцию –help c человекопонятным описанием опций проекта. В случае с cmake лучшее, что есть - это ccmake (или cmake-gui), в которых а) нужно повозиться, чтобы отделить опции коретного проекта от всего остального и б) их интерфейс явно не рассчитан на отображение справки длинней одной строки на каждую опцию (да и хорошо, если авторы проекта вообще хоть что-то там пишут). Кроме того, cmake позволяет легко и непринужденно создавать недокументированные опции проекта, узнать о которых можно только из его кода
  • проект на autotools поддерживает набор стандартных переменных, которые можно задавать на стадиях configure и make. В cmake поддерживается не все, не везде, и многое зависит от доброй воли разработчика проекта.
annulen ★★★★★ ()
Ответ на: комментарий от mittorn

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

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

Посмотри в сторону опции link_language. До версии 0.51 было автоматическое определение, это решили дополнить явным указанием компилятора.

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

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

Просто за новую систему сборки на плюсах или сишке могут взяться только совсем отбитые люди (если это не совсем низкоуровневая штука вроде ninja)

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

CMake норм, ты просто его готовить не умеешь.

большинство проектов его тоже готовить ни черта не умеют.

То есть это такой аналог рыбы фугу. Приготовишь неправильно — скопытишься.

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

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

Ага, ерунда. Всего-то сорокалетний язык с десятком+ систем сборки.

В Комитете таки хотят что-нибудь с этим сделать, есть подгруппа про это. Но сначала модули.

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

И это далеко не единственное преимущество

И правда.

  • Истинная кроссплатформенность: самая популярная ОС и ее компилятор для автотулзов не существуют. Главное - существуют все платформы, если они GNU. Хотя бы притворяются GNU.

  • Библиотечка, собирающаяся за 2 секунды, с автотулзами будет собираться всю минуту, что добавляет энтерпрайзности. Матрица в консоли при этом повышает уровень хакерства.

  • Ахив с исходниками библиотечки вырастает в размерах на порядок за счет нечитаемых талмудов на древних языках. Еще больше энтерпрайзности.

  • Неважно, что все равно придется установить сборочное окружение на полгига минимум. Главное - ничего специально не надо устанавливать, только sh и make!

  • И вообще, какая эстетика: смесь sh, m4 и perl. Для тех, кто познал жизнь.

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

Главное - существуют все платформы, если они GNU

ЛПП, изначально автотулзы предназначались для портирования софта на всевозможные юниксы, ИЧСХ успешно решали эту задачу.

С виндой, конечно, не все так гладко, но даже для msvc есть обертка

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

Ахив с исходниками библиотечки вырастает в размерах на порядок за счет нечитаемых талмудов на древних языках

Откуда такие цифры?

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

Откуда такие цифры?

И вообще, какая эстетика: смесь sh, m4 и perl. Для тех, кто познал жизнь

Конечный пользователь в нормальной ситуации ни с чем из этого не взаимодействует. А если что-то серьезно поломано, то sh в configure большинству людей дебажить гораздо проще, чем ковыряться в чужом cmake

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

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

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

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

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

Чего, например, стоит захаркоженный стиль кодирования 1TBS:

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

С кросс-платформенностью там плоховато и с подключением сторонних библиотек.

Тут вопрос — а где лучше?

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

В Комитете таки хотят что-нибудь с этим сделать, есть подгруппа про это.

ВАААААУ!

У них есть уже какие-то черновики, наработки? Интересно было бы почитать…

hobbit ★★★★★ ()