Кто-нибудь пробовал build2?

Согласен. Грепать нужно. Ну хоть что-то. С другой стороны, качественное документирование процесса конфигурирования/сборки тоже может быть в виде readme.md

Не люблю документировать ручками если честно. Хочу чтобы всё делалось автоматически.

Я все это делал исключительно через cmake.

Если вы про rpath в ELF модуле, то это ещё больший костыль, прибивающий бинарник к фиксированному месту.

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

хотелось, чтобы cmake был самодостаточен

Что надо было писать объявления всех библиотек для всех систем сборки? Спасибо, не надо. pkg-config — это хоть какой-то де-факто стандарт.

Если вы про rpath в ELF модуле, то это ещё больший костыль, прибивающий бинарник к фиксированному месту.

Так можно ведь в RPATH использовать специальную строку ORIGIN/… и тогда пути будут отсчитываться от местоположения исполняемого файла. И тогда весь каталог с программой может быть где угодно. Разумеется в соответствующем файле .desktop с путями для главного меню должны быть правильные пути.

Что надо было писать объявления всех библиотек для всех систем сборки?

Ну хотя бы для самых распростроненных. Да, было бы здорово.

Да, было бы здорово.

Для авторов библиотек и меинтейнеров это кошмар. Не забывайте что объявления библиотек ещё отличаются в разных дистрибутивах.

Есть такое. Но вот для авторов я бы не называл бы это прям уж кошмар. Это нужно сделать один раз и потом изредка вносить небольшие правки. Ведь написание pkg-config файлов ведь не называют кошмаром.

Пояснения уже описаны в docstring к cache-переменным. Вопрос в том, что даже сам cmake не может сгенерировать из этого что-то нормальное. Хотя вот в cmake-gui это сделали, с другой стороны.

Может можно и в консоли вывести ТОЛЬКО опции? Но я не искал способ.

вот мои требования (ну, их также можно назвать хотелками) к системе сборки.

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

мне нравится b2, но в нем туго с ide. cmake не умеет несколько конфигураций, но там есть много полезных штку, например можно сгенерировать проект для ide, создать пакет, запустить тесты.

Если вы про rpath в ELF модуле, то это ещё больший костыль, прибивающий бинарник к фиксированному месту.

к фиксированному месту.

ЧоЧо? Ты совсем болен? Одна из фич RPath возможность указать относительные пути к поиску библиотек: ../lib64/, тем самым получая возможность создавать портабельные программы которые не прибиты к отному месту.

Алсо ЕМНИП там есть в cmake что-то типа build rpath полезно для разработки софта в IDE + для запуска программы до make install, и install rpath для релизной сборки установки в систему.

Да

wandrien

Да.

ОС-то при чем.

Что, прямо для Windows работает с MSVC и для macOS с каким-нибудь homebrew?

Насколько я помню, эти модули в CMake умеют подобное. А вот pkg-config работает только в чужеродных окружениях вроде MSYS2.

pkg-config просто читает флаги из конфигов.

В макоси совместимый по флагам компилятор из коробки, не?

В винде можно его поставить.

Для cl.exe можешь сконвертировать флаги sed-ом на лету.

В макоси совместимый по флагам компилятор из коробки, не?

Без понятия как в macOS pkg-config ложится на тамошний менеджер «пакетов» и рецептов вроде homebrew, но вроде как активно используется.

C MSVC вроде тоже работает: https://github.com/fanc999/pkg-config/blob/master/README.win32

Хотя сейчас в Windows во всю юзают всякие https://github.com/microsoft/vcpkg и прочие https://conan.io/, насколько я помню, они сильно завязаны на CMake и его модули.

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

Автотулзы живы и продолжают доминировать

GNU Poke 1.0 (комментарий)

пруф https://git.savannah.gnu.org/cgit/poke.git/tree/configure.ac

ЧоЧо?

Упячка Упячка!!! Шячло Попячтса!

Превед из 2007-го.

