Оценки хелловорлда тред

Я нахожу её удобнее, чем наркоманскую макросню CMake'а и ту же регистронезависимость.

При чем тут cmake, я говорил о premake5.

Так уж повелось, что в IT часто выигрывает самое отвратное и угрёбищное решение.

Может на самом деле cmake не так и плох, как вы о нем говорите, раз он победил?

В результате CMakeLists.txt по сути стал стандартом в мире C/C++ и это прискорбно.

Стандарт - это скорее хорошо, чем плохо.

Не знаю про totem, щас проверю.

Есть новости?

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

Генерация проекта для xcode под macos, ios, tvos - та еще прелесть.

О, вроде хорошая штука.

Могла бы быть хорошей штукой. Но там один разработчик и очень маленькое комьюнити.

Она умеет генерировать «проекты» для какого-нибудь плагина к текстовому редактору и/или IDE? Первая страница поиска не выдавала ничего полезного.

Не уверен, что понял ваш вопрос. Premake5 умеет генерировать проекты к разным средам разработки. Поскольку конфиг этого генератора пишется на lua, то там можно кастомизировать многое. Можно вообще написать свой внешний генератор.

Вам бы всё проектики генерить, да вот то что генерирует cmake - проектом не является. Это прослойка для интеграции cmake в ide, а не проект.

CMake умеет генерировать файлы проекта под разные IDE. Что-то вы увлеклись рассказом того, в чем не смыслите.

При чем тут cmake, я говорил о premake5.

Я к тому, что любой генератор/сборочная система выглядит адекватнее CMake, будь это premake5, QBS или Gradle.

Могла бы быть хорошей штукой. Но там один разработчик и очень маленькое комьюнити.

О чём я и говорил. Было бы неплохо, если бы стандартом стал именно premake5: С/Lua не создают оверхеда по тем же зависимостям и более удобны, чем C/C++/наркоманский DSL с подводными камнями, как в случае CMake.

Я к тому, что любой генератор/сборочная система выглядит адекватнее CMake, будь это premake5, QBS или Gradle.

Тут не спорю.

О чём я и говорил. Было бы неплохо, если бы стандартом стал именно premake5: С/Lua не создают оверхеда по тем же зависимостям и более удобны, чем C/C++/наркоманский DSL с подводными камнями, как в случае CMake.

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

Генерация проекта для xcode под macos, ios, tvos - та еще прелесть

Можно чуть подробнее? Много телодвижений приходится делать?

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

Тот же RedHat в последнее время плотно присел на http://mesonbuild.com/

Но он лишь капля в море, увы.

Но он лишь капля в море, увы.

А гугель обратил внимание на cmake :)

Можно чуть подробнее? Много телодвижений приходится делать?

Premake5 генерирует проект для xcode старой версии. После загрузки, xcode его фиксит. У premake5 нет доступа к некоторым кишкам проекта, поэтому без плясок с бубном не обойтись.

Тот же Firefox с некоторых пор работает только поверх пульсы

Пользуйся гентой, не будет таких детских проблем. И пульсу элементарно ставить не надо будет!

Из попсовых автосборок cmake самый кошерный, т.к. позволяет делать тесты (как автомейк), но не тупит так дико (как тот же автомейк). Программке средней сложности cmake генерирует makefile'ы буквально за считанные секунды, а automake тупит пару минут!

Точно. Я так привык к скорости работы cmake, что просто перестал это замечать.

premake5

Я думал, там о проблемах с CMake

искать зависимости ... CMake

Я тебя умоляю. Типичный CMake Way разработчиков этого поделия:

