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)

 ← 1 2 3 4 →
Ответ на: комментарий от anonymous

Я думаю мы это будем ждать еще примерно столько сколько ждем модули. Т.е. гдето в районе c++-40

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

Про Конан впервые слышу. Спасибо, анон, посмотрю. Пока как раз я это все цмейком разваливаю и с вскод/атомом интеграция хорошая

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

Уже 3.16? 3.5 кажется чуть ли не вчера была.

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

Какие-то соображения про пакетный менеджер есть тут: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1254r0.html

Там же есть несколько печальное:

There is not and will not be a standard build system. The existing diversity is too large.

Это, правда, мнение автора пропозала, но видимо не только его.

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

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

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

Они умеют работать с разными компиляторами? Несовместимыми с gcc?

На freebsd для кучи пакетов приходится ставить gmake. Если это неправильно приготовленные автотулзы, тогда вопрос - почему вообще они заставляют руками писать куски make.

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

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

Из своего опыта. А у тебя какие? Исходники меньше 100 Кб, один configure - емнип, полмегабайта. И еще m4/, и еще что-то было. Не помню, ушел с них давно. Такое-то удовольствие - дистрибьютить автогенеренное и просто тупо скопированное. Ага, автономность, только непонятно для кого и зачем.

Конечно, есть autogen.sh, но тогда приходим к той же модели что у cmake.

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

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

Ну сколько занимает build-essentials? Емнип, сотни МБ, даже не беря C++ с фреймворками.

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

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

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

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

Они умеют работать с разными компиляторами? Несовместимыми с gcc?

Конечно, именно для этого autotools изначально и создавались. Я так и узнал про них, собирая софт под SCO UNIX.

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

Мне казалось, я видел завязки на gcc. Ну ок, спорить не буду.

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

Не, b2 без перспектив. Его в самом бусте видят как легаси, и вяло пытаются перетащить буст на cmake.

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

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

Это очень спорное преимущество. Я бы предпочёл удобную кросс-сборку проектов на хосте этому.

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

autotools умеют работать с разными компиляторами? Несовместимыми с gcc?

Да, нужно лишь изменить пару переменных окружения, типа такого

AR='ar-lib lib' CC='compile cl -nologo' CXX='compile cl -nologo' NM='dumpbin -symbols' WINDRES='compile rc -nologo' LD='link -nologo' STRIP=':' RANLIB=':' CFLAGS='-MD -EHsc' CXXFLAGS='-MD -EHsc' PKG_CONFIG_PATH=С:/tools/vcpkg/installed/x64-windows/lib/pkgconfig PKG_CONFIG=С:/tools/vcpkg/installed/x64-windows/bin/pkg-config.exe ./configure
make

и будет работать с MSVC…

Узнал про это смотря https://github.com/microsoft/vcpkg и как там собирают пакеты, которые собираются autotools…

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

Спасибо, интересно попробовать.

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

Каждый раз как собираю ffmpeg под виндой проклинаю autotools. Более забагованного и тормозного ужаса придумать невозможно.

Угрёбищность autotools под Windows дополняет тамошний тормозной I/O. Всё это создание тысячи файлов на каждый чих, вызов десятка разных утилит, чтобы проверить sizeof(int) == 4 или нет, мало того, что в современном мире являются дичью и анархизмом, так ещё и тратят время на подобную чепуху.

В этом плане CMake, который не предлагает тебе дебильных проверок по умолчанию для UNIX’ов из 70-ых годов, выглядит лучше.

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

Ну это как посмотреть.

Для CMake я должен открывать редактор и писать какой-то там ToolChain-файл, вспоминая про угрёбищность синтаксиса CMake.

А для autotools я должен помнить про ахинею в виде target/host/build-ключей, которые сегодня обозначают не то, что все привыкли ожидать, вроде того что host это не хостовая система, а целевая.

удобство кросс-сборки у cmake и autotools одинаковое.

