Как добавить зависимости QT в cmake при сборке, если они отсутсвуют на хосте?

Никак не надо добавлять. CMake сам выдаст достаточно понятное сообщение об отсутствии необходимой зависимости (Qt в данном случае), а собирающий, прочитав это сообщение, установит ее так, как ему нужно.

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

Ясно, спасибо.

При чем тут QuickTime?

Я про фреймворк https://www.qt.io/

Фреймворк называется Qt

у boost на гите есть репы отдельных модулей вроде program_options и filesystem, которые вроде можно собрать как .lib под винду

Нельзя. Точнее, можно, но «репы отдельных модулей» здесь ничем не помогут.

с qtbase так по идее не получится

Ты хочешь собирать только необходимую тебе часть? Это плохой вариант, по крайней мере в случае с тем же бустом. Собирай целиком.

Или у пользователя в любом случае должен быть QT?

Нет, твой подход верный.

Нет, твой подход верный.

Человек выше написал, что скачивать и устанавливать такие зависимости автоматически не очень хорошо, как же в итоге правильно поступить? Или я чего то не понимаю…

Человек выше написал, что скачивать и устанавливать

Именно про скачивать и устанавливать я согласен - не надо так делать. Положи зависимость в гит(подмодулем, допустим - это не важно) и собирай, когда зависимости нет на хосте(или версия неподходящая). Устанавливать только вместе с проектом, а не при сборке. Если проще:

$ cd <BUILD-TREE> && cmake <SRC-TREE> && cmake --build .
$ cmake --build . -- install  # Вот здесь должна быть установка зависимости, если она не нашлась и была собрана. Не раньше.

А где гарантия, что он не соберет с одной версией, а установит потом другую? Не проще ли отказаться собирать, пока зависимости не будут удовлетворены?

А где гарантия, что он не соберет с одной версией, а установит потом другую?

В смысле? Собирается только одна версия и ставится она же. Какую другую и откуда оно возьмётся?

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

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

какой-то поток сознания, почитай документацию.

В смысле? Собирается только одна версия и ставится она же. Какую другую и откуда оно возьмётся?

Так если он зависимость подключил через подмодуль гита:

Положи зависимость в гит(подмодулем, допустим - это не важно)

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

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

И для пользователя проще, кмк. Пусть ставит себе зависимость как ему удобно

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

Тогда оно должно взять либу с хоста. А если версия не подходит или ещё что-то - собирать свою и ставить её же. Если твой вопрос про «нафига две версии» - проблемы тоже нет. Если сумеешь подобрать версию либы, которая сможет использоваться везде - поставь её и будет только она. Если не сможешь такую версию подобрать - то опять две ставишь. Разницы никакой.

Пусть ставит себе зависимость как ему удобно

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

Тогда оно должно взять либу с хоста.

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

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

Согласен, поэтому автор должен просто предоставить список зависимостей. Все. Он же в любом случае не сможет предусмотреть все варианты сборки. Мейнтейнеры пакетов в дистрибутивах именно эту проблему и решают. Т.е. это сама по себе достаточно большая проблема - сборка кода под конкретный дистрибутив.

Так а я про что

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

Если на хосте нет нужной зависимости, то эту проблему должен решать пользователь, а не автор.

Бессмысленное занятие.

Он же в любом случае не сможет предусмотреть все варианты сборки

По зависимостям - вполне сможет.

Ну и проблему ты так и не назвал. «соберет с одной версией, а установит потом другую» - невозможно. «будет стоять две версии либы» - пусть стоит(если совсем припёрло - можно вручную поставить единственную, удовлетворяющую всех).

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

Я имел в виду, что cmake еще на этапе конфигурирования сообщает об этом, до сборки еще и не дошло.

Если на хосте нет нужной зависимости, то эту проблему должен решать пользователь, а не автор.

Бессмысленное занятие.

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

По зависимостям - вполне сможет.

Не всегда. Он написал библиотеку два года назад. Она решает нужные ему задачи в нужном ему объеме. Он может туда больше ничего не коммитить. Однако зависимости, используемые в ней, могут продолжать активно развиваться и их версии обновляются против воли автора библиотеки и без его ведома. Как он может их предусмотреть? Все их возможные варианты заранее? С этим зоопарком зависимостей на момент сборки иметь дело придется тому, кто собирает свежую версию.

