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

https://stackoverflow.com/questions/14639459/how-to-change-qmake-prefix-location

Видел, пока не понял

проблема опакетить приложение, не сейчас не об этом.

checkinstall

Я зарёкся ставить с помощью sudo make install, и теперь делаю что бы оно ставилось в $HOME/.local, обычно то что ставится таким образом на компе нужно только мне, а удалять в случае чего в разы проще, не травмирует систему

checkinstall

Нужно заставить qmake указывать нужный мне путь установки программы.

Собирать лучше всего в chroot, чтобы система была чистой без кучи девелоперских зависимостей. Пакет делать либо через checkinstall, либо вообще AppImage сделать. Либо FlatPak.

Если ты разраб, выкинь это гуано, не поленись, изучи cmake, избежишь кучи проблем

Что qmake, что cmake – ягоды одного поля – наспех спроектированные кривые сборочные системы, на которые зачем-то все подсели. А когда спроектировали более адекватные инструменты: qbs, Meson было уже поздно, ибо ниша занята вот этими корявыми qmake, cmake, autotools.

Праграмма librecad, и по их инструкциям зачем то нужен qmake -r.

Если что, то вот как они собирают AppImage:

https://github.com/LibreCAD/LibreCAD/blob/master/CI/build-appimg.sh

И вот как они собирают под Ubuntu 20.04 LTS:

https://github.com/LibreCAD/LibreCAD/blob/f55f341e69b70c2c8ceaf73ad594261406507349/.github/workflows/build-all.yml#L37-L40

${ANALYZE}qmake -r librecad.pro CONFIG+=debug_and_release PREFIX=/usr BOOST_DIR=${{ github.workspace }}/boost/boost

Правда, непонятно, зачем там PREFIX=/usr, который нигде не используется, а установка по make install, судя по https://github.com/LibreCAD/LibreCAD/blob/master/settings.pri идёт в INSTALLDIR = ../../unix.

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

Если что, в Arch Linux его собирают вот так:

https://github.com/archlinux/svntogit-community/blob/packages/librecad/trunk/PKGBUILD

А в Ubuntu/Debian вот так:

https://salsa.debian.org/science-team/librecad/-/blob/master/debian/rules

https://salsa.debian.org/science-team/librecad/-/blob/master/debian/librecad.install

более адекватные инструменты: qbs, Meson

Вкусовщина. :) Если в проекте есть и Meson и CMake, я всегда выберу CMake.

Похоже, в librecad не используют установку из qmake.

Если в проекте есть и Meson и CMake, я всегда выберу Meson.

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

cmake тоже выкинь (и на autotools не смотри), пиши мейкфайлы сам, так всем будет проще

Если ты разраб, выкинь это гуано, не поленись, изучи cmake

А если знаешь Lua, не поленись, изучи tup. Но можно обойтись и без знания Lua.

Не понимаю, почему tup непопулярен.

По поводу autotools согласен, но cmake я право не представляю чем заменить, против него не находил внятной аргументации, тогда как против qmake(иногда надо по 2 раза проект собирать) и autotools(куча лишних движений) её много

cmake даёт реальную кроссплатформенность(дальше вопросы к вашему поекту и зависимостям), make такую не обеспечит никогда

Всего лишь PREFIX=, как в любой другой системе сборки.

Видел, пока не понял

Тяжко тебе.

Если ты разраб, выкинь это гуано, не поленись, изучи cmake, избежишь кучи проблем

Не отменяя того что qmake действительно не нужен, прежде чем такие вещи писать не поленись и почитай хотя бы первые строчки документации. Справедливости ради, с опакечиванием приложений на qmake никаких проблем никогда не встречал - он логичен, делает то что скажут и настраивается в нужных пределах. А cmake от имбецилов которые любят творить х-ню при сборке ни разу не панацея - наоборот, позволяет делать ещё больше невообразимой дичи. Хочешь докером тебе контейнеров накачает, хочешь - зависимостей git’ом и поставит всё это неизвестно куда.