Одинаково хреновое.

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

Угрёбищность autotools под Windows дополняет тамошний тормозной I/O. Всё это создание тысячи файлов на каждый чих, вызов десятка разных утилит, чтобы проверить sizeof(int) == 4 или нет, мало того, что в современном мире являются дичью и анархизмом, так ещё и тратят время на подобную чепуху.

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

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

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

Серьёзно? С каких это пор ахинея и нелогичное говно вроде:

$ cmake . -DSDL=yes && make
$ cmake . -DSDL2=yes && make

(CMake за счёт кэша будет считать, что SDL должен равняться YES даже во втором вызове)

Удобны для разработчика?

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

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

На Windows (и иногда кстати на Linux) на некоторых проектах до смешного доходит: вся эта коричневая autotools мишура отрабатывает дольше чем, собственно, сама компиляция исходного кода.

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

Конечно, есть autogen.sh, но тогда приходим к той же модели что у cmake.

Нет, эта модель намного хуже. В CMake есть хоть какая-то обратная совместимость. А в этом говне постоянные ошибки связанные с каким-нибудь automake или autoconf из-за чего требуется брать и ставить пакеты предыдущих версий этого говна, чтобы собрать софт:

core/automake 1.16.1-2 (base-devel) [installed]
    A GNU tool for automatically creating Makefiles
aur/automake-1.11 1.11.6-2 [installed] (6) (0.00)
    A GNU tool for automatically creating Makefiles
aur/automake-1.14 1.14.1-2 (Out of Date) (6) (0.00)
    A GNU tool for automatically creating Makefiles
aur/automake-1.15 1.15.1-2 (0) (0.00)
    A GNU tool for automatically creating Makefiles
aur/automake-1.7 1.7.9-1 (15) (0.00)
    A GNU tool for automatically creating Makefiles

core/autoconf 2.69-6 (base-devel) [installed]
    A GNU tool for automatically configuring source code
extra/autoconf2.13 2.13-5 [installed]
    A GNU tool for automatically configuring source code (Legacy 2.1x version)

Это хорошо, если дистр позволяет такое сделать. А в каком-нибудь Deb-based или Rpm-based это всё выливается в такую чехарду с накатыванием древних пакетов из помоек, что хочется пробить голову вилкой тому мудаку-разработчику, который забыл сгенерировать configure скрипт для своего проекта.

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

Я так и узнал про них, собирая софт под SCO UNIX.

А какой компилятор был в давно уже почившем SCO UNIX?

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

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

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

Вообще по поводу всего этого autotools и сопутствующего говна залитого в UNIX-like системы, есть одна классная статья от Poul’а-Henning’а Kamp’а:

Оригинал: A Generation Lost in the Bazaar
Перевод: Поколение, затерянное на базаре

Позволю себе привести некоторые цитаты оттуда:

Вместо того, чтобы стандартизировать UNIX и исключить необходимость этих скриптов, какой-то умник написал программу autoconf, чтобы автоматически генерировать configure-скрипты.

Сегодняшние UNIX/Posix-образные системы, даже если учитывать версию IBM z/OS mainframe, с точки зрения наблюдателя из 1980 практически одинаковы. До сих пор 31 085 строчек кода configure скрипта для libtool проверяют наличие <sys/stat.h> и <stdlib.h> не смотря на то, что даже те никсы, в которых их не хватало, не имели достаточно памяти, чтобы запустить libtool; или места на диске, чтобы уместить 16 Мб исходного кода libtool.

Само собой разумеется, адекватные программисты никогда бы не пожелали добровольно копаться в M4, даже если бы у них был навык, поэтому эти скрипты для autoconf создаются методом копипасты, часто оказываясь затерянными среди чрезмерно жирных стандартных макросов, покрывающих «стандартные тесты». Да, те самые тесты, проверяющие наличие проблем совместимости, с которыми никто не сталкивался уже лет 20.

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