[CMake Code Monkey #1]: Смотрите на нашу новую сборочную систему CMake, мы написали кучу Find-модулей к популярным библиотекам и заботливо положили их в папочку дистрибутива программы! Разработчикам библиотек больше не нужно думать о написании этих модулей, а разработчикам программ не нужно писать их самостоятельно. Yay!

... прошло три года ...

[CMake Code Monkey #2]: Блин, с этими Find-модулями куча проблем! У нас не хватает рук и вообще мы маленькая компания. Что-то срочно надо делать. Давайте переложим работу по написанию Find-модулей на разработчиков библиотек! А что делать с уже написанными нами Find-модулями? Давайте их заморозим нахер и будем таскать мёртвым грузом за собой всегда! Пок-пок-пок!

... прошло два года ...

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

---

Отличный пример из жизни. Допустим, я хочу написать простейший HelloWorld, проигрывающий OGG-звук и отображающий PNG-изображение. Использовать буду современный SDL2 и сопутствующие либы как зависимости. Ну и сборочную систему CMake, конечно же.

Для поиска зависимостей можно использовать модули SDL2 из диструбутива CMake? Хер там! Нет их и их не принимают туда, так что там только модули для SDL1 и сопутствующих библиотек, CMake как бы говорит нам: иди-ка ты лесом.

Окей, что насчёт самой SDL2? Фух, разработчики положили туда Find-модули, проблема отпадает! Но нам же нужно выводить звук и изображение форматов, отличных от WAV и BMP, верно? Для этого нужны SDL2_mixer и SDL2_image. Смотрим в dev-пакеты этих либ в любом дистрибутиве или в их сорцы. Cюрприз-сюрприз, никаких Find-модулей там тупо нет и ими даже не пахнет!

https://github.com/davidsiaw/SDL2_mixer
https://github.com/davidsiaw/SDL2_image

А это значит, что я должен, как последний виндузятник, идти в интернет и скурпулёзно выковыривать из кучи мокрых писек эти дурацкие модули:

https://github.com/PetorSFZ/VR-Experimentation/blob/master/externals/sfzCore/...

Либо я должен потратить время, чтобы разобраться в наркоманском DSL, попутно преодолевая кучу подводных камней и в итоге написать эти модули своими руками. Желательно так, чтобы они получились кросс-платформенными. Весь GitHub пестрит этими велосипедами, разной степени упоротости:

[1], [2], [3], [4], [5], тысячи их.

Какой из них правильный и корректный? Кто мне ответит? CMake-разработчики? Точно так же касательно библиотеки SDL2_image или вообще любой другой популярной библиотеки, где забили на капризных идиотов из Kitware.

В итоге в любом сколько-нибудь сложном проекте со сборочной системой CMake разработчики греют голову о четырёх наборах разных Find-модулей: 1) заскорузлая херня из дистрибутива CMake, 2) модули разработчиков либ, которые прогнулись под требования CMake-быдлокодеров, 3) модули для либ, разработчики которых срать хотели на CMake, натыренные из интернета, 4) самописные кривые модули от полуразобравшихся в угрёбищном DSL CMake'а программистов.

И самое смешное, что c SDL1 таких проблем не будет. Все замороженные Find-модули лежат и работают как надо:

http://esxi.z-lab.me:666/~exl_lab/screens/CMake_Old_SDL_Find_Modules.png

Позор CMake-разработчикам: https://github.com/Kitware/CMake/pull/152, которые резко «не осилили» и пошли на попятную. И ссаной тряпкой им по лицу. Когда кто-то говорит о CMake и о поиске зависимостей, у адекватных людей это должно вызывать лишь громкий хохот, переходящий в истерику. Потому что хуже эту функциональность сделать ну просто невозможно! Лучше бы её вообще не было.

На кой черт тебе SDL для проигрывания звуков (для этого, вообще-то, ffmpeg нужен) и отображения изображений (а для этого за глаза freeglut'а хватит)?

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

Здравствуй, Eddy.

Тут дело такое, что для ffmpeg и GLFW (зачем нам тянуть целый и устаревший GLUT для показа изображения, когда есть современное и компактное решение?) люди точно так же должны будут ходить с огромным мешком по интернету и собирать эти Find-модули в кучу.

https://bitbucket.org/andreyu/simple-viewer-gl/src/master/cmake/?at=master

Это всё проблема именно CMake, разработчики которого переложили её «с больной головы на здоровую».

Как запускать? ЗЫ: могу попробовать PPA с билдами для убунты сделать, если надо.

Это не проекты т.к они не рабгтают самостоятельно.

На заметку, в KDE меняется громкость. Могли бы конечно и MPRIS прикрутить, тем более любой мало-мальски серьёзный проект его реализовывает.

Почитал комменты. Вместо обсуждения достаточно полезной, но маленькой программы обсуждение билдсистем. Я даже догадался КТО это начал. :)

Вообще можно было по аналогии поискать «mpris totem». Можно, надо сделать Edit → Plugins → DBus Service Plugin.

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