Хочешь докером тебе контейнеров накачает, хочешь - зависимостей git’ом и поставит всё это неизвестно куда.

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

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

Оно не сработало

$ qmake PREFIX=/local my.pro

Project MESSAGE: Install Prefix is: /local

неа

$ qmake PREFIX=$HOME/.local librecad.pro  
Project MESSAGE: We will be using CPP11 features

Что именно «неа»?

Я проверил сгенерированный Makefile c префиксом /opt, всё (де)инсталлируется. И какая версия qmake?

Значит, в librecad рукопопы. :)

А что в my.pro, если не секрет?

Ничего, собирательный образ. :)

Но проверял на goldendict.pro.

Так это не поведение qmake по умолчанию, это разработчики озаботились.

# Install prefix: first try to use qmake's PREFIX variable,
# then $PREFIX from system environment, and if both fails,
# use the hardcoded /usr/local.
PREFIX = $${PREFIX}
isEmpty( PREFIX ):PREFIX = $$(PREFIX)
isEmpty( PREFIX ):PREFIX = /usr/local
message(Install Prefix is: $$PREFIX)

Ну да.

Значит, в librecad рукопопы. :)

Почитал повнимательнее файлы проекта И таки да рукожопы редкие

Это правда, но только на половину. В конце концов никто не пишет кусок говна на шелле только чтобы вызвать его из системы сборки - говно творят именно на системе сборки. Поэтому задача оной - предоставить разработчику все решения его тупорылых хотелок, но так чтобы нормальные люди могли всё это отменить одним флажком. Этакий embrace, extend & extinguish плохих практик.

Мудак-разработчик хочет звать git чтобы забить собираемую ревизию в бинарник? Предоставьте ему встроенный аналог autorevision, только не от недоучки Реймонда, а адекватный - не тянущий git в зависимости, не цепляющий левые репы выше по дереву и позволяющий [при пакетировании] явно передать версию.

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

Мудак-разработчик хочет чтобы приложение имело непредсказуемую функциональность в зависимости от того какие зависимости нашлись при сборке? Ради бога, но для нормальных будет ключик считать все опциональные зависимости обязательными (недавно узнал про --auto-features=enabled в meson).

Мудак-разработчик хочет добавить во флаги -Werror или -march=native? Дайте ему удобную крутилку для этого, чтобы при опакечивании она была безусловно выключена.

И т.д.

Ну в целом я согласен со всем изложенным, но всё-таки есть нюансы:

1. Я понятия не имею, что такое autorevision, но зависеть от гита, чтобы получить теги и хэш весьма удобно. Можно, конечно, встроить это в систему сборки, но тогда она будет зависеть от гита или от libgit, или зачем-то будет велосипедить свой полусовместимый гит, что ещё хуже.

2. Доставка зависимостей - это вообще функциональность пакетного менеджера, с которыми в плюсах и сишке полный швах. В общем случае, это не проблема системы сборки, её дело find_package запускать, а не качать. То, что кто-то велосипедит свой костыльный менеджер зависимостей, ещё и на cmake, это следствие отсутствия стандартизированного pm. В meson’е для этого есть какие-то специальные плюшки? Как они по сравнению с conan?

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

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

В общем тут всё, как с плюсами: есть языки, которые все ругают и есть языки, которыми никто не пользуется. Cmake кривой, косой и не удобный, но проблема не в нём.

Я понятия не имею, что такое autorevision

Это скрипт имени широко известного в узких кругах костылеклепателя Эрика С. Реймонда, который получает эту самую ревизию из VCS (типа-работает везде, умеет все VCS какие-то там настройки и перделки, в итоге не работает без патчинга и обычно просто вырезается при пакетировании). Но ладно autorevision, это хотя бы попытка сделать универсально. Обычно вызывают просто git rev-parse, а это ломается во-первых потому что при сборке не обязано стоять никакого гита, а во-вторых потому что сборка происходит не из репы, а из скачанного тарболла. И самое смешное когда гит репой является, например, хомяк или корень, и тогда ревизия собираемой софтины берётся оттуда.