Ну а для тех товарищей, кто хоть раз задумывался о том, что использование макросов m4 для конфигурации autoconf для генерации shell-скрипта для проверки наличия 26 компиляторов Fortran с целью собрать веб-браузер — это как-то немного через жопу, Брукс предложил хорошо аргументированную надежду, что у нас есть шанс всё исправить.

Статью реально можно на цитаты разбирать, чтобы потом тыкать в них носом особо назойливых любителей autotools.

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

ССЗБ

Что выбрал CMake? Ну тут и не поспоришь!

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

Я так и узнал про них, собирая софт под SCO UNIX.

А какой компилятор был в давно уже почившем SCO UNIX?

Свой собственный какой-то, как у большинства Юниксов… Даже был с++, но в виде препроцессора.

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

Да, всегда поражало, какой хренью оно занимается.

Это в лучшем случае подходит для другой эпохи и других применений, чем то что на него вешают сейчас.

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

Все таки все это код внутри. А какой user experience у разработчика?

Вот CMake например - вроде штука новее. И что? Лучше стал experience? Нету этих древних проверок, а все равно конфиги какие-то беспощадно тупые, хрупкие, их легко написать плохо. Он все равно приспосабливает код к системе, а не требует чтобы система была стандартной (как говорится в статье).

Так что мне кажется вопрос именно в нестандаризированости среды. Эти скрипты каждый раз высаживаются на темную планету с фонариком и пытаются куда-то дойти.

C/C++ нужно просто больше convention over configuration, а разрабам больше смелости чтобы НЕ поддерживать нестандартное говно.

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

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

есть одна классная статья

несерьёзно

Вместо того, чтобы стандартизировать UNIX и исключить необходимость этих скриптов, какой-то умник написал программу autoconf, чтобы автоматически генерировать configure-скрипты.

David Mackenzie (автор аутотулз) должен был стандартизировать зоопарк коммерчесских Юниксов? Как? Что за бред?

Аутотулз был единственным в своём роде инструментом, ничего подобного очень долго не было. Благодаря аутотулз было много достигнуто в плане распространения и популяризации свободного софта и подготовили переход на ГНУ/Линукс, когда он появился.

Благодаря аутотулз народ сидевший под Юниксами собирал гнушный софт и когда появился ГНУ/Линукс переход был абсолютно прозрачным и даже стремительным.

тыкать в них носом особо назойливых любителей autotools

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

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

Я не думаю что главный message - уменьшить историческую значимость autotools когда все что они делают было релевантно. Это больше обсуждение что делать сейчас, когда линукс победил, торчит из каждой микроволновки и все дистры причесаны быть почти одинаковыми для сборки софта. BSD закопан кроме трех die hard калек, Windows пытается косить под Linux эмуляцией экосистемы разработчика

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

несерьёзно

На серьёзность там никто не и претендовал, статья изначально в ироничном ключе описывает современную ситуацию с autotools и задаёт резонный вопрос «что делать дальше?»

David Mackenzie (автор аутотулз) должен был стандартизировать зоопарк коммерчесских Юниксов? Как? Что за бред?

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

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

И по сей день остаётся одним из самых распространённых инструментов и выполняет свою задачу.

В том-то и вопрос, какую задачу сегодня выполняет autotools? Практически все коммерческие UNIX’ы сегодня канули в лету. Немногие оставшиеся – фактически подстроились под Linux. Сюда же и отсутствие зоопарка компиляторов можно приплести.

Для сборки ПО в большинстве случаев сегодня не требуется проверять sizeof(int) и подобное. А для генерации Makefile есть более удобные генераторы. Да что там говорить, даже Makefile уже отходит на второй план и заменяется ninja или compile_commands.json

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

И по сей день остаётся одним из самых распространённых инструментов и выполняет свою задачу.

В том-то и вопрос, какую задачу сегодня выполняет autotools?