Зачем вообще RPATH? Линковать с конкретной libxyz.so.x.y.z и класть её в пакет. Ситсемная будет видна как libxyz.so -> libxyz.so.a -> libxyz.so.a.b -> libxyz.so.a.b.c а libxyz.so.x.y.z будет лежать рядом и никого не трогать. Удалится вместе с пакетом, если что. С долбаной libicu*.so (будь прокляты её создатели, за каким-то хером непрерывно меняющие мажорную версию и ломающие совместимость) постоянно так приходится делать, чтобы не пересобирать весь сторонний софт при обновлении.

Можно и в системный каталог ложить. Но я так не люблю. Любо я использую библиотеку из стандартного репозитория, либо я несу библиотеку в пакете и храню ее в каталоге с программой. Потому что вот ты положишь библиотеку в системный каталог и зубудешь прописать правильно конфликты (ведь может быть пакет с точно таким именем файла библиотеки или он может появиться в будущем) и будет хер знает что. К тому же, если ты в составе своего пакета несешь библиотеку Х и кладешь ее в системный каталог, то это некрасиво и неаккуратно: если библиотека располагается в системном каталоге, то она должна быть в отдельном пакете, а не в составе другого пакета.

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

Но если и возникла такая ситуация, то геморроя с одинаковыми названиями можно легко избежать, например, если использовать какой-нибудь префикс или суффикс для библиотеки. Для конкретной софтины это несложно. Но вообще, если софтине точно нужна очень специфическая версия библиотеки и никакая другая, и её один хрен придётся таскать с собой - что мешает слинковать эту библиотеку с софтиной статически и не иметь вообще никакого геморроя ни с чем? Маинтейнеру при создании пакета всё равно придётся заново собирать эту библиотеку с нужными опциями, отличными от дистрибутивных, так какая разница, динамически её потом слинковать с софтиной или статически, это же тупо всего лишь вместо -l:libxyz.so.x.y.z сказать линкеру -l:libxyz.a ? Да и места меньше займёт, ибо неиспользуемые функции либы при статической линковке будут выкинуты.

Вопрос вообще ИМХО выеденного яйца не стоит. Уж где-где, а в линуксе никакого DLL hell не было и нет.

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

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

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

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

Но вообще, если софтине точно нужна очень специфическая версия библиотеки и никакая другая, и её один хрен придётся таскать с собой - что мешает слинковать эту библиотеку с софтиной статически и не иметь вообще никакого геморроя ни с чем?

Я не считаю использование динамических библиотек геморроем. УМВР. По поводу статической линковки - это другая тема, это не было первоначальным предметом дискуссии.

Вопрос вообще ИМХО выеденного яйца не стоит. Уж где-где, а в линуксе никакого DLL hell не было и нет.

В принципе согласен. Тут скорее личные предпочтения и правила определяют.

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

Я вообще не понимаю, зачем в такой ситуации делать эту библиотеку динамической.

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

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

Я вообще не понимаю, зачем в такой ситуации делать эту библиотеку динамической.

Нет. Мне не хочется про это дискутировать. Это другая тема.

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

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

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

Как законченное решение для распространения - сомнительно как-то.

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

Qt Creator например, который устанавливается из официального установщика несет с собой каталог с требуемыми библиотеками и имеет прописанный RPATH. Кроме этого раньше Viber для Linux тоже нес все библиотеки Qt с собой и имел прописанный RPATH (не знаю, как сейчас).

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

cmake не умеет несколько конфигураций

Ты про -G "Ninja Multi-Config или что?

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

Почему? Там и так полно либ с нестандартными именами. Тот же KDE, например этим страдает. Или samba4. Всё-же динамические либам полагается лежать в специально отведённом для этого месте. Вдруг их кто-то ещё захочет найти и слинковаться с ними. Они же для этого сделаны динамическими.

Кроме этого может быть ситуация, когда новое ПО требует версии библиотеки НОВЕЕ системной.

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

А если делали - то почему тогда имя не поменяли, чтобы понятно было, что эта либа подшаманенная?

