Вы можете представить подобного рода дискуссии вокруг go/python/java и других современных языков программирования со своими пакетными менеджерами? Я не могу. Я в статье специально написал, что conan - это лучшее, что произошло в мире С++, но он до сих пор далек от того, чтобы его можно было назвать менеджером пакетов языка С++. На текущий момент он может существенно упростить работу с зависимостями и собрать ваш проект для конкретных версий. Но постоянно поддерживать зависимости в актуальном состоянии для вашего проекта очень тяжело и опубликовать ваш пакет тоже не просто
По поводу Qt. Там тот же самый автор снова выложил два пуллреквеста, надеюсь они вмержатся.
Нет) что то вроде ansible, но который запускает все команды одновременно, стримит их вывод и сохраняет его локально. Я все ещё не придумал, как объяснить коротко, что делает проект
Это мы говорим о линковке с системными библиотеками из языка, которых нет из коробки. Ну в таком случае такой подход не будет работать, да. Но это все же ограничения языка я считаю. Когда он не может покрыть функциональность своими средствами, приходится их тянуть из с/с++ и тогда конечно будет не так просто выглядеть сборка. Но это частный случай. А в с/с++ любая сборка и распространение могут стать проблемой
Нет, в go есть фича go run. То есть можешь поставить в системе go и запускать нужные тебе утилиты указывая ссылку на гитхаб нужной тебе утилиты. Тогда и проблема с паранойей решается тоже, а для разработчиков утилит можно дале не собирать бинарник для распространения.
И go это частный случай, во всех современных языках, что я знаю, эта проблема решена.
С этим я не спорю совершенно. Это вообще основная причина, почему я не поменял в итоге язык, он даёт полную свободу и возможность реализовать что угодно и интегрироваться куда угодно.
Но факт в том, что язык с++ не решает проблемы сборки и распространения вообще никак, в то время как в других языках эта проблема решена.
Go лучше, потому что он вам на выходе даёт готовый к запуску на платформе бинарник. Для С++ вам ещё нужно организовать portable версию архива. Например самостоятельно пройтись по всем зависимостями положить их в одну папку. А вы могли ещё сделать это не правильно, например, случайно поместив в ваш архив библиотеки из системы, а не из зависимостей,с которыми вы собирались.
Чтобы собрались зависимости достаточно компилятора go
Чтобы приложение запустились, достаточно его один раз собрать на платформе (все зависимости линкуются статически).
Таким образом go на уровне языка решает обе эти проблемы. И так во всех языках обе эти проблемы каким то образом решены. Да, для некоторых потребуется заранее настроить ещё окружение для запуска (python, java, c#), но оно одно и ставится единожды на всю платформу.
В С/С++ задача сборки и запуска вообще никак на уровне языка не решается.
Я считаю это особенностью языка. GO например такой проблемы не имеет. Если вы установили go, то этого достаточно и это гарантия того, что зависимости соберутся. В принципе и со всеми остальными языками так же (java, python, ruby, c#, rust и т.д.). Мне даже трудно назвать язык имеющий такую же проблему. Везде наличие компилятора/интерпретатора языка даёт гарантию подключения зависимостей.
Это ещё один пакетный менеджер куда нужно встраивать сборку, как в fedora dnf или debian apt-get, а значит не решает проблему.
Проблема С++, что он не имеет пакетного менеджера с изолированным окружением, в который вы можете добавить свой пакет и забыть о его распространении под другие платформы, где может применяться С++. Таким пакетным менеджером мог бы стать conan, но очень далек от этого.
Это просто скрипт, который позволяет собрать зависимости Qt. Кроме них в проекте ещё есть зависимости и он не решает проблемы доставки до пользователей приложения и библиотеки
Gui к go не прикрутить потом. Кроме того как спроектировать расширяемый асинхронный интерфейс не очень понятно, чтобы можно было его в плагины вынести например
Если в соглашении сторон Андрей Х требовал 3 зарплаты, то компания на данный момент выплатила 2.5 зарплаты. Получается экономия в 0.5 зарплаты сотрудника. Шах и мат, профсоюзники!
Вы можете представить подобного рода дискуссии вокруг go/python/java и других современных языков программирования со своими пакетными менеджерами? Я не могу. Я в статье специально написал, что conan - это лучшее, что произошло в мире С++, но он до сих пор далек от того, чтобы его можно было назвать менеджером пакетов языка С++. На текущий момент он может существенно упростить работу с зависимостями и собрать ваш проект для конкретных версий. Но постоянно поддерживать зависимости в актуальном состоянии для вашего проекта очень тяжело и опубликовать ваш пакет тоже не просто
По поводу Qt. Там тот же самый автор снова выложил два пуллреквеста, надеюсь они вмержатся.
А, понял, да
sudo требуется только для tcpdump. Можно или убрать команду из файла, или научить запускать tcpdump от пользователя. Тогда sudo не нужен
А так у вас основной сценарий использования утилиты )
Нет) что то вроде ansible, но который запускает все команды одновременно, стримит их вывод и сохраняет его локально. Я все ещё не придумал, как объяснить коротко, что делает проект
Отображать множество стримов в вебе такое себе.
Это мы говорим о линковке с системными библиотеками из языка, которых нет из коробки. Ну в таком случае такой подход не будет работать, да. Но это все же ограничения языка я считаю. Когда он не может покрыть функциональность своими средствами, приходится их тянуть из с/с++ и тогда конечно будет не так просто выглядеть сборка. Но это частный случай. А в с/с++ любая сборка и распространение могут стать проблемой
Нет, зачем компилятор с/с++? Go достаточно. На понятно что gui приложение ты не соберёшь так, но это другое ограничение другого языка уже.
Нет, в go есть фича go run. То есть можешь поставить в системе go и запускать нужные тебе утилиты указывая ссылку на гитхаб нужной тебе утилиты. Тогда и проблема с паранойей решается тоже, а для разработчиков утилит можно дале не собирать бинарник для распространения.
И go это частный случай, во всех современных языках, что я знаю, эта проблема решена.
С этим я не спорю совершенно. Это вообще основная причина, почему я не поменял в итоге язык, он даёт полную свободу и возможность реализовать что угодно и интегрироваться куда угодно.
Но факт в том, что язык с++ не решает проблемы сборки и распространения вообще никак, в то время как в других языках эта проблема решена.
Go лучше, потому что он вам на выходе даёт готовый к запуску на платформе бинарник. Для С++ вам ещё нужно организовать portable версию архива. Например самостоятельно пройтись по всем зависимостями положить их в одну папку. А вы могли ещё сделать это не правильно, например, случайно поместив в ваш архив библиотеки из системы, а не из зависимостей,с которыми вы собирались.
Есть две проблемы:
Проблема сборки зависимостей
Проблема запуска
Для go обе проблемы решены
Чтобы собрались зависимости достаточно компилятора go
Чтобы приложение запустились, достаточно его один раз собрать на платформе (все зависимости линкуются статически).
Таким образом go на уровне языка решает обе эти проблемы. И так во всех языках обе эти проблемы каким то образом решены. Да, для некоторых потребуется заранее настроить ещё окружение для запуска (python, java, c#), но оно одно и ставится единожды на всю платформу.
В С/С++ задача сборки и запуска вообще никак на уровне языка не решается.
Я считаю это особенностью языка. GO например такой проблемы не имеет. Если вы установили go, то этого достаточно и это гарантия того, что зависимости соберутся. В принципе и со всеми остальными языками так же (java, python, ruby, c#, rust и т.д.). Мне даже трудно назвать язык имеющий такую же проблему. Везде наличие компилятора/интерпретатора языка даёт гарантию подключения зависимостей.
Это ещё один пакетный менеджер куда нужно встраивать сборку, как в fedora dnf или debian apt-get, а значит не решает проблему.
Проблема С++, что он не имеет пакетного менеджера с изолированным окружением, в который вы можете добавить свой пакет и забыть о его распространении под другие платформы, где может применяться С++. Таким пакетным менеджером мог бы стать conan, но очень далек от этого.
В этом и суть проблемы. Чтобы заинтересовал, нужно чтобы попробовал. По крайней мере мне только так удавалось его продвигать.
Это просто скрипт, который позволяет собрать зависимости Qt. Кроме них в проекте ещё есть зависимости и он не решает проблемы доставки до пользователей приложения и библиотеки
Когда проект начал, о нем было известно ещё меньше, чем о conan. Надо будет как нибудь попробовать
Gui к go не прикрутить потом. Кроме того как спроектировать расширяемый асинхронный интерфейс не очень понятно, чтобы можно было его в плагины вынести например
Спасибо за статью! Давно искал вариант подписи open source проекта.
Типичная циклическая зависимость выученной беспомощности:
Бороться не нужно, потому что есть суд, трудовая инспекция, прокуратура
Если трудовая инспекция, прокуратура и суд не работают, то бороться бессмысленно
Если в соглашении сторон Андрей Х требовал 3 зарплаты, то компания на данный момент выплатила 2.5 зарплаты. Получается экономия в 0.5 зарплаты сотрудника. Шах и мат, профсоюзники!