Мне трудно ответить на этот вопрос, не имея полной картины. Здесь серьёзное исследование нужно проводить (хотя бы багтрекер аутотулзов почитать :) ). Я сам аутотулз только один раз в жизни использовал в качестве разработчика, симейк мне больше понравился. Живу и дома и на работе под ГНУ/Линуксом, потому мне тоже очень трудно судить про другие системы, сколько их и какая есть потребность в их поддержке. Но вообще если так рассуждать, то поддержка Линукса не нужна, в основном-то нужен Андроид, Виндос и Айос :).

Есть и другие аспекты, кроме технических. Например аутотулз живёт под крылом ГНУ проекта. А под кем ходит симейк? Там корпорациями не пахнет?

И ещё, несмотря на то что современные, более быстрые и простые (типа cmake) альтернативы есть, массового перехода старых проектов на них не наблюдается. Я думаю приростает симейк в основном из-за новых проектов.

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

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

Makefile уже отходит на второй план и заменяется ninja или compile_commands.json

бггг.

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

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

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

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

И ещё, несмотря на то что современные, более быстрые и простые (типа cmake) альтернативы есть, массового перехода старых проектов на них не наблюдается. Интересно было бы также послушать истории типа «надо фичу Х но её нет в симейк, поэтому взял аутотулз» и наоборот.

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

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

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

Но вообще если так рассуждать, то поддержка Линукса не нужна, в основном-то нужен Андроид, Виндос и Айос :).

Куда-то вас совсем не туда понесло. Почему-то все воспринимают Linux как десктопную систему, забывая, на минуточку, всю ту кучу серверов и всяких роутеров на нём. Под которые тоже компилируется и собирается софт. И далеко не энтузиастами. Одно дело, когда мы рассуждаем о том, что проверка 17 флагов проприетарных компиляторов SCO Unix в autotools сегодня не нужна, потому что SCO Unix скопытился и другое когда кто-то заявляет о ненужности Linux.

массового перехода старых проектов на них не наблюдается. Я думаю приростает симейк в основном из-за новых проектов.

Ну как сказать, вот, например, X.Org и Mesa перешли недавно на Meson. GNOME тоже переполз. Чем не знаковые проекты мира GNU/Linux?

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

Боюсь, таких историй практически не существует. Сегодня практически все новые проекты выбирают либо CMake, либо Meson вместо autotools.

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

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

Уж лучше Gradle, чего мелочиться!

Видел пару проектов, которые используют его для сборки кода на C и C++.

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

CMake, ещё недавно был относительно новым, однако я его никогда не любил. Хоть он был и есть замена старому autotools.

Тратить своё время на изучение M4 или на лапшу Makefile’ов, в которых ещё и нельзя пробелами отступы делать, когда в современном мире имеется возможность быстро и легко описать сборку декларативно и получить нормальную многопоточность из коробки в довесок? С ужасом вспоминаю как 10 лет назад некоторые проекты после make -jN собирались не полностью.

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

Сегодня практически все новые проекты выбирают либо CMake, либо Meson вместо autotools.

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

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

Ну как сказать, вот, например, X.Org и Mesa перешли недавно на Meson. GNOME тоже переполз. Чем не знаковые проекты мира GNU/Linux?

Довольно заметные проекты. Но по-моему зря они спешат… Мезон в Убунте появился с 16 версии, в Дебиане первый раз с 8й. Слишком юн для серьёзных проектов. Года 3-4 ещё выдержать надо.

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

CMake, ещё недавно был относительно новым

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

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

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

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

Проекты так или иначе с главными разработчиками от шапки не в счёт.

Позови когда Blender, Boost и другие монстры начнут переходить на это самое.

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

Позови когда Blender, Boost и другие монстры начнут переходить на это самое.

Ты так заявил, как будто они на autotools, а не на CMake и b2. Они уже перешли.

EXL ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 →
Разработка