modern cmake

Типа target_include_directories Vs include_directories

А в чём проблема? include_directories использую для инклюдов, используемых во всём проекте, target_* — только специфичных для цели

https://crascit.com/professional-cmake/

Когда-то зафиксировал для себя ряд ссылок, может и вам что-то из этого поможет: https://eao197.blogspot.com/2017/11/prog-cmake.html

Толку от этой толпы даташитов и мануалов?

Вот сниппеты — совсем другое дело! Они бы очень помогли в данном случае. Я бы и сам с удовольствием почитал сниппеты на современном cmake, а то у меня так и не получилось по-человечески разрулить проблемы с xgettext (чтобы mo-файлы собирались только в debug-режиме, а в release лишь устанавливались; и чтобы была возможность добавить еще какой-нибудь язык).

Смортя относительно чего modern. Transitive usage requirements даже сейчас не везде есть(2.8 вроде не поддерживает)

Какой 2.8, когда сейчас cmake не ниже 3.13 везде?

Если для тебя понятие «везде» ограничивается локалхостами - то да

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

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

Если бы это было всегда возможно. Я вот тоже ограничен v2.8

главное правило современного cmake - предпочитать устанавливать свойства для целей (target_*). Для директорий - только в случае явной необходимости.

А что для тебя понятие «везде»? Допотопные компы со вторым кернелом?

Если админ не обновляет линукс на борту компа, то зачем такой админ нужен? Сейчас самое древнее ведро, которое может стоять на компах - 4.4. А самый древний cmake — 3.9!!!

Если ты найдешь где-то более древние, дергай админов.

Я вот тоже ограничен v2.8

Это как?

Не использовать системный симейк. Например.

Дать одмину в бубен?

Будь реалистом - centos всё ещё с нами. Кстати, на debian stable «всего» 3.7. Про арч и прочие роллинг-релизы в продакшене только не надо, это если и встречается, не является широко распространённой практикой

А этот ужас в самом деле широко используется?

centos всё ещё с нами.

и это отлично.

cmake.x86_64        2.8.12.2-4.el6      base
cmake3.x86_64       3.6.1-3.el6         epel

Им уже с версии 3.1 что ли можно более-менее пользоваться. По сути, target_link_libraries, другие target_*, экспорт, импорт - почти все там уже есть.

К сожалению, да. Хоть какая-то интеграция из коробки: тут тебе и ninja, и cotire, хошь под eclipse или codeblocks проект, хошь compile_commands.json, cmake-server. ctest отлично интегрируется с gtest, позволяя из коробки параллельное выполнение тестов с таймаутами, а так же генерит всякие junit.xml отчеты. А с другой стороны, это виндовая сборка, включая возможность делать всякие cmake -E sha256sum и tar без головняка «а где взять это на винде»

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

epel

Это понятно. Так-то и собрать не проблема. Но не все хотят это тянуть(о причинах ничего не могу сказать)

Но не все хотят это тянуть

Ну это же миф. Не углубляясь в философию и оставаясь в теме: что мешает всё собрать в каком-нибудь докере, а поставить только rpm ки? Ведь cmake их даже делает при некотром старании: https://cmake.org/cmake/help/latest/module/CPackRPM.html

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

А на сборочнице можно ставить чего угодно

«Да, но лучше не надо» (c)

всмысле, не надо? ну откажитесь тогда от этого специального софта, который им (вам?) не хочется собирать по идеологическим (идиотическим) соображениям. Проще выпить водки и лечь спать, я понимаю :)

А meson не взлетает?

Кстати, о генерации rpm: в 3.7 с этим жесть та ещё - то ли он список файлов фильтрует таким образом, то ли ещё что-то. Но! Он использует полный путь до build tree как регулярку(про экранирование, ясное дело, не слышали). Хорошо, что у меня ++ в пути было и всё сразу отвалилось

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

Вот и отказались же в пользу 2.8 )

Баги... Меня эта генерация rpm не особо вдохновила - писанины много, обощения мало, лишний слой считай. Мне нравится import\export, транзитивные зависимости, ctest. А, ну и то, что ninja под виндой можно завести на сборочнице. Короче, то что я выше перечислил :)

cmake 2.8 остался, разве что на CentOS, но и туда, скорее всего, можно бинарную версию с cmake.org скачать и распаковать куда-нибудь для работы. Так что если тебе нужен свежий cmake, то ты его не только на localhost легко сможешь установить, но на какой-нибудь travis-ci. Так что использовать старый cmake великого смысла нет.

Если бы это было всегда возможно. Я вот тоже ограничен v2.8