Ну и проблему ты так и не назвал. «соберет с одной версией, а установит потом другую» - невозможно.

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

какой-то поток сознания, почитай документацию.

Так можно на любой вопрос ответить, даже про смысл жизни)

Покажи документацию на жизнь.

Я имел в виду, что cmake еще на этапе конфигурирования сообщает об этом, до сборки еще и не дошло.

Ну да, я верно понял. Конфигурация часть сборки. Не важно.

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

Ну с этим натурально в школу. А ещё на другой машине оказалась другая архитектура и SIGILL сразу же при запуске. Даже не смешно.

Под пользователем я понимаю другого программиста, который либу собирает. Я не имею в виду пользователя, который просто нажимает кнопки.

Однако зависимости, используемые в ней, могут продолжать активно развиваться и их версии обновляются против воли автора библиотеки и без его ведома

2в1: что из этого следует и к чему это вообще написано?

Проблема то в чем. Есть прилажуха с зависимостями написанная под линуксом, нужно что бы она могла собраться и под unix и под win. Желательно без поиска зависимостей, ну изначально так хотелось по крайней мере, поддерживать ее долго не нужно и о совместимости зависимостей через пол года мне не нужно задумываться, т.к. эта проблема будет не актуальна в следствии не надобности самого приложения. Но как нужно поступать в обычных случаях то же интересно. Хотелось бы узнать куда копать, что бы например какие нибудь гугл тесты можно было бы собрать одновременно и под никс и под винду. Например под linux у меня все прикрасно ставится таким образом: https://pastebin.com/1UvBhaep

Я хотел сказать, что наличие документации не исключает возможных вопросов. По вашей логике многих аналогичных ресурсов не должно существовать, если есть документация:)

Но как нужно поступать в обычных случаях то же интересно.

Я писал выше об этом.

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

Одновременно - за один билд? Собери две версии.

Эк вы без cargo мучаетесь.

Ну с этим натурально в школу.

Да погоди ты из себя взрослого строить. Тут как раз наоборот получается. Ты все время только на локалхосте что ли работаешь? Или ты все свои проекты собираешь на машине пользователя? Каждого пользователя?

2в1: что из этого следует и к чему это вообще написано?

Из этого следует что все зависимости в проекте должны удовлетворятся пакетным менеджером дистрибутива. Тащить зависимость в виде git submodule можно только когда человек точно понимает, что он делает. И уж Qt тащить в виде git submodule не стоит 100%. Никогда.

Одновременно - за один билд? Собери две версии.

Имел ввиду, в зависимости от ОС хоста, две одновременно собранных версии не нужны)

Да погоди ты из себя взрослого строить. Тут как раз наоборот получается. Ты все время только на локалхосте что ли работаешь?

Так, пошла откровенная клоунада. Впрочем, такое всегда чем-то подобным кончается. Ну там, локалхост, кивки в сторону дяди и подобное. Слишком дёшево.

Или ты все свои проекты собираешь на машине пользователя? Каждого пользователя?

Кстати, я сразу не разглядел:

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

С вручную установленными зависимостями оно так же поломается, как и с автоматически собранными. Даже здесь ты обгадился.

Из этого следует что все зависимости в проекте должны удовлетворятся пакетным менеджером дистрибутива

Нет, слова меня не интересуют. Ты должен обосновать следование, а не просто написать любую чепуху и потом заявить «из этого следует». Из чепухи ничего следовать не может.

В целом, ваяешь хэлворд, демонстрируешь названные тобой проблемы и показываешь, как ручная установка зависимостей эти проблемы решает. Ты же сможешь, так?

Ну тут особых телодвижений не нужно, многое cmake сам делает. Что не делает - делаешь руками под if-ами. Ты там выше выкладывал код, я там видел if(UNIX) - ну вот в таком же духе.

Так, пошла откровенная клоунада.

Клоунады нет никакой с моей стороны. Ты же меня попытался в школьники записать.

С вручную установленными зависимостями оно так же поломается, как и с автоматически собранными. Даже здесь ты обгадился.

Ой, все, сливаешься потихоньку. Если сборка велась с зависимостями, установленными пакетным менеджером дистрибутива, то после развертывания бинарников на целевой машине все будет работать из коробки. Это же очевидный факт.

