Состоялся (https://blog.kitware.com/cmake-3-14-0-available-for-download/) релиз кроссплатформенного открытого генератора сценариев сборки CMake 3.14 (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.13/release/3.14.html):
- Добавлена поддержка кросс-компиляции для iOS, tvOS и watchOS с использованием простых файлов toolchain (https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7....);
- Добавлен экспериментальный генератор сборочных сценариев для Visual Studio 16 2019 (протестирован в Visual Studio 2019 Preview 4). Новый генератор сильно отличается от генераторов для других версий Visual Studio и не поддерживает указание целевой платформы в имени генератора (платформа передаётся только через переменную окружения CMAKE_GENERATOR_PLATFORM). Целевая платформа по умолчанию выбирается на основании платформы текущего окружения (хост-платформы);- В генератор "Green Hills MULTI" добавлена поддержка библиотек объектных файлов (Object Library), возможность переименования целевых платформ и изменения свойств вывода;
- Добавлены переменные "CMAKE_BUILD_RPATH_USE_ORIGIN" и "BUILD_RPATH_USE_ORIGIN", позволяющие использовать относительные пути для runtime (RPATH), что полезно для организации повторяемых сборок;
- В команду "install(TARGETS)" добавлена возможность определения каталогов для установки по умолчанию в зависимости от типа целевых платформ, без использования переменной DESTINATION. В команды "install(FILES)" и "install(DIRECTORY)" добавлены новые параметры для установки в привязке к типу файлов. Данные о каталогах основываются на переменных, выставляемых модулем GNUInstallDirs, и встроенных значений по молчанию;
- В команды "install(CODE)" и "install(SCRIPT)" добавлена поддержка выражений генератора;
- В команду "if()" добавлена возможность проверки переменных из кэша, определённых при помощи выражения "DEFINED CACHE{VAR}";- В сборочный режим "cmake --build" добавлена поддержка опций "--verbose" и
"-v". В команду "cmake -E compare_files" добавлена опция "--ignore-eol" для игнорирования маркеров конца строки (LF или CRLF) при сравнении;
- Прекращена поддержка запуска CMake в Windows XP и Windows Vista, для работы на платформе Windows теперь требуется как минимум Windows 7.URL: https://blog.kitware.com/cmake-3-14-0-available-for-download/
Новость: https://www.opennet.me/opennews/art.shtml?num=50327
> Прекращена поддержка запуска CMake в Windows XP и Windows Vista, для работы на платформе Windows теперь требуется как минимум Windows 7Печально, конечно. Я устал бегать с ОС на ОС и давно хочу стабильности. Один вечный Windows на все времена
Главное чтобы бинарные сборки под Linux продолжали собирать в Debian 6. Раньше собирали в каком-то старом CentOS, но начиная с CMake 3.0 обновили билд-ферму до Debian 6. В мейл-листах мне сказали, что это было сделано, чтобы все необходимые вызовы Glibc были доступны. Хотя из исходников CMake 3.x продолжает компилироваться и в CentOS 5 с Glibc 2.4
Ну так и пользуйтесь одной вечной windows xp и старым ПО, проблема-то в чём?
> Ну так и пользуйтесь одной вечной windows xp и старым ПО, проблема-то в чём?GitHub требует браузер обновить. А на XP крайний: 5Х.0.1.
Ради такой благородной цели можно и руками собрать свежачок.
Просто ИТ-потреблятели не принимают прописанные им лекарства. Вместо этого употребляют Яблочное смузи.
а он не собирается - версия cmake манки-кодерами вбивается в requirements- разумеется, самая распоследняя, которую только эта обезьянка сумела у себя завести, хотя никакими новыми фичами ни разу не пользовалась (а если и пользовалась, то нахрен они не нужны), а еще там и пихон какой-нибудь будет гвоздями прибит.Исправить - уже немного не самая тривиальная задача для обыкновенного пользователя, пусть даже и осилившего сборку.
>Один вечный Windows на все временаСтавьте 10-ку.
> 3.14В день числа Пи зарелизили, однако
И правильно, ведь это 3.141ц.
14.03 вы хотели сказать.
14.88
Линковку в режиме whole archive когда сделают? Джва года жду.
Можно аргументы линкеру совать прямо в списке библиотек, так работает. Но выглядит криво, конечно.
Прочитал https://stackoverflow.com/questions/805555/ld-linker-questio... и так и не понял зачем оно может быть кому-то нужно в реальной жизни. Автор вопроса тоже, очевидно, как и авторы CMake.
Чтобы статическую либу не разбирало на отдельные объектники, которые друг без друга не работают (гугли С++ статическая регистрация). Сейчас приходится дополнительный линк-враппер делать - add_library(INTERFACE), делать ей set_property(INTERFACE_LINK_OPTIONS) с ключами для каждого ликонвищика и прописывать зависимость между линк-враппером и либой. Но зачем мне этим всем заниматься, если это всё может cmake нагенерировать? Тем более что про существование whole archive он уже явно в курсе.
> В команду "install(TARGETS)" добавлена возможность определения каталогов для установки по умолчаниюШикарно.
> В сборочный режим "cmake --build" добавлена поддержка опций "--verbose" и "-v"
И это.
Что быстрее и удобнее использовать при сборке больших проектов: autotools, cmake или meson?
cargo
А туда таки сделали возможность выполнить что-то в post-build или post-install?
scons. не благодарите.
Скунс - это если совсем некуда торопиться. Карго (и вообще ржавчина) - туда же.
а скажите, этот scons умеет с разными кросс- тулчейнами в подпроектах работать? На самом деле cmake гадость та еще, но и без него никак, проекты должны собираться для пары контроллеров + хост, 2-3 архитекруры за раз с общими зависимостями
Голый make?
На каждой системе ручками прописывать пути к библиотекам? Спасибо.
Лучше пусть это делает maintainer, когда создаёт cmake-привязки.
Пути к библиотекам можно получить и на голом make:
CPPFLAGS += $(shell pkg-config --cflags-only-I $(SUPERDUPERLIB))
CFLAGS += $(shell pkg-config --cflags-only-other $(SUPERDUPERLIB))
LDFLAGS += $(shell pkg-config --libs $(SUPERDUPERLIB))
Хотя это, конечно, всё равно куда менее переносимо и, кажется, GNU make only.
meson+ninjaгляньте на опыт gnome/mesa, они сразу дропнули autotools как meson заработал (ибо небо и земля)
Точно не autotools. Мой выбор — cmake, но на meson просто не хочу смотреть из-за зависимости от питона.
>Прекращена поддержка запуска CMake в Windows XP и Windows Vista, для работы на платформе Windows теперь требуется как минимум Windows 7.CMake - одна из худших систем сборки. Баг-трекер и пулл-реквесты требуют отдельной регистрации на сайте kitware, а регистрация - за рекапчей, что есть сообщение "шли бы вы отсюда, срaть мы хотели на ваши баг репорты и пулл-реквесты, мы систему исключительно для себя пилим".
В чем твоя проблема? Ты хотел без рекапчи тонну ботов регистрировать или авторизовываться через зонды?
Я ткого не утверждал. Вы зачем дешевую демагогию применяете?
Так в чем претензия то?
Вообще-то там есть вход с гугловским или гитхабовским аккаунтом, но ты ведь всё равно найдёшь причину ничего не репортить.
Есть. С обязательным предоставлением доступа к почте в ГХ-аккаунте. А не проследовать ли им на йух с такими запросами?
Я же говорил: повод не репортить всегда найдётся, было бы нежелание.
Если это используется в RectalOS, врядли это показатель чего-то хорошего.