но зависеть от гита, чтобы получить теги и хэш весьма удобно

Для какого кейса? Разработчики которые собирают из репы тебе и сами скажут хэш коммита, у пользователей использующих дистрибутивные пакеты никакого хэша не будет потому что во-первых, зависимость от git будет первым делом вырезана мантейнером, во-вторых, пакеты собираются не из репы, а из тарболла.

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

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

Доставка зависимостей - это вообще функциональность пакетного менеджера, с которыми в плюсах и сишке полный швах.

Ты что-то путаешь, пакетный менеджер это часть системы. В плюсах и си с ним как раз всё замечательно, ибо они не пытаются заниматься его работой. Как какие-нибудь pip, npm и cargo, которые либо выкачивают неизвестно что неизвестно откуда и в итоге не смогут собрать потому что Петя сломал API в патч версии, а Вася вовсе удалил свой leftpad, либо выкачивают известно что, где никогда не будут исправлены уязвимости и баги. И в любом случае не могут собрать простейший проект без доступа к сети.

В общем случае, это не проблема системы сборки, её дело find_package запускать, а не качать.

Это всё понятно, но долбоящерам же этого не объяснишь? Они хотят чтобы все зависимости были с собой и можно было собрать сразу готовый проект, потому что они привыкли разрабатывать под пускалкой проприетарных игрушек где нет пакетного менеджера. Или считают что libfmt и lua из системы тянуть слишком сложно, и надо насрать ими прямо в репу. Ну ещё редкие люди которые зависят от патченной версии апстрима и им это может быть даже действительно нужно.

И вот когда ты можешь одной строчкой сказать «пук-среньк хочу тут забандлить libfmt» ты сделаешь именно это, а не будешь тратить время на костыль, и мой поинт в том чтобы это позволяло прийти потом и сказать - «то что это профнепригодное чмо считает тут забандленным libfmt - на самом деле лежит вот там в системе».

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

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

Для какого кейса?

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

Для opensource это, наверное, не лучшая идея, и надо через гитхуки или руками вести версии и брать их из файлика или из флагов, как минимум если гита нет. Но тут как обычно хотелки разработчиков vs хотелки мейнтенеров, и притащить для сборки git и собирать из тарбола с включённым в него .git, это не прямо какое-то космическое требование. С этим жить вполне можно. Опять же, далеко не все разрабы понимают проблемы мейнтейнеров, так что тут один вариант - предлагать патчи, opensource же.

Ты что-то путаешь, пакетный менеджер это часть системы.

Я имел ввиду что-то типа conan, аналога pip, npm и т.п. Pm дистрибутива, это вещь, конечно, замечательная, но рассчитывать на него не всегда получается.

Ну например, представь, что тебе нужен свежий буст, а ты при этом поддерживаешь rhel 7. Да, ты сделал find_package, указал минимальную версию, а дальше что? Ну ок, допустим ментейнер как-то притащит нужную версию буста, соберёт её для сборочного окружения и даже поставит. А в readme в инструкции для сборки ты что будешь писать? Собирать-то надо не только мейнтейнерам, но и обычным пользователям, и для них это должно быть так, что ты поставил зависимости по списку, запустил cmake и всё готово. И это куда важнее, чем боль мейнтейнеров о том, что что-то забандлено.

А ведь ещё бывают зависимости, которых в дистрибутивах просто нет. Мейнтейнер опакетит, но пользователь такой хернёй заниматься не будет. Поставить пакеты по списку и вбить пару команд - это максимум, на который можно рассчитывать.

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

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

И вот когда ты можешь одной строчкой сказать «пук-среньк хочу тут забандлить libfmt» ты сделаешь именно это

Ну вообще через conan забандлить fmt куда удобнее, чем через git. В идеальном мире для этого бы существовала опция в pm, которой можно было бы сказать найти пакет в системе через тот же pkg-config. В конане для этого надо писать свой dummy-враппер. Что с vcpkg не знаю. Так что приходится велосипедить cmake-флаги и генерировать файл зависимостей conan’а на лету (это единственный вариант, который я придумал, но я, правда, opensource не пишу).

