Доступен релиз кроссплатформенного открытого генератора сценариев сборки CMake 3.11 (http://www.cmake.org/), выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD.CMake примечателен предоставлением простого языка сценариев, средствами расширения функциональности через модули, минимальным числом зависимостей (нет привязки к M4, Perl или Python), поддержкой кэширования, наличием инструментов для кросс-компиляции, поддержкой генерации файлов сборки для широкого спектра систем сборки и компиляторов, наличием утилит ctest и cpack для определения сценариев тестирования и сборки пакетов, утилитой cmake-gui для интерактивной настройки параметров сборки.
Основные улучшения (https://cmake.org/cmake/help/v3.11/release/3.11.html):
- В генератор сборочных файлов Ninja добавлена поддержка компиляторов
TI C/C++ (http://www.ti.com/tools-software/compilers/features-benefits...);- В генераторах для Visual Studio появилась возможность использования условного выражения COMPILE_LANGUAGE при определении значений COMPILE_DEFINITIONS, INCLUDE_DIRECTORIES, COMPILE_OPTIONS и file(GENERATE). В генераторе Xcode поддержка условного выражения COMPILE_LANGUAGE обеспечена для COMPILE_DEFINITIONS и
INCLUDE_DIRECTORIES (в COMPILE_OPTIONS и file(GENERATE) уже поддерживалась ранее);- Компанды add_library() и и add_executable() теперь могут вызываться без наличия исходных текстов с расчётом, что код будет добавлен позднее при помощи команды target_sources();
- В команду target_compile_definitions() добавлено свойство INTERFACE_COMPILE_DEFINITIONS, в команду target_compile_features() - INTERFACE_COMPILE_FEATURES, в target_compile_options() - INTERFACE_COMPILE_OPTIONS, в target_include_directories() - INTERFACE_INCLUDE_DIRECTORIES, в target_sources() - INTERFACE_SOURCES, в target_link_libraries() - INTERFACE_LINK_LIBRARIES;- В свойстве исходных файлов "COMPILE_DEFINITIONS" добавлена поддержка выражений генератора;
- Свойство исходных файлов COMPILE_OPTIONS добавлено в список опций, передаваемых компилятору;
- При использовании свойств AUTOMOC или AUTOUIC, CMake теперь параллельно запускает несколько процессов moc или uic для сокращения времени сборки. Число процессов определяется через переменную CMAKE_AUTOGEN_PARALLEL и свойство AUTOGEN_PARALLEL (по умолчанию выставляются в значения, соответствующие числу CPU).URL: https://blog.kitware.com/cmake-3-11-0-available-for-download/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48352
ха-ха, рядом новость про QBS!
> минимальным числом зависимостейда ну нах?
/usr/ports/devel/cmake/Makefile:LIB_DEPENDS= libcurl.so:ftp/curl \
/usr/ports/devel/cmake/Makefile- libexpat.so:textproc/expat2 \
/usr/ports/devel/cmake/Makefile- libjsoncpp.so:devel/jsoncpp \
/usr/ports/devel/cmake/Makefile- libuv.so:devel/libuv \
/usr/ports/devel/cmake/Makefile- librhash.so:security/rhash
/usr/ports/devel/cmake/Makefile-
/usr/ports/devel/cmake/Makefile-USES= compiler:c++11-lang libarchive ncurses
--
/usr/ports/devel/cmake/Makefile:MANPAGES_BUILD_DEPENDS= sphinx-build:textproc/pyа самое приятное - вот это:
/usr/ports/devel/libuv/Makefile:USES= autoreconf libtool pathfix pkgco
т.е автоконф (вместе со всем хламом в виде перла и m4) тоже никуда не делся, "мы не выкинули пончики, они с нами летят", он вам понадобится чтобы собрать архинужную и полезную (кто знает, этот кусок г-на вообще зачем?) деталь для самого cmake. Йа его слепила, из того что было.Знаете, я лучше на autotools останусь, они хотя бы циклических зависимостей не содержат. m4 и перл собираются без автотула, m4 и перла. В том числе потому, что авторы немножко думали головой, а не тащили в рот все что с полу поднято.
> т.е автоконф (вместе со всем хламом в виде перла и m4) тожеПуссиэкзешники должны страдать!
https://packages.debian.org/ru/sid/cmake
> Знаете, я лучше на autotools останусьЗамшелым и ничего толком на современных системах не умеющим? Прям подстать бздам ))
и что вы мне этой ссылкой хотели показать, кроме того что еще и по-английски не умеете?
У вас там точно такая же зависимость от libuv (она,кстати, собирается не только autotools, но и cmake. Уп-с... но мы пытаемся собрать cmake!), часть остальных попрятаны в косвенные зависимости.> Замшелым и ничего толком на современных системах не умеющим?
да куда уж ему, даже без libuv собран.
asynchronous event notification library как нам подсказывает ваша ссылка. Эта хрень ведь ну очень нужна в системе, йопаралон, генерации makefile'ов ? Вы без нее не можете, у вас гироскутер укатится?
Впрочем, есть и прекрасные образцы использования autoconf:
# systemd support.
AC_ARG_WITH([systemd],
AS_HELP_STRING([--with-systemd], [support systemd socket activation]),
[], [with_systemd=check])
have_systemd=no
if test "x$with_systemd" != "xno"; then
PKG_CHECK_MODULES(systemd, [libsystemd-daemon],
[AC_DEFINE(HAVE_SYSTEMD, 1, [Define if systemd is available])
have_systemd=yes],
have_systemd=no)
if test "x$have_systemd" = xno -a "x$with_systemd" = xyes; then
AC_MSG_ERROR([systemd support requested but libraries not found])
fi
fiэто все.
В смысле - это вообще единственное в этой (довольно распространенной) программке в аж 870 строк, для чего на самом деле используется autoconf. (еще он проверяет наличие нескольких системных вызовов и .h и тупо вываливается, если не нашел - зачем было проверять, непонятно, оно что так не соберется, что этак)да-да, вы правильно поняли - вся эта мура понадобилась автору потому, что сам написать мегаскрипт configure с единственным параметром with/without systemd он ниасилил.
Я, в общем, практически уверен, что почти все использования cmake примерно такого же сорта.
> У вас там точно такая же зависимость от libuv (она,кстати, собирается не только autotools, но и cmake. Уп-с... но мы пытаемся собрать cmake!)А компилятор без компилятора ты уже собрал?
слив засчитан.
То есть факт звиздежа про "миниимум зависимостей" (вместо аж двух у automake) опровергнуть не получилось, пришлось приступить к подмене понятий.
Ты эта, runtime от buildtime зависимости отличай и make clean не забывай делать. По runtime cmake не зависит от autotools.
> По runtime cmake не зависит от autotools.вам там показали кучу чудовищного уродливого bloatware, от которого зависит.
Но вы продолжайте петь сказки, что у него "мимими...минимальные зависимости". Главное, ставьте софт из пакетиков, и ни в коем случае не думайте своей головой, за вас уже все подумали.А правильное использование autotools вообще не предполагает их наличия и запуска на системе, где занимаются сборкой - configure зависит только от /bin/sh (и только сравнительно недавно его наконец испортили настолько, что если это не bash, то обязан быть bsd sh - раньше оно работало бы даже на совсем странных или древних системах)
Именно потому, что этап конфигурации и сборки информации о системе совершенно намеренно отделен от этапа сборки информации о проекте.
Это еще те, олдовые гнушники писали, они умели. Пользуются, к сожалению, идиоты.
> правильное использование autotools вообще не предполагает их наличия и запуска на системе, где занимаются сборкойТеоретически. На деле же… Это не ты выше цитату приводил?
> /usr/ports/devel/libuv/Makefile:USES= autoreconf libtool pathfix pkgco
Ну то есть не соберётся оно на фряхе, если autoreconf не сделать. Видимо патчик какой-то накладывается, без которого никак, а с которым надо всё переделывать. И это не единичный пример, и для фряхи это не специфично — в линуксах тоже бывает сплошь и рядом. Так что всё равно, если занимаешься сборкой, приходится держать в системе кучу autoconf, automake и прочей автодряни разных версий (не ломать обратную совместимость они ведь не могут, в отличие от сабжа).
> этап конфигурации и сборки информации о системе совершенно намеренно отделен от этапа сборки информации о проекте.
Нет там никакого "этапа сборки информации о проекте", есть этап напихивания в исходники кучи скриптов, по размеру на порядки превосходящей размер среднего проекта.
> Теоретически. На деле же…ну так что вы хотите? Одни неумельцы тащат в "продукт" поделки других. Я ж говорю - что ни валяется на полу, все в рот.
> Видимо патчик какой-то накладывается,
да щясс... там вообще нет files/
USE_GITHUB= yes
типичная поделка, не имеющая понятия "релиз" (или там такой релиз, с которым ничего уже лет пять не соберешь).> Нет там никакого "этапа сборки информации о проекте",
Те самые .am скрипты, которые привязаны к исходникам (или во всяком случае должны бы быть) - это оно и есть. Независимо от того, умел автор этим пользоваться, или просто не умел писать makefile.
А сборка информации о системе - это когда (порожденные теми) уже configure скрипты старательно обрабатывают единственный параметр "with-systemd".
А что это решалось в пяток строк на sh или в один define для make - так они ни sh не умеют, ни make.
Остальные пять тыщ строк и сотня ненужнопроверок - побочный эффект от применения автоматики там, где она совсем не нужна.Авторы конкретной этой глупости зато, смотрю, умеют .bat (не-не-не, cmd ниасилен) - похоже, в винде оно собирается без autoconf. Правда сперва что-то там совершенно неведомое автовсасывает откуда-то с гугля, я бы вот, будь у меня винда, не рисковал бы ЭТО запускать.
> ну так что вы хотите? Одни неумельцы тащат в "продукт" поделки других. Я ж говорю - что ни валяется на полу, все в рот.Так я ж соглашаюсь: не надо эту бяку в рот. И в другие физиологические отверстия тоже не советую.
>> Нет там никакого "этапа сборки информации о проекте",
> Те самые .am скрипты, которые привязаны к исходникам (или во всяком случае должны бы быть) - это оно и есть.И где тут "сборка информации о проекте"? Собирать-то нечего, разрабы всё сами ручками в эти самые .am и прочие .ac прописали.
> И где тут "сборка информации о проекте"? Собирать-то нечего, разрабы всё сами ручками в эти
> самые .am и прочие .ac прописали.ну так это и есть способ рассказать automake, что тебе от него нужно.
а что из этого есть и где - найдет уже configure.в cmake просто эти этапы перемешали в кучу, а часть тестов заменили статическими конфигами. Разработчики, видимо, счастливы (особенно - те что неасилили и кэширование), те кому потом с их продуктом иметь дело - не очень. Угадайте, кого на свете больше (включая других разработчиков, вынужденных пользоваться тем что дали, чтобы не переизобретать весь мир с первого дня)
> в cmake просто эти этапы перемешали в кучуНичего там не перемешивали. Просто первый этап (генерацию новых и подкладывание готовых скриптов) выкинули за ненужностью.
> Разработчики, видимо, счастливы (особенно - те что неасилили и кэширование), те кому потом с их продуктом иметь дело - не очень. Угадайте, кого на свете больше
В мире бинарных дистрибутивов больше, конечно, разработчиков, поскольку майнтейнер обычно сопровождает большое число пакетов. А конечным пользователям по барабану. Да, кстати, как майнтейнер я к cmake имею лишь очень небольшие нарекания (прежде всего — отсутствие универсального способа задать путь для установки библиотек). С autotools проблем по крайней мере не меньше.
> слив засчитан.
> То есть факт звиздежаНеплохо у бздунов бомбануло. Аноним правда другой был, но сказанул все верно.
Факт в том, что кому шашечки, а кому и ехать. Шашечники гордо собирают все из сорцов, гордясь "прозрачностью" и "простотой", но рулить своей "юниксвейной" системой предпочитают почему-то из под пуссиэкзе.
А вторым нужно работать, а не маяться дурью, играя в билдферму. И они используют пакетник. Что характерно, из под линуха, где сделали именно так, как нужно для работы и решения повседневных задач, а не и повышения ЧСВ от использования "правильных" академподходов.
У пакетов есть как минимум одна проблема: они собраны с какими то опциями, и часто то не хватает то оно тянет лишних зависимостей.Держать билдферму вообще не проблема и не напряг, как минимум полезней чем майнить.
> У пакетов есть как минимум одна проблема: они собраны с какими то
> опциями, и часто то не хватает то оно тянет лишних зависимостей.
> Держать билдферму вообще не проблема и не напряг, как минимум полезней чеми проблема, и напряг - но когда тебе нужно что-то нестандартное или просто отсутствующее/не той версии - выбора у тебя нет.
а здесь мы видели поток сознания горе-программистов, которые всю жизнь лопали что дают, apt-get install, шлеп-шлеп
к сожалению, весь современный софт пишут такие же. m4 у них некруто, немодно, вот неделями зубрить совершенно бредовый синтаксис cmake (или, вероятнее, скопипастить со stackoverflow и не уметь поменять) - это они могут. Причем для чего-нибудь типа вышепроцитированного - снабдить систему сборки единственного .c единственным параметром (совершенно, кстати, ненужным)
> а здесь мы видели поток сознания горе-программистов, которые всю жизнь лопали что
> дают, apt-get install, шлеп-шлепТак ты уже собрал свой любимый проприетарный шланг c помощью шланга, питона, ниндзи и перла? Или оно "не считается"?
> Так ты уже собрал свой любимый проприетарный шланг c помощью шланга, питона,
> ниндзи и перла? Или оно "не считается"?ты будешь удивлен, но тот что в base system freebsd - собирается без шланга (ну, ок, последние четыре года с большим скрипом, но кое-как стартовать bootstrap можно и древним gcc), без питона, и без перла даже. Голый cmake и sh.
makefiles переписаны руками, ога (они еще и общесистемные параметры подхватывают - так, как это принято у системы, а не так как взбрело в голову "я вчера увидел новую билд-систему, щас мы на нее мигрируем"). Ничего, ну надо же, волшебного в этом нет.
Но вот оторвать ему сборку llvm под миллион абсолютно ненужных (~60% еще и неработающих) архитектур, занимающую часы и киловатты - этого, увы, никто пока не сумел. freebsd-update наше всьо.
а других компиляторов у нас нет. Либо уже сто лет пишущийся заведомыми вредителями gcc, либо этот.
В частности и потому, что вменяемых разработчиков уже почти не осталось, и на эти-то два не хватает.
> без питона, и без
> перла даже. Голый cmake и sh.
> Голый cmakeА голый cmake собираем (привожу ваш? же комментарий)
>>>>>>>>>/usr/ports/devel/cmake/Makefile:LIB_DEPENDS= libcurl.so:ftp/curl \
/usr/ports/devel/cmake/Makefile- libexpat.so:textproc/expat2 \
/usr/ports/devel/cmake/Makefile- libjsoncpp.so:devel/jsoncpp \
/usr/ports/devel/cmake/Makefile- libuv.so:devel/libuv \
/usr/ports/devel/cmake/Makefile- librhash.so:security/rhash
/usr/ports/devel/cmake/Makefile-
/usr/ports/devel/cmake/Makefile-USES= compiler:c++11-lang libarchive ncurses
--
/usr/ports/devel/cmake/Makefile:MANPAGES_BUILD_DEPENDS= sphinx-build:textproc/py
а самое приятное - вот это:
/usr/ports/devel/libuv/Makefile:USES= autoreconf libtool pathfix pkgco
>>>>>>>>приехали …
просто опечатка. Там make. Обычный такой bsd make.
> m4 у них некруто, немодно, вот неделями зубрить совершенно бредовый синтаксис cmakeСинтаксис cmake местами, может, и странноват, но зато предельно простой, если не сказать примитивный. Что там можно зубрить *неделями*? m4 намного сложнее, не говоря о том, что для правильного обращения с автокрэпом надо уметь ещё в shell и make (причём хорошо уметь, чтобы писать переносимо между разными реализациями).
> ещё в shell и make (причём хорошо уметь, чтобы писать переносимо
> между разными реализациями).на фоне необходимости уметь собственный код писать переносимо - это такая мелочь...
И да, количество USE_GMAKE неплохо кореллирует с autotools. И с кучей патчей чтобы оно хоть как-то собралось не на единственном доступном автору линуксе. Хорошо еще, если не безальтернативно gcc.
Зачем, спросите, они вообще при этом использовали automake? Ну правильно, потому что ни shell, ни make толком...m4 для его использования знать не надо, к сожалению. Да они и не знали.
> слив засчитан.Дорогой бздун, ты слился на незнании матчасти еще при копипасте частей мейк-файлов в качестве "демонстрации" зависимостей. Вместо make (pretty-print-)(build|run)-depends-list или make all-depends-list
Ну и заодно посмотри зависимости для сборки любимого шланга.
> в качестве "демонстрации" зависимостей. Вместо make (pretty-print-)(build|run)-depends-list
> или make all-depends-listя рад за вас, что вы выучили массу абсолютно ненужных заклинаний. Типикал юзер cmake.
> я рад за вас, что вы выучили массу абсолютно ненужных заклинаний. Типикал юзер cmake.Т.е. типикал бздun маны своей же билдсистемы в глаза не видел?
man ports
> all-depends-list Print a list of all dependencies for the port.
> pretty-print-run-depends-list, pretty-print-build-depends-list
> Print a list of all the compile and run
> dependencies, and dependencies of those
> dependencies, by port name and version.Яснопонятно.
> Т.е. типикал бздun маны своей же билдсистемы в глаза не видел?когда-то видел, запоминать всю эту километровую муру - это для вас, мальчики с феноменальной памятью (вероятно, кому-то так проще, или, что скорее, кто-то зачем-то это использует в скриптах).
мне гораздо проще и быстрее посмотреть в Makefile, что там на самом деле, а не что выдаст интуитивно-приятный скрипт
(к тому же эти заклинания имеют особенности, о которых вы не в курсе, поскольку читатели манов, а не админы фри)
> https://packages.debian.org/ru/source/sid/cmake
> adep: python3-sphinx
> adep: qtbase5-devАга, ещё лучше.
> я лучше на autotools останусь, они хотя бы циклических зависимостей не содержат. m4 и перл собираются без автотула, m4 и перла.Обломайся, ему всё равно нужен make. А чем собирается make?
> В том числе потому, что авторы немножко думали головой, а не тащили в рот все что с полу поднято.
Вот тут полностью согласен. Советую всем так и поступать (не тащить в рот автокрэп).
> ему всё равно нужен makeАх да, извини. gmake, конечно же.
> Обломайся, ему всё равно нужен make. А чем собирается make?gmake еще oldschool - там не было принято старательно _удалять_ из дистрибутивного архива готовый configure.
> Вот тут полностью согласен. Советую всем так и поступать (не тащить в
> рот автокрэп).я знаю целую одну достаточно сложную программу, у которой autoconf используется по делу (и в ридми которой _явно_ сказано - не будите лихо, все .am/.ac - для _девелоперов_, причем только тех, которым понадобилось что-то менять в системе сборки, а не просто поправить строчку в исходнике - например, портируя на новую платформу).
Как ни странно, это php. Который действительно собирается и работает на куче совершенно разных систем и в миллионе разных конфигураций. Но, разумеется, за счет наличия кода для них, а не автомагически пыщь-само-чудом-сгенерилось.
> gmake еще oldschool - там не было принято старательно _удалять_ из дистрибутивного архива готовый configureШта? Это где это так стало принято? Не, я понимаю, что хипстота автокрэпом пользоваться не умеет, но она как правило и не пытается. Так кто удалил? Пруф в виде ссылки на архив, пожалуйста (не сгенерированный git archive на каком-нибудь гитхабе, а именно нормальный релиз).
> Шта? Это где это так стало принято? Не, я понимаю, что хипстотада везде. Старательно добавят в .gitignore (как будто он у них меняется!) и будут расходовать гигаватты по всему миру каждый раз, как надо приложить тривиальный патч из одного символа, на перегенерацию совершенно ненужного кода (для, к тому же, совершенно, как правило, ненужных и бесполезных проверок - оно все равно работает только в одной-единственной конфигурации, той что была у разработчика)
> Так кто удалил? Пруф в виде ссылки на архив, пожалуйста (не
> сгенерированный git archive на каком-нибудь гитхабе, а именно нормальный релиз).а, так релизы ж тоже немодно и несовременно. У нас тут continuous development, вы чего!
(к тому же, даже если из него выгрузят "релиз", вы думаете, они вспомнят про configure? )
> да вездеТо есть пруфа не будет.
> Старательно добавят в .gitignore (как будто он у них меняется!)
В .gitignore его добавляют совершенно правильно. В гите от него толку нет, потому что всё равно при чекауте даты модификации файлов сбиваются, и make может решить перегенерить configure и прочее автокрэповое хозяйство, даже если оно уже есть.
> В .gitignore его добавляют совершенно правильно.* Да-да, даже в "олдскульном" gmake: https://git.savannah.gnu.org/cgit/make.git/tree/.gitignore#n23
> Как ни странно, это php. Который действительно собирается и работает на куче
> совершенно разных систем и в миллионе разных конфигураций.Это тот, который под винду только msvc можно собрать? Кул стори.
> /usr/ports/devel/libuv/Makefile:USES= autoreconf libtool pathfix pkgcoМожет быть это проблема порта и должно быть BUILD_DEPENDS?
Оно и подразумевает что при билде только используется.
Автотулс остой полный, как по мне.
Нужно обязательно 100500 файлов насоздавать чтобы удовлетворить сборочную систему.
С CMake достаточно один файл для простого проекта.Что до зависимостей - так надо ещё посмотреть, может автор порта просто не заморачивался и зафигачил по максимуму.
> Что до зависимостей - так надо ещё посмотреть, может автор порта просто
> не заморачивался и зафигачил по максимуму.Если пытаться что-то из этого выпилить - оно у тебя может и получится, только рано или поздно какой-то проект не соберется кастрированным cmake - если есть кнопка, она ж должна быть нажата!
и да, модули - отдельная песня, это все - только голый cmake
Где вы это нашли? В архиве (cmake-3.11.0.tar.gz) нет ни одного makefile'а. Во время сборки bootstrap - таки да, генерируя makefile, для сборки используется make, но никаких autoconf/autotools. Также не понятно про "самое приятное" - исходники libuv (в этом же архиве) тоже компилятся make'ом (без всяких autoreconf и т.п.)
> т.е автоконф (вместе со всем хламом в виде перла и m4) тоже
> никуда не делся, "мы не выкинули пончики, они с нами летят",
> он вам понадобится чтобы собрать архинужную и полезную (кто знает, этот
> кусок г-на вообще зачем?) деталь для самого cmake.Ага, gettext, который тянет libxml, который тянет питон.
> Ага, gettext, который тянет libxml, который тянет питон.Но его можно отключить, если собирать rhash без поддержки иностранных языков.
> Ага, gettext, который тянет libxml, который тянет питон.dependency hell сам по себе - это отдельная болячка, хоть и менее чудовищная чем в типикал линуксе (исключая гентуклоны, но у тех своих бед хватает).
Отчасти устраняемая OPTIONS_UNSET=NLS (и еще двумя десятками UNSET ненужного), в целом - непобедимая, потому что весь нынешний софт так написан.а так-то у нас и gmake норовит собираться с NLS. Где вылупляются подобные "разработчики", которым оно нужно - не знаю, и не хочу узнать.
Отличная система сборки, имеет хорошую поддержку в QtCreator и других IDE (говорят, даже VSCode). Крупные проекты уже оценили; не понимаю тех, кто не хочет переходить с autotools или тех, кто предпочитает голый Makefile.
>Число процессов определяется через переменную CMAKE_AUTOGEN_PARALLELчерез make -jN сделать не судьба видимо.
AUTOGEN и AUTOMOC работают там, где нет make.
> AUTOGEN и AUTOMOC работают там, где нет make.в винде, да?