Концепты, корутины, модули... Ерундой какой-то занимаются. Лучше бы utf-8 строки доделали! Перечисления нормальные написали. Флаги добавили, а не вот эту студенческую ерунду.
Здравствуйте, B0FEE664, Вы писали:
NB>>да уже сколько лет просим, дайте нормальную билд систему с пакетным менеджером. NB>>бесполезно
BFE>Зачем это нужно?
зачем это нужно питону, расту и многим другим языкам? не знаю
может чтобы поменьше заниматься любовью с кучей разных (используемых в применяемых библиотеках) и вместо решения инфраструктурных вопросов сконцентрироваться на непосредственно стоящей задаче
ну и боусом была бы возможность не тащить в страндартную библиотеку все модное/молодежное
смотрю направо, смотрю налево, никто никуда не бежит ))
тем более раст слишком тяжел в компиляции
я как то простенькие примеры компилял и мне очень не понравилась ни скорость компиляции, ни дисковое пространство которое уходит под весь билд
а давайте вы не будете врать и как минимум перекручивать то что я сказал ?
зы но я не Е.Музыченко, уходить дальше во флуд по этой ветке мне не интересно
я говорил что если бизнесу удобнее жить в -O0 что бы обходить УБ, то видимо им дешевле купить 100cpu и терабайты памяти что бы достичь той же производительности что и с -O3, чем нанять правильных разработчиков
или раст не использует оптимизацию ?
использует
но ресурсоемкость компилятора слишком жирновата для условного хелоуворда
что тогда говорить о серьезных проектах ?
да
Pzz>С ней есть одна проблемка: она паршиво работает в окружении с ограниченной сетевой connectivity во время сборки.
это уже детали конкретных реализаций (насколько знаю, в расте никто не мешает прописать виртуальный репозиторий)
главное они там есть, и ими можно пользоваться
Pzz>Но вот одна проблема. У меня есть опенсорсный проект, написанный на Go. Когда его включали в Убунту/Дебиан, они очень убедительно ныли, как им тяжело и неказисто иметь дело с программами с внешними зависимостями. Потому, что сборка идет на изолированных от сети виртуальных машинках. Пришлось парсер конфигурационных файлов руками переписать, чтобы не ныли. Pzz>В конторе, где я работаю, сейчас очень жесткие правила относительно втаскивания публичного опенсорса в периметр компании. Опасаются пакостей, связанных с политической ситуацией. Приходится стараться укладываться в stdlib. Мне это технически проще, чем с ИБ торговаться.
Так в чем проблема положить исходники зависимостей рядом со своим кодом?
Менеджеры пакетов Go и Rust такое точно умеют. У менеджера пактов Rust так же точно есть опция чтобы
вообще к сети не обращаться во время сборки (--offline) и использовать конкретные версии
пакетов (--locked), в Go наверное тоже подобный флаг(и) есть.
Здравствуйте, B0FEE664, Вы писали:
NB>>для какой "конкретной конфигурации"? BFE>Для той, которой ещё не существует, под ту платформу, которую ещё не выпустили. BFE>Сейчас во всём мире разных используемых библиотек наверное уже миллионы. Они что, будут все включены в ваш гипотетический менеджер? Включая все сочетания всех версий? Зачем?
Даже если в единый централизованный менеджер (вроде Cargo для Rust, Maven для Java, RubyGems для Ruby и т.д.) будет включено процентов 80 от всех существующих библиотек, то это очень сильно облегчит жизнь процентам 90 программистов (цифры с потолка, если что).
Но да, у централизованных репозиториев пакетов есть свои недостатки (может быть даже фатальные). Но ведь можно идти и по пути децентрализованного менеджмента. Т.е. есть стандартизированный формат описания зависимостей, есть инструмент, который по таким описаниям зависимости может собрать. Что-то вроде CMake-овского FetchContent.
Тут ключевой момент в том, чтобы это было стандартизовано и не было N конкурирующих между собой форматов/систем. Поскольку даже наличие vcpkg и conan уже создает лишний геморрой, т.к. с каждой из них нужно разбираться и следить за тем, куда и как они развиваются, временами адаптируясь под их новые версии. Если же таковых не две, и не три, то вообще грустно...
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Жаль. Что-ж, тогда так: сколько вы знаете людей, которые могут выполнить обновление, скажем, Ubuntu имея на руках только новые исходники? S>>Я не мейнтейнер Ubuntu, я не знаю с какими проблемами сталкиваются те, кто Ubuntu собирает и делает пакеты для нее. BFE>Хорошо. А сколько вы знаете людей, которые сами компилируют Qt, а не берут уже скомпилированные бинарники?
Когда я пользовался Qt (правда, это было давно), все компилировали его самостоятельно. Скачивали исходники и компилировали.
S>>А а вот для тех, кому нужно иметь софтину под Win/Lin на базе FFMPEG сборка этого самого FFMPEG может превратиться в изрядный квест под Windows и MSVC++. Вот для них наличие пакета для FFMPEG будет экономией на десятки человекочасов. BFE>Как предсказуемо. Об этих минусах я и пишу: создали монстра и выпихивают всех не вписавшихся. Так?
Ох, ё. Не ну правда, такой полет мысли невозможно комментировать.
S>>Это у вас нужно спросить, вы же переживали, что будут мейнстримовые библиотеки без альтернатив. Вот есть FFMPEG и SDL. Вполне себе мейнстримовые. Если кому-то эта мейнстримовость не нравится, тот может сделать собственную альтернативу. BFE>И кто её будет использовать?
Не вижу смысла класть tar.gz сторонних библиотек в git, но если вам git ближе и милее, то можно и так.
Вопрос-то в другом. Вот есть у меня библиотека X моего производства, она требует библиотек Y и Z, а мою библиотеку X захотели заиспользовать в приложении N. Пакетный менеджер позволит в описании N указать, что нужна X, а уже пакетный менеджер разберется и с Y, и с Z.
Куда он сложит tar.gz для X, Y и Z -- это технический момент.
Камнем преткновения же в C++ сейчас является то, что стандартного способа описать зависимости для N нет. Хотя есть vcpkg, conan и еще с полдюжины разных других инструментов гораздо менее известных.
S>>И встречный вопрос: если "никакой сети", то как вы системы контроля версий эксплуатируете? Вычисляете diff-ы вручную, а затем посредством дискет обмениваетесь патчами? BFE>Уточню: никакой внешней сети.
Если у вас есть локальная сеть, то зачем дурочку включать?
S>>Какую такую систему? Вы про дистрибутивы Linux-а говорите? BFE>Новое рабочее место, для нового сотрудника.
Почитайте, например, как ставится vcpkg.
S>>У меня есть ощущение, что под пакетным менеджером вы понимаете что-то вроде apt или rpm. BFE>А есть принципиальная разница?
Да. Если вы ее не видите, то познакомьтесь с инструментами вроде vcpkg или conan.
S>>Но, поскольку все это распространяется не на всю систему (читай не на весь Linux, который стоит у меня на ноутбуке), а только на проект, то решается это в рамках обычной работы над проектом. BFE>Но вы же наверное, не один работаете?
Здравствуйте, night beast, Вы писали:
BFE>>И да, зачем говорить о пакетном менеджере в рамках языка?
NB>зачем в рамках языка иметь одну стандартную библиотеку? NB>это же здорово, когда у каждого есть свои классы строк ( )
На плюсах можно писать, не используя стандартную библиотеку. На питоне можно писать, не используя стандартный пакетный менеджер? Иди уже на раст писать, не тяни каку в плюсики
Здравствуйте, B0FEE664, Вы писали:
BFE>Концепты, корутины, модули... Ерундой какой-то занимаются. Лучше бы utf-8 строки доделали! Перечисления нормальные написали. Флаги добавили, а не вот эту студенческую ерунду.
Поддерживаю, концепты — не ерунда.
--
Не можешь достичь желаемого — пожелай достигнутого.
кому невозможно ?
но вы опять не по адресу, сходите к Е.М. и подискутируйте с ним,
зачем он использует язык который не понимает и не умеет использовать правильно
BFE>Концепты, корутины, модули...
Мне представляется, что модули — самое важное из всего.
Остальное в некотором роде экзотика, хотя и крутая.
А модули — это же прям нужно-нужно.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Мне представляется, что модули — самое важное из всего. LVV>Остальное в некотором роде экзотика, хотя и крутая. LVV>А модули — это же прям нужно-нужно.
Ну вот видите, сколько людей, столько и мнений. А мне, например, те модули нафиг бы не тарахтели, зато без концептов жизнь не мила. Бытие определяет сознание — диалектика.
--
Не можешь достичь желаемого — пожелай достигнутого.
NB>>>да уже сколько лет просим, дайте нормальную билд систему с пакетным менеджером. LVV>>Самим написать? NB>чтобы иметь n+1 ?
Автомобили же делают. И самолеты...
Зато это будет именно то, что ВАМ нужно.
А если сделать опенсорс, то, возможно, и другим тоже понравится.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, so5team, Вы писали:
S>Даже если в единый централизованный менеджер (вроде Cargo для Rust, Maven для Java, RubyGems для Ruby и т.д.) будет включено процентов 80 от всех существующих библиотек, то это очень сильно облегчит жизнь процентам 90 программистов (цифры с потолка, если что).
Или, наоборот, усложнит: если есть что-то майнстримовое, то обычный менеджмент будет решать только его и использовать. С одной стороны это приведёт к использованию обобщенных, не адаптированных к задаче решений, а значит тяжёлых, ухудшающих скорость приложений, с другой стороны это приведёт к обеднению разнообразия библиотек, так как не попавшие в центральный репозиторий не будут использоваться, а значит и поддерживаться.
S>Но да, у централизованных репозиториев пакетов есть свои недостатки (может быть даже фатальные). Но ведь можно идти и по пути децентрализованного менеджмента. Т.е. есть стандартизированный формат описания зависимостей, есть инструмент, который по таким описаниям зависимости может собрать. Что-то вроде CMake-овского FetchContent.
Откуда будут браться эти "зависимости"? Из сети? Т.е. всё будет держаться исключительно на доверии неизвестно кому?
S>Тут ключевой момент в том, чтобы это было стандартизовано и не было N конкурирующих между собой форматов/систем. Поскольку даже наличие vcpkg и conan уже создает лишний геморрой, т.к. с каждой из них нужно разбираться и следить за тем, куда и как они развиваются, временами адаптируясь под их новые версии. Если же таковых не две, и не три, то вообще грустно...
По моему опыту всеми такими пакетными менеджарами пользуются только недавно бывшими студентами программисты, а все кто хоть сколько-то поработал в промышленных масштабах понимает, что всё эти пакетные менеджеры хороши только если у разработчика есть их полный контроль: когда хранение и изменение пакетов полностью локально (без сети) контролируется разработчиками.
Здравствуйте, night beast, Вы писали:
NB>не выпустили и ладно, в чем проблема собрать из исходников?
Из исходников? А у вас больше не будет исходников — только пакеты и модули. Зачем вам разрушать экологию: тратить время и энергию на уже скомпилированные и подготовленные пакеты?
BFE>>Сейчас во всём мире разных используемых библиотек наверное уже миллионы. Они что, будут все включены в ваш гипотетический менеджер? Включая все сочетания всех версий? Зачем? NB>не знаю
Вот и я не могу понять — зачем?
NB>зачем тебе все сочетания всех версий?
Очевидно не все версии со всеми другими версиями будут компилироваться.
NB>все что надо должно, как обычно, собираться на машине разработчика.
Свежо предание, да верится с трудом.
Здравствуйте, B0FEE664, Вы писали:
S>>Даже если в единый централизованный менеджер (вроде Cargo для Rust, Maven для Java, RubyGems для Ruby и т.д.) будет включено процентов 80 от всех существующих библиотек, то это очень сильно облегчит жизнь процентам 90 программистов (цифры с потолка, если что). BFE>Или, наоборот, усложнит: если есть что-то майнстримовое, то обычный менеджмент будет решать только его и использовать. С одной стороны это приведёт к использованию обобщенных, не адаптированных к задаче решений, а значит тяжёлых, ухудшающих скорость приложений, с другой стороны это приведёт к обеднению разнообразия библиотек, так как не попавшие в центральный репозиторий не будут использоваться, а значит и поддерживаться.
Э... Выглядит как какой-то поток сознания.
Есть вещи, вроде FFMPEG, OpenSSL, SDL, Dear ImGUI и т.д., и т.п. Когда они доступны из пакетного менеджера и легко подключаются к приложению вне зависимости от платформы, то это огромный плюс.
Если же кому-то хочется самому вручную написать аналог FFMPEG или SDL, то флаг в руки и барабан на шею. Может быть даже и получится что-то когда-нибудь.
BFE>Откуда будут браться эти "зависимости"? Из сети? Т.е. всё будет держаться исключительно на доверии неизвестно кому?
А это уже требования к инструменту. По хорошему, должны поддерживаться и архивы из сети (с принудительной проверкой контрольной суммы по необходимости). И должна быть возможность "перекрыть" расположение зависимости, чтобы вместо github.com/vasyapupkin/superlib/archive/v13.0.2.tar.gz подхватывалось roga-i-koputa.ru/internal/mirror/superlib/v13.0.2.tar.gz.
В этом нет ничего из ряда вон. Вроде как в том же vcpkg есть механизм overlay-ев и registries для подобных целей.
BFE>По моему опыту
Теперь все должны жить опираясь только на ваш опыт?
Здравствуйте, night beast, Вы писали:
NB>давай ты не будешь фантазировать, а просто посмотришь, как сделано в "убогом питоне" (у которого в пакетах, внезапно, что-то делают либы с исходниками на сях и других языках)
Язык у которого нет стандарта — убогий язык. И да, зачем говорить о пакетном менеджере в рамках языка?
Здравствуйте, B0FEE664, Вы писали:
S>>Э... Выглядит как какой-то поток сознания. BFE>Жаль. Что-ж, тогда так: сколько вы знаете людей, которые могут выполнить обновление, скажем, Ubuntu имея на руках только новые исходники?
Я не мейнтейнер Ubuntu, я не знаю с какими проблемами сталкиваются те, кто Ubuntu собирает и делает пакеты для нее.
S>>Есть вещи, вроде FFMPEG, OpenSSL, SDL, Dear ImGUI и т.д., и т.п. Когда они доступны из пакетного менеджера и легко подключаются к приложению вне зависимости от платформы, то это огромный плюс. BFE>В чём плюс, если я их не использую?
Для вас здесь вообще все индеферентно.
А а вот для тех, кому нужно иметь софтину под Win/Lin на базе FFMPEG сборка этого самого FFMPEG может превратиться в изрядный квест под Windows и MSVC++. Вот для них наличие пакета для FFMPEG будет экономией на десятки человекочасов.
S>>Если же кому-то хочется самому вручную написать аналог FFMPEG или SDL, то флаг в руки и барабан на шею. Может быть даже и получится что-то когда-нибудь. BFE>Какая связь пакетного менеджера и написания библиотеки вручную?
Это у вас нужно спросить, вы же переживали, что будут мейнстримовые библиотеки без альтернатив. Вот есть FFMPEG и SDL. Вполне себе мейнстримовые. Если кому-то эта мейнстримовость не нравится, тот может сделать собственную альтернативу.
BFE>>>Откуда будут браться эти "зависимости"? Из сети? Т.е. всё будет держаться исключительно на доверии неизвестно кому? S>>А это уже требования к инструменту. По хорошему, должны поддерживаться и архивы из сети (с принудительной проверкой контрольной суммы по необходимости). И должна быть возможность "перекрыть" расположение зависимости, чтобы вместо github.com/vasyapupkin/superlib/archive/v13.0.2.tar.gz подхватывалось roga-i-koputa.ru/internal/mirror/superlib/v13.0.2.tar.gz. BFE>Ну ок: если требования "никакой сети", тогда как?
И встречный вопрос: если "никакой сети", то как вы системы контроля версий эксплуатируете? Вычисляете diff-ы вручную, а затем посредством дискет обмениваетесь патчами?
S>>В этом нет ничего из ряда вон. Вроде как в том же vcpkg есть механизм overlay-ев и registries для подобных целей. BFE>Для каких целей? Вот вы взяли библиотеку, прочили её, убедились, что качество устраивает и количество ошибок не велико. Используете её.
Пока понятно.
BFE>И тут вам надо установить новую систему
Какую такую систему? Вы про дистрибутивы Linux-а говорите?
BFE>>>По моему опыту S>>Теперь все должны жить опираясь только на ваш опыт? BFE>Теперь вы можете поделиться своим опытом: рассказать, например, бывали ли так, что пакетный менеджер устанавливал пакеты не совместимые с вашей версией продукта?
У меня есть ощущение, что под пакетным менеджером вы понимаете что-то вроде apt или rpm.
BFE>Бывало ли так, что из-за сетевых проблем пакетный менеджер не работал?
Нет.
BFE>Бывало ли такое, что работа пакетного менеджера занимала несколько часов?
Да.
BFE>Бывало ли такое, что обновление пакета приводила к нарушением в работе продукта?
Да, обновляешь версию зависимости, а там либо что-то убрали/поменяли, либо баг какой-то обнаружился.
Но, поскольку все это распространяется не на всю систему (читай не на весь Linux, который стоит у меня на ноутбуке), а только на проект, то решается это в рамках обычной работы над проектом.
Здравствуйте, so5team, Вы писали:
S>Вопрос-то в другом. Вот есть у меня библиотека X моего производства, она требует библиотек Y и Z, а мою библиотеку X захотели заиспользовать в приложении N. Пакетный менеджер позволит в описании N указать, что нужна X, а уже пакетный менеджер разберется и с Y, и с Z.
здесь еще важный момент в том, что в зависимостях прописываются версии, с которыми работает библиотека.
LVV>>Зато это будет именно то, что ВАМ нужно. NB>ты вроде на Го пишешь? NB>тут в соседнем сообщении Pzz говорил что у стандартной системы есть некоторые недостатки. NB>нет желания переписать? народ обязательно (нет) перейдет на твою, ручаюсь.
Мне — не нужно.
А вам — нужно. В этом разница...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Это не может быть стандартизировано. NB>https://go.dev/ref/mod
В Го — да. Ибо с самого начала.
А в С++ народ слишком свободомыслящий...
Кстати, возможно, с введением модулей что-то сдвинется в этом плане.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, night beast, Вы писали:
NB>давай ты не будешь фантазировать, а просто посмотришь, как сделано в "убогом питоне" (у которого в пакетах, внезапно, что-то делают либы с исходниками на сях и других языках)
Это там, где минорные изменения какого-то левого пакета всё нахрен ломают, причем в неожиданных местах в рантайме?
и да делайте ударение на том что бы в поддержку модулей доделали в компиляторах для буилд систем
ps не надо мне рассказывать что там да как и почти поддерживается
я держу руку на пульсе и в курсе
но в шланге например еще не допили некоторые вкусности
ну почему же
думаю комитет пытается держать руку на пульсе что бы понимать а туда ли они в целом идут
когда последний раз было, много активно проголосовал за нетворкинг в стандарте
и даже по моему саттер отдельно делал еще доп голосование
и по итогу увидел что народ таки хочет нетворкинг
и они что то типа полу официально сказал что, нетворкнг не получиться впихнуть — не готово
сейчас мне уже не хочется того нетворкинга который они там куралесят
пусть хотя бы паттерн матчинг добавят
а там может и експектед в более человеческий вид преобразуется
Здравствуйте, reversecode, Вы писали:
R>я как то простенькие примеры компилял и мне очень не понравилась ни скорость компиляции, ни дисковое пространство которое уходит под весь билд
Ты ж сам говорил, 100 CPU не проблема. Вот, разработчики растовского компилятора к тебе и прислушались.
Здравствуйте, night beast, Вы писали:
NB>это уже детали конкретных реализаций (насколько знаю, в расте никто не мешает прописать виртуальный репозиторий) NB>главное они там есть, и ими можно пользоваться
Мне очень нравится, как в Go сделана работа с внешними репами (насколько я понимаю, в расте она сделана примерно так же).
Но вот одна проблема. У меня есть опенсорсный проект, написанный на Go. Когда его включали в Убунту/Дебиан, они очень убедительно ныли, как им тяжело и неказисто иметь дело с программами с внешними зависимостями. Потому, что сборка идет на изолированных от сети виртуальных машинках. Пришлось парсер конфигурационных файлов руками переписать, чтобы не ныли.
В конторе, где я работаю, сейчас очень жесткие правила относительно втаскивания публичного опенсорса в периметр компании. Опасаются пакостей, связанных с политической ситуацией. Приходится стараться укладываться в stdlib. Мне это технически проще, чем с ИБ торговаться.
В общем, есть у этой системы не только свои достоинства, но и свои недостатки.
Здравствуйте, Pzz, Вы писали:
Pzz>В конторе, где я работаю, сейчас очень жесткие правила относительно втаскивания публичного опенсорса в периметр компании. Опасаются пакостей, связанных с политической ситуацией. Приходится стараться укладываться в stdlib. Мне это технически проще, чем с ИБ торговаться.
даже в таких условиях ничто не мешает этой конторе разрабатывать независимые друг от друга компоненты (с блекджеком) и включать их в проект стандартным образом.
я с го не работал, но сильно сомневаюсь, что там нельзя подтягивать внешние зависимости не из сети, а локально.
Pzz>В общем, есть у этой системы не только свои достоинства, но и свои недостатки.
это не недостатки системы. это недостатки конкретных реализаций.
и если этот вопрос встанет остро, его довольно быстро решат.
но, как я понял, у тебя уже есть некоторый опыт работы системой пакетирования.
на основании его скажи свое мнение, нужно ли оно в с++, или нет.
Здравствуйте, LaptevVV, Вы писали:
NB>>чтобы иметь n+1 ? LVV>Автомобили же делают. И самолеты... LVV>Зато это будет именно то, что ВАМ нужно.
ты вроде на Го пишешь?
тут в соседнем сообщении Pzz говорил что у стандартной системы есть некоторые недостатки.
нет желания переписать? народ обязательно (нет) перейдет на твою, ручаюсь.
Здравствуйте, night beast, Вы писали:
NB>но, как я понял, у тебя уже есть некоторый опыт работы системой пакетирования. NB>на основании его скажи свое мнение, нужно ли оно в с++, или нет.
Я считаю, что основная проблема c++ в том, что в него втащили вообще все, что есть где-нибудь еще. Поэтому нет, не нужна, и сам c++ не нужен. Его не исправишь, добавляя новые функции.
Здравствуйте, night beast, Вы писали:
NB>>>да уже сколько лет просим, дайте нормальную билд систему с пакетным менеджером. BFE>>Зачем это нужно? NB>зачем это нужно питону, расту и многим другим языкам? не знаю
Вот мне тоже это не известно. Могу предположить, что питон настолько убогий, что без этого просто не может, а что до остальных —
NB>может чтобы поменьше заниматься любовью с кучей разных (используемых в применяемых библиотеках) и вместо решения инфраструктурных вопросов сконцентрироваться на непосредственно стоящей задаче NB>ну и боусом была бы возможность не тащить в страндартную библиотеку все модное/молодежное
Т.е. если для конкретной конфигурации нет пакетного менеджера, то всё — "приплыли"?
Здравствуйте, B0FEE664, Вы писали:
NB>>зачем это нужно питону, расту и многим другим языкам? не знаю BFE>Вот мне тоже это не известно. Могу предположить, что питон настолько убогий, что без этого просто не может, а что до остальных —
да тоже убогие, чего уж там скромничать
NB>>ну и боусом была бы возможность не тащить в страндартную библиотеку все модное/молодежное BFE>Т.е. если для конкретной конфигурации нет пакетного менеджера, то всё — "приплыли"?
Здравствуйте, night beast, Вы писали:
NB>да тоже убогие, чего уж там скромничать
Вы сказали.
NB>для какой "конкретной конфигурации"?
Для той, которой ещё не существует, под ту платформу, которую ещё не выпустили.
Сейчас во всём мире разных используемых библиотек наверное уже миллионы. Они что, будут все включены в ваш гипотетический менеджер? Включая все сочетания всех версий? Зачем?
Здравствуйте, B0FEE664, Вы писали:
NB>>да тоже убогие, чего уж там скромничать BFE>Вы сказали.
ах да, забыл табличку
NB>>для какой "конкретной конфигурации"? BFE>Для той, которой ещё не существует, под ту платформу, которую ещё не выпустили.
не выпустили и ладно, в чем проблема собрать из исходников?
BFE>Сейчас во всём мире разных используемых библиотек наверное уже миллионы. Они что, будут все включены в ваш гипотетический менеджер? Включая все сочетания всех версий? Зачем?
не знаю
зачем тебе все сочетания всех версий?
все что надо должно, как обычно, собираться на машине разработчика.
Здравствуйте, B0FEE664, Вы писали:
NB>>не выпустили и ладно, в чем проблема собрать из исходников? BFE>Из исходников? А у вас больше не будет исходников — только пакеты и модули. Зачем вам разрушать экологию: тратить время и энергию на уже скомпилированные и подготовленные пакеты?
BFE>Вот и я не могу понять — зачем?
NB>>все что надо должно, как обычно, собираться на машине разработчика. BFE>Свежо предание, да верится с трудом.
давай ты не будешь фантазировать, а просто посмотришь, как сделано в "убогом питоне" (у которого в пакетах, внезапно, что-то делают либы с исходниками на сях и других языках)
Здравствуйте, so5team, Вы писали:
S>Э... Выглядит как какой-то поток сознания.
Жаль. Что-ж, тогда так: сколько вы знаете людей, которые могут выполнить обновление, скажем, Ubuntu имея на руках только новые исходники?
S>Есть вещи, вроде FFMPEG, OpenSSL, SDL, Dear ImGUI и т.д., и т.п. Когда они доступны из пакетного менеджера и легко подключаются к приложению вне зависимости от платформы, то это огромный плюс.
В чём плюс, если я их не использую?
S>Если же кому-то хочется самому вручную написать аналог FFMPEG или SDL, то флаг в руки и барабан на шею. Может быть даже и получится что-то когда-нибудь.
Какая связь пакетного менеджера и написания библиотеки вручную?
BFE>>Откуда будут браться эти "зависимости"? Из сети? Т.е. всё будет держаться исключительно на доверии неизвестно кому? S>А это уже требования к инструменту. По хорошему, должны поддерживаться и архивы из сети (с принудительной проверкой контрольной суммы по необходимости). И должна быть возможность "перекрыть" расположение зависимости, чтобы вместо github.com/vasyapupkin/superlib/archive/v13.0.2.tar.gz подхватывалось roga-i-koputa.ru/internal/mirror/superlib/v13.0.2.tar.gz.
Ну ок: если требования "никакой сети", тогда как?
S>В этом нет ничего из ряда вон. Вроде как в том же vcpkg есть механизм overlay-ев и registries для подобных целей.
Для каких целей? Вот вы взяли библиотеку, прочили её, убедились, что качество устраивает и количество ошибок не велико. Используете её. И тут вам надо установить новую систему с точной той библиотекой, которую вы уже проверили. Как это сделать?
BFE>>По моему опыту S>Теперь все должны жить опираясь только на ваш опыт?
Теперь вы можете поделиться своим опытом: рассказать, например, бывали ли так, что пакетный менеджер устанавливал пакеты не совместимые с вашей версией продукта? Бывало ли так, что из-за сетевых проблем пакетный менеджер не работал? Бывало ли такое, что работа пакетного менеджера занимала несколько часов? Бывало ли такое, что обновление пакета приводила к нарушением в работе продукта?
Здравствуйте, night beast, Вы писали:
BFE>>И да, зачем говорить о пакетном менеджере в рамках языка? NB>зачем в рамках языка иметь одну стандартную библиотеку?
Для унификации.
NB>это же здорово, когда у каждого есть свои классы строк ( )
В общем-то — да, здорово, тем более что в стандартной библиотеке так и нет нормальных юникодных строк.
Видите ли, библиотека — она выражена в терминах языка, а вот пакетный менеджер может не знать о языке ничего. Или я чего-то не понимаю или пакетный менеджер работает не с языком, а с файлами. Почему бы пакетному менеджеру не работать сразу с несколькими языками?
Здравствуйте, so5team, Вы писали:
S>>>Э... Выглядит как какой-то поток сознания. BFE>>Жаль. Что-ж, тогда так: сколько вы знаете людей, которые могут выполнить обновление, скажем, Ubuntu имея на руках только новые исходники? S>Я не мейнтейнер Ubuntu, я не знаю с какими проблемами сталкиваются те, кто Ubuntu собирает и делает пакеты для нее.
Хорошо. А сколько вы знаете людей, которые сами компилируют Qt, а не берут уже скомпилированные бинарники?
S>А а вот для тех, кому нужно иметь софтину под Win/Lin на базе FFMPEG сборка этого самого FFMPEG может превратиться в изрядный квест под Windows и MSVC++. Вот для них наличие пакета для FFMPEG будет экономией на десятки человекочасов.
Как предсказуемо. Об этих минусах я и пишу: создали монстра и выпихивают всех не вписавшихся. Так?
S>Это у вас нужно спросить, вы же переживали, что будут мейнстримовые библиотеки без альтернатив. Вот есть FFMPEG и SDL. Вполне себе мейнстримовые. Если кому-то эта мейнстримовость не нравится, тот может сделать собственную альтернативу.
И кто её будет использовать?
S>Либо http://localhost/corporate-repository-copy/superlib/v13.0.2.tar.gz или даже file:///usr/shared/corporate-repository-copy/superlib/v13.0.2.tar.gz
А не проще всё в git положить?
S>И встречный вопрос: если "никакой сети", то как вы системы контроля версий эксплуатируете? Вычисляете diff-ы вручную, а затем посредством дискет обмениваетесь патчами?
Уточню: никакой внешней сети.
S>>>В этом нет ничего из ряда вон. Вроде как в том же vcpkg есть механизм overlay-ев и registries для подобных целей. BFE>>Для каких целей? Вот вы взяли библиотеку, прочили её, убедились, что качество устраивает и количество ошибок не велико. Используете её. S>Пока понятно. BFE>>И тут вам надо установить новую систему S>Какую такую систему? Вы про дистрибутивы Linux-а говорите?
Новое рабочее место, для нового сотрудника.
S>У меня есть ощущение, что под пакетным менеджером вы понимаете что-то вроде apt или rpm.
А есть принципиальная разница?
S>Но, поскольку все это распространяется не на всю систему (читай не на весь Linux, который стоит у меня на ноутбуке), а только на проект, то решается это в рамках обычной работы над проектом.
Но вы же наверное, не один работаете?
Здравствуйте, B0FEE664, Вы писали:
BFE>>>И да, зачем говорить о пакетном менеджере в рамках языка? NB>>зачем в рамках языка иметь одну стандартную библиотеку? BFE>Для унификации.
вот и ответ на твой вопрос.
BFE>Видите ли, библиотека — она выражена в терминах языка, а вот пакетный менеджер может не знать о языке ничего. Или я чего-то не понимаю или пакетный менеджер работает не с языком, а с файлами.
я не знаю, должен ли пакетный менеджер знать что-то о языке или нет, только почему-то никто не применяет npm для разруливания зависимостей плюсовых библиотек. по крайней мере, мне о таких случаях не известно.
такая вот наблюдаемая действительность.
BFE>Почему бы пакетному менеджеру не работать сразу с несколькими языками?
давай его научим нормально работать с одним, а уже потом и на другие будем смотреть.
Здравствуйте, night beast, Вы писали:
S>>Вопрос-то в другом. Вот есть у меня библиотека X моего производства, она требует библиотек Y и Z, а мою библиотеку X захотели заиспользовать в приложении N. Пакетный менеджер позволит в описании N указать, что нужна X, а уже пакетный менеджер разберется и с Y, и с Z.
NB>здесь еще важный момент в том, что в зависимостях прописываются версии, с которыми работает библиотека.
LVV>>Мне — не нужно. LVV>>А вам — нужно. В этом разница... NB>нам нужно чтобы это было стандартизировано, а не чтобы где-то появилась новая реализация NB>этом разница...
Это не может быть стандартизировано.
Это как СУБД.
Выбираете из того, что есть, или пишете сами.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, so5team, Вы писали:
S>Когда я пользовался Qt (правда, это было давно), все компилировали его самостоятельно. Скачивали исходники и компилировали.
Это было видимо очень давно, я с середины нулевых периодически используют Qt, и ни разу не заморачивался с его сборкой
Здравствуйте, Marty, Вы писали:
S>>Когда я пользовался Qt (правда, это было давно), все компилировали его самостоятельно. Скачивали исходники и компилировали.
M>Это было видимо очень давно, я с середины нулевых периодически используют Qt, и ни разу не заморачивался с его сборкой
Это был период где-то с 2004-го по 2008-ой. ЕМНИП, в 2004-ом Qt3 под Windows бесплатно можно было взять только в бинарниках, а вот уже полная платная версия собиралась на машине пользователя из исходников. Может тогда и были бинарники, не помню, но у нас Qt3 компилировалась под VisualStudio 2003 с некоторыми дополнительными "галочками", вроде интеграции Qt и STL.
Здравствуйте, so5team, Вы писали:
S>Почитайте, например, как ставится vcpkg.
Ну почитал:
To get and use vcpkg, you first must build it. This is as simple as:
Clone vcpkg from its GitHub repository.
In a command line or terminal window:
cd to the root directory for vcpkg.
run one of the following based on your OS:
bootstrap-vcpkg.bat on Windows
bootstrap-vcpkg.sh on Linux or MacOS.
Из этого следует, что установленная версия может быть несовместима с использованными на других рабочих местах.
S>>>У меня есть ощущение, что под пакетным менеджером вы понимаете что-то вроде apt или rpm. BFE>>А есть принципиальная разница? S>Да. Если вы ее не видите, то познакомьтесь с инструментами вроде vcpkg или conan.
Почитал, как используется vcpkg, принципиальной разницы с apt не вижу.
Более того, пока что использование vcpkg для меня выглядит удручающе. Если вам не важно качество используемых библиотек, а делаете вы какой-нибудь учебный проект, то да, удобно, а вот использовать в работе такое странно.
Так в чём принципиальная разница между apt и vcpkg?
Здравствуйте, B0FEE664, Вы писали:
BFE>Из этого следует, что установленная версия может быть несовместима с использованными на других рабочих местах.
В vcpkg есть управление версиями зависимостей. Если вы для своего проекта создали vcpkg.json и в нем указали конкретный baseline, то даже если на разных машинах будет отличающиеся версии vcpkg, к своему проекту вы подтянете именно те зависимости, что вам нужно. Или наткнетесь на ситуацию, когда у кого-то сильно древний vcpkg и там просто такого значения для baseline нет. В этом случае просто обновляете vcpkg.
BFE>Почитал, как используется vcpkg, принципиальной разницы с apt не вижу.
У вас может быть отдельный apt на каждый проект?
BFE>Более того, пока что использование vcpkg для меня выглядит удручающе.
А "Карузо не такой уж и великий певец" (с).
BFE>Так в чём принципиальная разница между apt и vcpkg?
Здравствуйте, reversecode, Вы писали:
R>смотрю направо, смотрю налево, никто никуда не бежит )) R>тем более раст слишком тяжел в компиляции R>я как то простенькие примеры компилял и мне очень не понравилась ни скорость компиляции, ни дисковое пространство которое уходит под весь билд
Что значил тяжел в компиляции? Первая сборка разве что. А потом все очень быстро
cpu, time, diskusage
я игрался с tokio
спустя несколько месяцев полез перебилдить
эта хня натянула рядом с уже одними версиями всех всех либ депенд
новых версий тех же либ вместо того что бы их обновить хотя бы
в итоге вышел винигрет в какой то там директории куда оно их сложило
и что бы удалить старое нужно все грохнуть ~1гиг помоему
и пересобрать еще раз
Здравствуйте, so5team, Вы писали:
S>Результаты опроса
Результаты более-менее логичны. Вызывает безпокойство, что процент использующих С++ в школе <10% и процент людей с 1-2 годами опыта <5%. Это значит, что новичков в С++ мало, и скоро популярность С++ пойдёт на спад.
)