Насколько я понимаю, в мезоне всё выше обсуждаемое так же актуально.

# create folder structure
# ...snip...
mkdir -p appdir/usr/share/librecad
# ...snip...
mkdir -p appdir/usr/share/librecad

На всякий пожарный.

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

Ну я вообще не о комменсне. Там можно любое говно творить, никому же в это лезть не понадобится.

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

project(foo VERSION 1.2.3), больше ничего не надо

Но тут как обычно хотелки разработчиков vs хотелки мейнтенеров, и притащить для сборки git и собирать из тарбола с включённым в него .git, это не прямо какое-то космическое требование.

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

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

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

Я имел ввиду что-то типа conan, аналога pip, npm и т.п. Pm дистрибутива, это вещь, конечно, замечательная, но рассчитывать на него не всегда получается.

Мы обсуждали опакечивание, а ты ушёл куда-то в сторону. Проблемы тех кому нужно поддерживать RHEL7 и пользователей дистрибутивов где нет актуальных зависимостей меня не сильно волнуют. Остальным никакие conan и vscode не нужны.

изучи cmake… у него получаются более быстрые makefileы

Жду пруфов на тесты.

У cmake вырвиглазный синтаксис. И если мой проект работает с разными мажорными версиями Qt, в cmake нужно подключать разные модули, файл проекта qmake куда более компактен.

файл проекта qmake куда более компактен

Может стоит открыть для себя новые возможности, а не сидеть на давно протухшей версии 2.8?

массовое помешательство в треде!

qmake не занимается никакими установками. оно генерит мейкфайлы. Всё!

Праграмма librecad, и по их инструкциям зачем то нужен qmake -r.

нуок.

qmake -r
make
INSTALL_ROOT=$HOME/.local make install

Look, ma! No hands sudo!

/thread

project(foo VERSION 1.2.3), больше ничего не надо

Ну это ведение версии руками.

Остальным никакие conan и vscode не нужны.

Ну так конечно не нужны, у них же есть git submodule. Правда тебе это почему-то не нравится, а виноват в этом, почему-то, cmake.

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

Да ни в каких дистрибутивах нет ВСЕХ актуальных зависимостей. Ну очевидно же. Вот есть, например, ctre, как её поставить пакетным менеджером дистрибутива? Потому и бандлят. Не нравится ctre, возьми любую другую из миллионов библиотек, которой нет в твоём дистре.

Вот есть, например, ctre, как её поставить пакетным менеджером дистрибутива?

А в чём проблема? Вот в nixpkgs она есть, а если бы не было, запаковать как два пальца. А как поставить — а зачем её «ставить»? Добавляешь в buildInputs и всё.

И что там по обсуждаемому вопросу в новых cmake?

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

Извиняюсь, что вопрос не по теме треда.

Чем qmake, ... удобнее https://en.wikipedia.org/wiki/Code::Blocks ?

Ну это ведение версии руками.

Ну от этого никуда не деться. changelog тоже руками надо писать, никто не жалуется.

Ну так конечно не нужны, у них же есть git submodule. Правда тебе это почему-то не нравится, а виноват в этом, почему-то, cmake.

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

Да ни в каких дистрибутивах нет ВСЕХ актуальных зависимостей.

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

Ну очевидно же. Вот есть, например, ctre, как её поставить пакетным менеджером дистрибутива?

Даже в моей сраной мёртвой FreeBSD это pkg install ctre.

Потому и бандлят. Не нравится ctre, возьми любую другую из миллионов библиотек, которой нет в твоём дистре.

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

Тем же чем git удобнее firefox.

changelog тоже руками надо писать, никто не жалуется.

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

Если про установку, то Cmake имеет опцию создания пакетов в Linux и инсталяторов в Windows. Если про синтаксис, то он стал несколько проще. И уж точно в Cmake удобнее делать модульный проект.