Кстати, раз уж ты на убунте, то правильно ли у меня в CMakeLists.txt указан путь для установки юнита? Там вроде какая-то наркомания с путями в /usr/lib

При переключении аутпутов? Если да, то это не KDE, а пульса. И как раз логично, что пульса не прикрутила MPRIS.

А я такое только в KDE и видел. Хотя пульсой я тоже не так давно начал пользоваться.

Для ffmpeg и glfw не нужны никакие find-модули, т.к. эти библиотеки нормально дружат с pkg-config!

find-модули нужны лишь для всяких монстров вроде куды (где много чего понаверчено и неизвестно где может в системе валяться) и убожеств, которые pc-файл не создают!

Не стоит обращать внимания на пользователей бубунты. Это те же вантузятники.

Ну и на systemd не стоит отвлекаться. Это — временное говно, как и hal когда-то был. Пройдет зуд у придурка поцтеринга, и вернутся к старой доброй openrc или более приличное что-нибудь сделают. Но не это неюниксвейное угребище.

Да, работает.

В инструкции у тебя какая-то чушь:

Building

mkdir build
cd build
cmake ..
make

и там пусто.

А должно быть?

временное говно у тебя в прыще, который на плечах. А придурак сейчас в твоих штанах, в которых недавно было временное говно.

А должно быть?

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

Непонятно, зачем вызывать cmake в пустом каталоге.

Потому что cmake вторым аргументом получает родительский каталог с CMakeLists.txt и начинает генерацию в пустой директории build/ необходимых файлов для сборки.

Так это работает.

mkdir build, cd build, и там пусто.

Это называется out of tree build. В пустой каталог сгенерируется сборочная система (командой cmake path/to/sources). С автотулзами (./configure) тоже так можно, если это специально не отломано в проекте.

Для тех, кто знает как это работает, инструкция не нужна.

git clone https://github.com/f1u77y/headphones-plug-detector.git
mkdir ./headphones-plug-detector/build
cd ./headphones-plug-detector/build
cmake ..
make

Ну и на systemd не стоит отвлекаться.

Почему? Я отвлёкся, потому что он есть как минимум у меня (и он меня устраивает), и у многих других юзеров.

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

А что такое --pauseonly?

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

Потому что вероятность встретить у пользователя alsa — процентов 99 (а то и больше, не знаю, сколько сейчас народу OSS использует). А процент встретить поверх alsa еще и ненужный systemd значительно ниже!

Тьфу, не systemd, а пульсу, конечно. В принципе, как одно, так и другое — ненужное дерьмище.

https://github.com/f1u77y/headphones-plug-detector/blob/63226311feb928ded4df5...

- g_warning(error->message);
+ g_warning("%s", error->message);

Поясни по service

1/

$ systemctl start headphones-plug-detector.service
Failed to start headphones-plug-detector.service: Unit pulseaudio.service not found.

2/ Если временно убрать Requires=pulseaudio.service то:

$ systemctl status headphones-plug-detector.service
● headphones-plug-detector.service - Headphones plug detector
   Loaded: loaded (/usr/lib/systemd/system/headphones-plug-detector.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2017-11-29 19:07:17 EET; 17s ago
 Main PID: 12378 (headphones-plug)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/headphones-plug-detector.service
           └─12378 /usr/bin/headphones-plug-detector

Если просто запустить

$ headphones-plug-detector

Да, надо бы сделать что-то такое. ИМХО, лучше в каком-нибудь конфиге, потому что оно всё-таки рассчитано на автозапуск.

Ага, спасибо, сейчас поправлю.

systemctl --user start headphones-plug-detector.service

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

$ systemctl --user status headphones-plug-detector.service
● headphones-plug-detector.service - Headphones plug detector
   Loaded: loaded (/usr/lib/systemd/user/headphones-plug-detector.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-11-29 19:54:34 EET; 35s ago
 Main PID: 14145 (headphones-plug)
   CGroup: /user.slice/user-1000.slice/user@1000.service/headphones-plug-detector.service
           └─14145 /usr/bin/headphones-plug-detector

Тоже не работает

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

Покажи pacmd list-sinks | grep 'active port' при включённых и выключенных наушниках.

Собрал fedora'вский пакет по этому headphones-plug-detector.spec В общем заработало.