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)
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от EXL

уже перешли

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

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

Это ты протри глаза, пробегись по цепочке ответов и посмотри на какое сообщение (не тебе, кстати адресованное) ты ответил.

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

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

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

Внедрение Meson форсируют разработчики одной известной шапки.

Так что, мезон под шапкой? Они его разрабатывают? А симейк?

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

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

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

я не помню чтобы x.org, gimp и mesa

… mesa …

ЕМНИМ Mesa недавно с autotools на meson перешла (не все были согласны, но к счастью разум победил), cmake не при делах.

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

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

Мне как разработчику критично было что cmake генерирует не только мэйкфайлы, но и проекты IDE, и при желании ninja. И через это правильно поддерживает винду (и что угодно, без оглядки на posix). Это и есть честная кроссплатформенность. В перспективе также интересен CPack.

Ах да, киллер-фича: цветной прогресс-бар в консоли.

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

Windows пытается косить под Linux эмуляцией экосистемы разработчика

Что за бред? Использовать git это уже косить под линупс? При том, что в винде первоклассная экосистема разработчика с начала времён. Пеши ищо короч.

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

На meson переходят проекты так или иначе связанные с шапкой, а именно: gtk, gnome, wayland и компания. Gimp не исключение. Postgresql, Blender, MySql даже не рассматривают подобный переход.

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

Скорее всего gimp не исключение, так как хостится на гитлаб сервере gnome, а всякий travis ci там настроен в основном на использование в связке с meson. Ну и действительно может быть общая рекомендация их проектов.

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