А в чём проблема?

Проблема в том, что её нет в хоть сколько-нибудь не маргинальных репах, да и не нужна она там. Опакетить можно, но только разработчик софта этим заниматься не будет, тем более не будет он этим заниматься под сотню-другую дистрибутивов.

Как следствие, он при сборке притянет её любым, удобным ему способом (conan, vcpkg, git, …).

Ну от этого никуда не деться. changelog тоже руками надо писать, никто не жалуется.

Ок, согласен.

Потому что опакетить библиотеку намного проще чем даже себе в проект её затащить.

Под твой любимый дистрибутив, быть может и проще, хотя я не уверен. Всё-таки одна строка в conanfile по-проще будет.

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

По-хорошему, в проекте должны быть флаги: это бандлим, это берём из внешних либ. Но в том, что многие разрабы на это забивают, нет ничего удивительного. В общем если ты вспомнешь, сколько в мире разных дистров линукса, и сколько ещё не линуксов, то тебе станет вполне понятно, почему разрабы не хотят завязываться на пакетники дистрибутивов.

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

Тоже не работает, там надо редачить *.pro файлы, я выяснил уже

Жду пруфов на тесты.

Да нет их там, это фантазия автора. Если посмотреть подробно и исследовать вопрос, окажется что CMake генерирует ну очень тяжёловесные и медленные Makefile’ы, обмазанные всяким временным созданием TXT-файлов для отображения прогресса и прочей информации. У qmake сгенерированные Makefile’ы будут намного быстрее тех что порождают CMake и Autotools, потому что там куда более простой генератор и в. т. ч. генератор зависимостей. И главное, их можно без труда отредактировать в случае чего, а вот то что нагенерировано CMake или Autotools хрен ты отредактируешь. Более того, CMake для вывода Verbose-информации не поддерживает традиционное для UNIX-систем make V=1, ему нужен виндовый make VERBOSE=1, что ломает некоторые скрипты, но это проблема довольно минорная и связанная с общей виндовозностью CMake’а – ту да же относится и угёбищный регистронезависимый синтаксис, превращающий код в вашем репозитории в помойку.

Единственное преимущество CMake в данном случае – это возможность выкидывания медленных Makefile на мороз и использование генератора Ninja, который будет собирать проекты быстрее любых make. QMake так не умеет, к сожалению, а жаль. Но самый недостаток и mindfuck у QMake, который я запомнил – тупо захардкоженный стиль отступов 1TBS с невнятными ошибками в случае расхождения с ним:

static 
{
   something
}

# ^ Parse Error ('static') Unterminated conditional

static {
   something
}

# ^ Ok

Многие кто имеет проекты на Qt натыкались на подобное и долго не могли понять что происходит.

Тоже не работает, там надо редачить *.pro файлы, я выяснил уже

Ты так и не сказал под какой именно дистрибутив собираешь пакет? Почему тебя не устроили стандартные рецепты, которыми собирают LibreCAD в твоём дистрибутиве? И что именно ты поменял, чтобы make install копировал файлы в нужную тебе директорию.

Это в принципе разные вещи. Code::Blocks — это IDE, среда разработки, cmake и qmake — системы сборки (которые должны уметь работать как из IDE, так и без неё и вообще без всякого GUI, например, по живительному пинку от сервера CI).

К примеру, Qt Creator — это тоже IDE, он из коробки умеет создавать проекты и для cmake, и для qmake, и можно подключить кое-что ещё (но с этим кое-чем я не разбирался).

Современный Code::Blocks вроде как умеет работать со cmake, но я его очень много лет не тыкал, подробнее не скажу.

под дебиан 11, мне иконки элементов интерфейса в тёмной тене не понравилось как смотрятся)

Пропатчил то я минут за 10, а вто когда началась установка…

Вызов принят, я чекну

Code::Blocks — это IDE, среда разработки, cmake и qmake — системы сборки

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

cmake-gui с интерфейсом на qt и ccmake с ncurses интерфейсом.