Странно, на отсутствие компилятора D в production тебе насрать, ведь на localhost их аж 3 штуки. Почему же в версии cmake ты ограничен? Наверняка на localhost совсем не 2.8 установлена. Дядя начальник не позволяет решения на таком уровне принимать?

Если админ не обновляет линукс на борту компа, то зачем такой админ нужен? Сейчас самое древнее ведро, которое может стоять на компах - 4.4. А самый древний cmake — 3.9!!!

Если ты найдешь где-то более древние, дергай админов.

Классическая сказка от студента-арчевода админа localhost. Все сколько-нибудь серьезное (по нагрузке и по деньгам) на RedHat/CentOS работает. Но тебе этого не понять, похоже.

Впрочем, cmake на RedHat новый вполне можно поставить, а вот с ядром все сложнее.

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

Там правда есть что рассказывать. Я не видел ни одного проекта, в котором CMake используется правильно (даже в пределах заявленных ограничений по фичам для обратной совместимости — куча проектов до сих пор имеют cmake_minimum_required(VERSION 2.8), хотя все актуальные LTS-дистрибутивы на данный момент имеют как минимум 3.3).

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

Больше чем широко и альтернатив адекватных не видно.

К сожалению — да.

Из альтернатив разве что meson и waf.

Если бы это было всегда возможно. Я вот тоже ограничен v2.8

0) Скачиваешь portable по мере выхода с https://cmake.org/files.
1) Пользуешься какой хочешь версией.
2) Дистрибутивный cmake для сборки пакетов самого дистрибутива.
3) Никакого ограничения не существует.

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

Лучше чем этот чел написал справишься?

Вопрос возник. Если продуктом является открытый SDK, в нем применяется распоследний cmake. Подразумевается, что юзеры используют его через target_link_libraries(). Для меня это значит, что юзеры должны использовать распоследний cmake. Что с этим можно поделать, что бы позволить юзеру использовать другую заведомо несовместимую версию? Накручивать FindXXX.cmake у себя?

ЯННП, кто на ком стоял и почему юзеры не могут сделать так же. Это всё равно ничтожно по сложности по сравнению с тем чтобы подтянуть, например, компилятор и библиотеку 17-ки или 20-ки, которые нужны для этого гипотетического SDK.

ЯННП

сомневаюсь :)

В том, что ты сказал, есть резон да, поэтому, сейчас именно так и рекомендуется сделать (я имею ввиду один конкретный sdk, не важно какой). Я так примерно и рассуждал. Теперь еще раз подтвердил свою позицию.

Просто очередная полемика с пользователями была, которые именно что хотят использовать свой штатный cmake. Хотя, как ты прозорливо заметил, с SDK идет компилятор, ага, и дополнительный стафф не дает значимого оверхеда

Просто очередная полемика с пользователями была, которые именно что хотят использовать свой штатный cmake.

В тривиальных библиотеках требование cmake можно искусственно понизить. Правда это лишняя работа, которую надо делать постоянно, потому что инструмента, который бы позволял автоматически установить какой cmake требуется, я не нашёл. Только скачивать все версии c cmake.org/files и понижать до тех пор, пока не перестанет собираться. А в нетривиальных библиотеках искусственное понижение требования cmake пользователям несильно поможет, да.

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

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

Ну сопровождаешь ты старый продукт для которого стоит в ТЗ требование на, например, Debian Wheezy. Никто не будет ничего менять. Будет еще 10 лет жить этот продукт и ты будешь собирать cmake 2.8, потому что заказчик так требует - ты ему должен передать код, он сам его будет собирать под целевую платформу, указанную в ТЗ. Кому-то из заказчиков без разницы на дистр, а кто-то заморачивается по своим причинам.

Еще год назад приходилось писать с оглядкой на древний gcc, просто потому что железяка где все должно было крутиться не поддерживала более новый софт. Жизнь намного сложнее чем просто обновиться с инета.

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

Элементарно, ты кидаешь в докер с centos6 всё, что тебе надо для сборки - cmake, тулчейн, либы - любых версий. Собираешь бинарник, который будет запускать на любой системе LSB начиная эдак с 2010 года. Всё. Юзер элементрано это может воспроизвести.

Ради чего пердолиться с устаревшими инструментами? Это идеология такая, что ли?

Ради чего пердолиться с устаревшими инструментами? Это идеология такая, что ли?

Если вкратце, то это обычный энтерпрайз. Так всегда было, есть и будет.

это обычный энтерпрайз.

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

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

Согласен, оффтоп, но я отвечал на утверждение о том, что не может быть, чтобы кто-то сейчас использовал cmake с версией < 3.0