Нет, слова меня не интересуют. Ты должен обосновать следование, а не просто написать любую чепуху и потом заявить «из этого следует». Из чепухи ничего следовать не может.

Да я то в начале подумал, что ты просто хочешь совет дать человеку. А сейчас вижу что тебе главное доказать кому-то (очевидно всем?) что ты прав.

В целом, ваяешь хэлворд, демонстрируешь названные тобой проблемы и показываешь, как ручная установка зависимостей эти проблемы решает. Ты же сможешь, так?

Ты на дешевое «слабо» школьников своих бери. Я озвучил хорошо известные моменты. А ты продолжай советовать топикстартеру добавлять Qt как git submodule. Надеюсь он тебя проигнорирует.

Зачем что-то спрашивать если в доке все написано, не нравится дока у тебя есть гугл, в нем тоже все написано. Ты же не первопроходец. Ресурсы должны существовать, но не для того чтобы в 100 раз спрашивать вещи про которые уже давно все написано. Ты хотя бы что ли привел сборочный конфиг с попытками что-то сделать, а ты прогнал пургу со своими как будто бы дельными замечаниями, и теперь клянчишь готовое решение твоей «проблемы», да на кой хер кому-то тратить на тебя свое время. Буквально недавно задавался таким же вопросом просто потому что cmake я использую раз в пятилетку по большой нужде, и никаких проблем у меня не возникло чтобы найти решение, ты же не хочешь сказать что ты тупее меня?

Зачем что-то спрашивать если в доке все написано

не нравится дока у тебя есть гугл, в нем тоже все написано

Ты хотя бы что ли привел сборочный конфиг с попытками что-то сделать

В доках видел описание конструкций вроде «if(target_os)», гугл не смогу найти мне примером скачивания зависимости с гита и ее последующей установке под винду, выше есть мой код, который в теории должен собрать конкретно GTest под определенную систему, но работает он только под unix. Если бы мне удалось что то существенное найти в документации или гугле я бы не задавал здесь вопрос, т.к. это банально занимает больше времени, что моего, что остальных. Я думаю это очевидно. Если я где то пропустил аналогичный вопрос, хотя бы на этом ресурсе, то укажите, пожалуйста.

Ты же меня попытался в школьники записать.

Чьи-то обиды меня мало интересуют. Приводишь аргументы уровня школы => записываешься в школьники. Это не новость.

Ой, все, сливаешься потихоньку.

Кулстори.

Если сборка велась с зависимостями, установленными пакетным менеджером дистрибутива, то после развертывания бинарников на целевой машине все будет работать из коробки. Это же очевидный факт.

И что же помешает всему «работать из коробки» если зависимость собрана вручную? Срочно за парту.

Да я то в начале подумал, что ты просто хочешь совет дать человеку. А сейчас вижу что тебе главное доказать кому-то (очевидно всем?) что ты прав.

Кулстори номердва.

Ты на дешевое «слабо» школьников своих бери. Я озвучил хорошо известные моменты.

Во-первых, ты и есть школьник. Во-вторых, ты озвучил свои фантазии. В-третьих, опять ничего конкретного не показал.

А ты продолжай советовать топикстартеру добавлять Qt как git submodule. Надеюсь он тебя проигнорирует.

Совсем поломался. Странно, что у тебя не пятьзвёзд.

и теперь клянчишь готовое решение твоей «проблемы»

Я не припомню, что бы просил такого), ссылки или описания «своими словами» мне вполне подходит, дальше будет понятно в каком направлении копать.

Как я понял под Винду ещё нужно вручную пути указывать? Т.к. cmake сам либы найти не смог после скачивания и установки

А ты продолжай советовать топикстартеру добавлять Qt как git submodule. Надеюсь он тебя проигнорирует.

Совсем поломался. Странно, что у тебя не пятьзвёзд.

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

Говори прямо, тянуть Qt как субмодуль в репу или нет.

А то виляешь тут. Только это, без балабольства, что ты никому не должен. Если не должен, то можешь быть свободен, пёсик.

Не тяни в проект никакие зависимости, тем более такого монстра, как Qt.

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

Для полного юзера - бинарные сборки, сделанные тобой.

Понятно, спасибо