Неверно (точнее, обоснуй в чем сомнительность).

RPATH может быть уже установлена пользователем для каких-то глобальных целей. А тут какой-то софт её меняет.

Qt Creator например, который устанавливается из официального установщика несет с собой каталог с требуемыми библиотеками и имеет прописанный RPATH

Ну это всё-же девелоперская хрень. Там RPATH может быть вполне уместен.

Кроме этого раньше Viber для Linux тоже нес все библиотеки Qt с собой и имел прописанный RPATH (не знаю, как сейчас).

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

Если вы про rpath

Rpath – это вообще адовая хрень. Но LD_LIBRARY_PATH ничего так.

Как-то смотрел эту штуку, помню, что не пошла. если правильно помню, не так давно появилось это в cmake.

я вобще про то, как это можно например в boost build сдлеть, там довольно удобно: просто задаешь несколько значений одному параметру, например разные компиляторы, разные дефайны и прочее, он сам разберется как это все билдить.

Ну с смейком примерно так же. Компиляторы задаются тулчейн файл, флаги через конфигурацию (дебаг, релиз и т.д.). Только внешний враппер нужен. У меня пиновый скрипт на 100 строк или типа того собирает все конфигурации под все нужные платформы. И конкретно здесь я не вижу проблемы на самом деле. Т.е. наверное можно засунуть абсолютно все варианты сборки под один билд_дир аналогично мульти-конфиг сборкам… но зачем?..

Ninja Multi-Config это сравнительно новое, да. Но я вообще не понимаю как можно старым цмаком пользоваться, он и сейчас не слишком юзабелен :) В 3.20 вон add_custom_command пофиксят наконец, станет получше

Почему? Там и так полно либ с нестандартными именами. Тот же KDE, например этим страдает. Или samba4. Всё-же динамические либам полагается лежать в специально отведённом для этого месте. Вдруг их кто-то ещё захочет найти и слинковаться с ними. Они же для этого сделаны динамическими.

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

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

Да, приедет и заменит файл? Или вообще не сможет установиться (не помню, как пакетный менеджер будет себя вести). Это и превращает пакетную систему в хаос.

А если делали - то почему тогда имя не поменяли, чтобы понятно было, что эта либа подшаманенная?

Подшаманенную никто кроме тебя юзать не будет.

RPATH может быть уже установлена пользователем для каких-то глобальных целей. А тут какой-то софт её меняет.

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

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

Давай проясним. Я это писал вскользь, но ты видимо не уловил. Я не против ложить библиотеки в системный каталог, но только по правилам: библиотека должна быть в отдельном пакете, который называется именем библиотеки, а не быть в составе другого пакета как third_party (если так то, она должна быть в отдельном каталоге (например с программой, для которой она third_party, как я и писал выше)). Далее должны быть корректно прописаны зависимости и конфликты.

Rpath – это вообще адовая хрень. Но LD_LIBRARY_PATH ничего так.

Спасибо, святой отец.

В 3.20 вон add_custom_command пофиксят наконец, станет получше

А что именно там пофиксят?

https://gitlab.kitware.com/cmake/cmake/-/issues/12877

А чем build2 лучше чем, например Qbs?

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

А то развелось, понимаешь, каждый должен написать свой ФМ, плеер, антивирус (привет бабушкину), и, теперь, систему сборки. )))

А то развелось, понимаешь, каждый должен написать свой ФМ, плеер, антивирус (привет бабушкину), и, теперь, систему сборки. )))

Ты забыл главный тренд: СВОЙ ЯП.

Свой ЯП действительно должен написать каждый. И никому его не показывать.

я уже несколько раз напарывался на то, что сломал сборку или тесты на каком-нибудь компиляторе, не на том, на котором работаю (собенно часто, если собираешь шлангом, то на гцц может сломаться, ибо шланг много себе позволяет. а попытался я с ним работать из-за того, что clang code model в qtcreator не работает, если сборка не на нем (ну по крайней мере, я не смог завсети). ).

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