LINUX.ORG.RU

Типа target_include_directories Vs include_directories

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

XMs ★★★★★ ()

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

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

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

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

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

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

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

yetanother ()

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

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

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

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

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

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

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

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

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_*, экспорт, импорт - почти все там уже есть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

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

ЯННП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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