Здравствуйте, Sinclair, Вы писали:

V>>(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)
S>Ресолвинг — это и есть восстановление.

Нифига.
Ресолвинг в С++ — это поиск и конфигурирование путей к заголовкам и библиотекам.


S>Если зависимость — от .obj, для которого есть исходник, то ресолвинг — это компиляция.

И на марсе уже 20 лет существуют людские колонии.
Слушай, мне реально порой нравится нравится тобой произносимое, бо у тебя хватает смелости озвучивать то, о чём другие лишь только скромно думают...
Но совесть-то тоже надо иметь, перегибать-то не надо... ))


S>Если от .lib — то линковка. Если он внешнего пакета, то ресолвинг — это скачивание пакета.
S>По-прежнему ждём

Ты даже не представляешь, сколько всего мы ждём.
Но это всё бесплатное-опенсорсное.
Если ты или я это не сделаем — никто не сделает.
По крайней мере в ближайшие месяцы/годы/десятилетия.
А лично мне реально некогда...
Для меня эта задача, положа рукe на — тьфу, за полтора года успею примерно такое:
— сделаю первую версию
— получу по мозгам критику отовсюду, исправлю/доработаю
— потом опять добавлю/исправлю, к 3-й версии всё будет более-менее.

Через полтора года ты сможешь хвастаться всем этим...
И буквально малюсенький вопрос стоит — кто мне будет ЗП платить за этот период? ))


V>>В которых куча поддиректорий в поддиректории build, например.
S>Вот это всё — какие-то семидесятые.

Отнюдь.
Чем дальше, тем больше поддиректорий в поддиректории build.


V>>Это если разработчик предусмотрел какие-нить requirements.txt.
S>а если нет, то можно запустить pipreqs.

С вероятностью успеха примерно 50%.


V>>В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.
S>Для всех? Или для кого-то одного?

Для каждой сборки Linux свой файл.
Спасает то, что многие сборки являются как бы ответвлениями от "материнкой" сборки.
Например, чуть ли не половина сборок базируются на DEB-Linux.


V>>Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
S>То есть, всё же устанавливаются.

Откуда именно?


V>>Но не сложилось единого мирового реестра.
S>Речь не о единости реестра, а о штатном способе инсталляции зависимостей — в том числе и внутри build pipeline.

Этого в Джава нет.
Хотя я понимаю и унутре всячески сочувствую твоему представлению о прекрасном.


S>Как видим, в С++ ничего похожего нет — каждый дрочит как он хочет. Кто-то через nuget, кто-то через apt, кто-то через yum, кто-то просто через externals.

С++ тут не при чём, это заморочки платформенного уровня.


V>>Просто для поржать — вот дефолотный "центральный" репозиторий:
V>>https://repo.maven.apache.org/maven2/
V>>Пролистай до конца.
V>>Это всё.
S>Берём первый попавшийся Java проект на гитхабе: https://github.com/Anuken/Mindustry
S>Все зависимости качаются (если нужно) в процессе билда. Всё делается одной командой.

Не-не-не.
Никакой "одной командой", и никаких "в процессе билда".
Это разработчики либы нехило озаботились впендюрить такую функциональность.
Но "стандартной" такой нет.

А так-то, если поднапрячься, то в любой технологии можно впендюрить подобное.
Будет ли это что-то доказывать? — да аж ничего.
Незначительные флуктуации вакуума...


S>Берём первый попавшийся С++ проект на гитхабе. Читаем раздел Integration, впечатляемся.

Была бы у тебя совесть, ты бы точно так же подобрал наоборот.


V>>Да понятно, что ответить тебе нечего.
S>Понятно, что С++ по-прежнему фокусируется на особенностях языка, забивая на тулчейн.

Рехнулся?
Вроде был адекватным несколько постов?

При чём тут "особенности языка"?
Речь о зависимостях.

Проблема в том, что разные сборки линуха даже имеют разные АПИ уровня ОС.
Ну вот собирают даже ядро с разными флагами.
А потом ставят низкоуровневые либы, собранные с разными опциями.

В итоге, С++ проектам приходится уметь собираться в зоопарке архитектур, где отличия — по кол-ву поддерживаемой функциональности.
Ты эта... посмотрел бы хоть раз на какой-нить Config.h, который конфигурируется целью make configure.
Там будет полторы-две сотни макроопределений навроде #PLATFORM_HAS_EVENTFD 1

В исходниках затем ветвление на макропроцессоре: есть в АПИ ОС eventfd — пользуем, нет — эмулируем на пайпах и регистре-защёлке.


S>"нам не нужны модули, достаточно текстового препроцессора для инклуда хидеров". "Нам не нужен ABI, пусть он остаётся платформенно- и компиляторо-зависимым". Повторное использование в С++ просто имеет самый низкий приоритет. Какая-нибудь убогая нода с самого начала проектировалась для повторного использования, поэтому там из коробки менеджер пакетов.

Поэтому она тормозит.
Ты реально решил вот прямо сейчас повторять мантры религии из 2005-го?
Серьёзно? ))

Ну если нет в АПИ ОС eventfd, то никакие твои причитания на форумах это не изменят, не понимаешь, что ле? ))
Любой чирикающий попугай, который попробует нести чушь на эту тему, автоматически приравнивается к тупой домохозяйке, которой нечего делать в подобных обсуждениях.
Как грится, идите лучше накрутите бигуди, а взрослых дядек от работы отвлекать не надо.
И без вас хлопот хватает...


S>Мейнстримом ноды является "я возьму 99% готового кода, добавлю в него немножко клея и специфической логики, и у меня получится редистрибьютабл приложение".

Менйстрим ноды сделан плюсовиками, вроде меня.
Потому что Node.js — это насквозь нейтивная технология, и добавлять туда либы — это надо уметь, это надо понимать, как устроены JS-объекты, как нужно с ними общаться, чтобы не потекла память или не произошёл проход по памяти и т.д.
В общем, это не для средних умов технология, что касается добавления туда библиотек, основные которые являются обёртками над хорошо известными C/C++ библиотеками.

С другой стороны — ничего нового, под Lua была примерно та же история...


S>Мейнстримом С++ является "я напишу мой личный код на моей личной машине и скомпилирую под неё же, чтобы запускать его прямо здесь". Все желающие собирать код на машине X так, чтобы он использовался на машине Y — экстремалы.

Судя по описанию — это драйвер.
Что не так? ))
Ты примерно представляешь, что есть драйвер, или ты та самая обезъянка, которой такие как я должны делать либы для nodfe.js?


S>Все желающие писать код на машине X, чтобы его использовали при сборке на машине Y для исполнения на машине Z — ещё большие экстремалы, и должны страдать.

Поплачь, поплачь.
Вызови сочувствие у читателей...

А это... как его... ты сайтом не ошибся, случаем?
Домохозяйки тусуются не здесь.


V>>Скорее всего потому, что на тот момент ты не пользовался той функциональностью, про которую спрашиваешь сейчас.
V>>А она тогда была реализована через packages-config.
V>>И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.
S>Это непринципиальное улучшение.

Хрен там, это именно то, о чём ты спрашивал.
Т.е., относительно недавняя функциональность.
И твой вопрос выдал тебя с головой — ты никогда не конфигурировал проекты с большим кол-вом зависимостей.
Потому что на момент хождения VS2015 или первых версий VS2017 в наличии была такая функциональность, которая не позволила бы задавать вопросы так, как ты задал.
Ты бы сидел молча и не отсвечивал. ))


S>Управление пакетами было и до этого; то, что в msbuild не было автоматического restore, легко лечилось пребилд степом.

Ой нубство...
Что угодно можно вылечить чем угодно.
Только это всегда закат солнца вручную.
MS Build однажды предложил автоматизацию.

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


S>Ведь в С++ вы и сейчас предлагаете использовать packages.config, не так ли

Но ты же им пользовался до VS 2017 SP2?
Не умер?

И нода же пользуется отдельным файлом зависимостей?
И питон?
А почему С+ нельзя?


V>>До этого пакетный менеджер жил отдельно от системы сборки, как оно есть в node.js, питоне и т.д., где для восстановления зависимостей необходимо ручками пинать пакетный менеджер.
S>Можно ручками.

Не можно, а нужно, т.к. другого пути нет.


S>А можно — изнутри сборочного скрипта.

Пошла демагогия.
Или, таки, нубство?
Ты всерьёз считаешь, что для сборки С++ запрещено писать сборочные скрипты? ))

У меня такое сложилось ощущение, что ты пока не определился, что именно ты пытаешься доказать.
Судя по всполохам мыслей — чисто потрындеть ни о чём.


S>А можно, как в С++ — иметь рулоны инструкций про то, как собирать чудо на каждой из платформ.

С++ не обязывает тебя к этому — пиши такие же скрипты.
Собсно, в большинстве С++ проектов есть готовые скрипты примерно под десяток платформ или больше.
Но соберу проект и без них под любую платформу.
Потому что хорошо работающий код бесценнен, а потраченное время нуба на "а как собрать этот проект???" ничего не стоит.
Не умеешь — потерялся и не раздражаешь.
Идёшь семечками торговать.


V>>Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
V>>(по крайней мере в мейнстриме)
S>maven?

Не имеет центарльного реестра, поэтомуне работает в ситуации, когда ты форкнул проект с github.


S>Можно посмотреть на то, как устроены GitHub actions для java, С#, node.js проектов.
S>А можно — на C++. Разница будет видна невооружённым взглядом.

Потому что детсад и то и другое.
Открой для себя TeamCity.

Вот нафига С++ разработчикам технологии из середины нулевых?
Тебя устраивает — твой выбор.
Меня нет, бо это для дохозяек и прочего стада обезьянок.
Для обезъянок в любом случае 300-400 тыс р потолок, даже для самых грамотных из них, поэтому они могут рассыпаться в филосовствовании сколько угодно.
Их выслушают, улыбнутся, и забудут о них через минуту.
Мало ли кто там жужжит, стукаясь о стекло, не понимая, что это всего лишь стекло?
Форточка рядом...


V>>Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
V>>И это верно не только для C++, ес-но.
S>Отлично. То есть для кросс-платформенной сборки, мне нужно поддерживать 100500 "файлов с зависимостями".

На практике 5 платформ: DEB, RPM, Pacman, Zypper, Nuget.
Остальное экзотика.
И даже экзотики вряд ли наберётся более 10 вариантов к перечисленному.


S>И то, что мой проект собирается на голой винде, не означает, что он же соберётся на убунту.

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


S>Я всё правильно понял?

Конечно, конечно.
Поиграй пока, а через пол-часа тебя позовут кушать манную кашу.


V>>Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
V>>И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
S>Ну, то есть в С++ забит болт на вопросы сборки и дистрибуции

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


S>поэтому имеем вот этот вот зоопарк и геморрой на ровном месте.

Опять нет.
Весь этот миллион кода не спроста по-разному сконфигурирован.
А по банальной причине — универсального ответа на любой вопрос нет.


S>Просто комитету неважно, насколько легко повторно использовать написанный на С++ код.

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


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

Это потому что сама Windows не имеет.
Отсылаю твои претензии к MS.


S>Можно сколько угодно кивать на тёмное прошлое C# и других языков, но по факту получается так, что С++ на поколение отстаёт от "языков для нубов".

И как же оно отстаёт, если использует тот же NuGet?
А как, по-твоему, вообще возможно собираться эти многие тысячи пакетов в сборке Linux, если там всё так плохо?
Подсказка — там всё неплохо, плохо у домохозяйки с эрудицией.


V>>Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
V>>А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.
S>Дело даже не в том, что нейтив платформенно зависим. А в нежелании вообще заниматься вопросами организации сборочного конвеера.

Ты это сейчас всёрьез?
Большинство проектов в линухах собираются так:
make configure

потом:
make

потому:
make install

И это норма еще с 1985-го.

Но, блин, твои оценочные суждения доставляют, однако.
Я тоже львиную долю рабочего времени провожу в виндах, но достаточно эрудирован в 4-5 самых популярных сборках Linux.
А в которых не эрудирован — стараюсь не рассуждать.
Твой основной косяк — тебе нравится спорить на те темы, в которых ты ни бум-бум.
Ты тем самым экономишь себе время, собирая ключевую информацию от оппонентов, но в итоге всё-равно получается поверхностность.

Я помню наши споры про соционику.
Помню твои восклицания, мол, прочитал Есенине — да, это я.
Это как раз нормально.
Ненормально, когда ДонКихот говорит, да, я Есенин.
Потому что ты не Дн-Кихот.
Слишком поверхностен.
Слишком мало тебя интересует истинное устройство этого мира, тебе достаточно неких абстрактных представлений из оперы "оно примерно так".
Для возвышения над окружающим "быдлом" тебе этого достаточно.
А внутерннего стремления к абсолютному владению предметом у тебя нет — т.к. тебе всегда важно сравнивать себя с окружающими.
Это или безотцовщина или отец твоим воспитанием не занимался.

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


V>>Можно сказать, что существует — LLVM.
V>>Ой, это же опять "виртуальный процессор"!
S>И как мне llvm поможет собрать на винде библиотеку для ubuntu?

RTFM!

Здравствуйте, Sinclair, Вы писали:

V>>(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)
S>Ресолвинг — это и есть восстановление.

Нифига.
Ресолвинг в С++ — это поиск и конфигурирование путей к заголовкам и библиотекам.


S>Если зависимость — от .obj, для которого есть исходник, то ресолвинг — это компиляция.

И на марсе уже 20 лет существуют людские колонии.
Слушай, мне реально порой нравится нравится тобой произносимое, бо у тебя хватает смелости озвучивать то, о чём другие лишь только скромно думают...
Но совесть-то тоже надо иметь, перегибать-то не надо... ))


S>Если от .lib — то линковка. Если он внешнего пакета, то ресолвинг — это скачивание пакета.
S>По-прежнему ждём

Ты даже не представляешь, сколько всего мы ждём.
Но это всё бесплатное-опенсорсное.
Если ты или я это не сделаем — никто не сделает.
По крайней мере в ближайшие месяцы/годы/десятилетия.
А лично мне реально некогда...
Для меня эта задача, положа рукe на — тьфу, за полтора года успею примерно такое:
— сделаю первую версию
— получу по мозгам критику отовсюду, исправлю/доработаю
— потом опять добавлю/исправлю, к 3-й версии всё будет более-менее.

Через полтора года ты сможешь хвастаться всем этим...
И буквально малюсенький вопрос стоит — кто мне будет ЗП платить за этот период? ))


V>>В которых куча поддиректорий в поддиректории build, например.
S>Вот это всё — какие-то семидесятые.

Отнюдь.
Чем дальше, тем больше поддиректорий в поддиректории build.


V>>Это если разработчик предусмотрел какие-нить requirements.txt.
S>а если нет, то можно запустить pipreqs.

С вероятностью успеха примерно 50%.


V>>В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.
S>Для всех? Или для кого-то одного?

Для каждой сборки Linux свой файл.
Спасает то, что многие сборки являются как бы ответвлениями от "материнкой" сборки.
Например, чуть ли не половина сборок базируются на DEB-Linux.


V>>Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
S>То есть, всё же устанавливаются.

Откуда именно?


V>>Но не сложилось единого мирового реестра.
S>Речь не о единости реестра, а о штатном способе инсталляции зависимостей — в том числе и внутри build pipeline.

Этого в Джава нет.
Хотя я понимаю и унутре всячески сочувствую твоему представлению о прекрасном.


S>Как видим, в С++ ничего похожего нет — каждый дрочит как он хочет. Кто-то через nuget, кто-то через apt, кто-то через yum, кто-то просто через externals.

С++ тут не при чём, это заморочки платформенного уровня.


V>>Просто для поржать — вот дефолотный "центральный" репозиторий:
V>>https://repo.maven.apache.org/maven2/
V>>Пролистай до конца.
V>>Это всё.
S>Берём первый попавшийся Java проект на гитхабе: https://github.com/Anuken/Mindustry
S>Все зависимости качаются (если нужно) в процессе билда. Всё делается одной командой.

Не-не-не.
Никакой "одной командой", и никаких "в процессе билда".
Это разработчики либы нехило озаботились впендюрить такую функциональность.
Но "стандартной" такой нет.

А так-то, если поднапрячься, то в любой технологии можно впендюрить подобное.
Будет ли это что-то доказывать? — да аж ничего.
Незначительные флуктуации вакуума...


S>Берём первый попавшийся С++ проект на гитхабе. Читаем раздел Integration, впечатляемся.

Была бы у тебя совесть, ты бы точно так же подобрал наоборот.


V>>Да понятно, что ответить тебе нечего.
S>Понятно, что С++ по-прежнему фокусируется на особенностях языка, забивая на тулчейн.

Рехнулся?
Вроде был адекватным несколько постов?

При чём тут "особенности языка"?
Речь о зависимостях.

Проблема в том, что разные сборки линуха даже имеют разные АПИ уровня ОС.
Ну вот собирают даже ядро с разными флагами.
А потом ставят низкоуровневые либы, собранные с разными опциями.

В итоге, С++ проектам приходится уметь собираться в зоопарке архитектур, где отличия — по кол-ву поддерживаемой функциональности.
Ты эта... посмотрел бы хоть раз на какой-нить Config.h, который конфигурируется целью make configure.
Там будет полторы-две сотни макроопределений навроде #PLATFORM_HAS_EVENTFD 1

В исходниках затем ветвление на макропроцессоре: есть в АПИ ОС eventfd — пользуем, нет — эмулируем на пайпах и регистре-защёлке.


S>"нам не нужны модули, достаточно текстового препроцессора для инклуда хидеров". "Нам не нужен ABI, пусть он остаётся платформенно- и компиляторо-зависимым". Повторное использование в С++ просто имеет самый низкий приоритет. Какая-нибудь убогая нода с самого начала проектировалась для повторного использования, поэтому там из коробки менеджер пакетов.

Поэтому она тормозит.
Ты реально решил вот прямо сейчас повторять мантры религии из 2005-го?
Серьёзно? ))

Ну если нет в АПИ ОС eventfd, то никакие твои причитания на форумах это не изменят, не понимаешь, что ле? ))
Любой чирикающий попугай, который попробует нести чушь на эту тему, автоматически приравнивается к тупой домохозяйке, которой нечего делать в подобных обсуждениях.
Как грится, идите лучше накрутите бигуди, а взрослых дядек от работы отвлекать не надо.
И без вас хлопот хватает...


S>Мейнстримом ноды является "я возьму 99% готового кода, добавлю в него немножко клея и специфической логики, и у меня получится редистрибьютабл приложение".

Менйстрим ноды сделан плюсовиками, вроде меня.
Потому что Node.js — это насквозь нейтивная технология, и добавлять туда либы — это надо уметь, это надо понимать, как устроены JS-объекты, как нужно с ними общаться, чтобы не потекла память или не произошёл проход по памяти и т.д.
В общем, это не для средних умов технология, что касается добавления туда библиотек, основные которые являются обёртками над хорошо известными C/C++ библиотеками.

С другой стороны — ничего нового, под Lua была примерно та же история...


S>Мейнстримом С++ является "я напишу мой личный код на моей личной машине и скомпилирую под неё же, чтобы запускать его прямо здесь". Все желающие собирать код на машине X так, чтобы он использовался на машине Y — экстремалы.

Судя по описанию — это драйвер.
Что не так? ))
Ты примерно представляешь, что есть драйвер, или ты та самая обезъянка, которой такие как я должны делать либы для nodfe.js?


S>Все желающие писать код на машине X, чтобы его использовали при сборке на машине Y для исполнения на машине Z — ещё большие экстремалы, и должны страдать.

Поплачь, поплачь.
Вызови сочувствие у читателей...

А это... как его... ты сайтом не ошибся, случаем?
Домохозяйки тусуются не здесь.


V>>Скорее всего потому, что на тот момент ты не пользовался той функциональностью, про которую спрашиваешь сейчас.
V>>А она тогда была реализована через packages-config.
V>>И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.
S>Это непринципиальное улучшение.

Хрен там, это именно то, о чём ты спрашивал.
Т.е., относительно недавняя функциональность.
И твой вопрос выдал тебя с головой — ты никогда не конфигурировал проекты с большим кол-вом зависимостей.
Потому что на момент хождения VS2015 или первых версий VS2017 в наличии была такая функциональность, которая не позволила бы задавать вопросы так, как ты задал.
Ты бы сидел молча и не отсвечивал. ))


S>Управление пакетами было и до этого; то, что в msbuild не было автоматического restore, легко лечилось пребилд степом.

Ой нубство...
Что угодно можно вылечить чем угодно.
Только это всегда закат солнца вручную.
MS Build однажды предложил автоматизацию.

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


S>Ведь в С++ вы и сейчас предлагаете использовать packages.config, не так ли

Но ты же им пользовался до VS 2017 SP2?
Не умер?

И нода же пользуется отдельным файлом зависимостей?
И питон?
А почему С+ нельзя?


V>>До этого пакетный менеджер жил отдельно от системы сборки, как оно есть в node.js, питоне и т.д., где для восстановления зависимостей необходимо ручками пинать пакетный менеджер.
S>Можно ручками.

Не можно, а нужно, т.к. другого пути нет.


S>А можно — изнутри сборочного скрипта.

Пошла демагогия.
Или, таки, нубство?
Ты всерьёз считаешь, что для сборки С++ запрещено писать сборочные скрипты? ))

У меня такое сложилось ощущение, что ты пока не определился, что именно ты пытаешься доказать.
Судя по всполохам мыслей — чисто потрындеть ни о чём.


S>А можно, как в С++ — иметь рулоны инструкций про то, как собирать чудо на каждой из платформ.

С++ не обязывает тебя к этому — пиши такие же скрипты.
Собсно, в большинстве С++ проектов есть готовые скрипты примерно под десяток платформ или больше.
Но соберу проект и без них под любую платформу.
Потому что хорошо работающий код бесценнен, а потраченное время нуба на "а как собрать этот проект???" ничего не стоит.
Не умеешь — потерялся и не раздражаешь.
Идёшь семечками торговать.


V>>Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
V>>(по крайней мере в мейнстриме)
S>maven?

Не имеет центрального реестра, поэтому не работает в ситуации, когда ты форкнул проект с github.


S>Можно посмотреть на то, как устроены GitHub actions для java, С#, node.js проектов.
S>А можно — на C++. Разница будет видна невооружённым взглядом.

Потому что детсад и то и другое.
Открой для себя TeamCity.

Вот нафига С++ разработчикам технологии из середины нулевых?
Тебя устраивает — твой выбор.
Меня нет, бо это для дохозяек и прочего стада обезьянок.
Их выслушают, улыбнутся, и забудут о них через минуту.
Мало ли кто там жужжит, стукаясь о стекло, не понимая, что это всего лишь стекло?
Форточка рядом...


V>>Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
V>>И это верно не только для C++, ес-но.
S>Отлично. То есть для кросс-платформенной сборки, мне нужно поддерживать 100500 "файлов с зависимостями".

На практике 5 платформ: DEB, RPM, Pacman, Zypper, Nuget.
Остальное экзотика.
И даже экзотики вряд ли наберётся более 10 вариантов к перечисленному.


S>И то, что мой проект собирается на голой винде, не означает, что он же соберётся на убунту.

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


S>Я всё правильно понял?

Конечно, конечно.
Поиграй пока, а через пол-часа тебя позовут кушать манную кашу.


V>>Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
V>>И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
S>Ну, то есть в С++ забит болт на вопросы сборки и дистрибуции

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


S>поэтому имеем вот этот вот зоопарк и геморрой на ровном месте.

Опять нет.
Весь этот миллион кода не спроста по-разному сконфигурирован.
А по банальной причине — универсального ответа на любой вопрос нет.


S>Просто комитету неважно, насколько легко повторно использовать написанный на С++ код.

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


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

Это потому что сама Windows не имеет.
Отсылаю твои претензии к MS.


S>Можно сколько угодно кивать на тёмное прошлое C# и других языков, но по факту получается так, что С++ на поколение отстаёт от "языков для нубов".

И как же оно отстаёт, если использует тот же NuGet?
А как, по-твоему, вообще возможно собираться эти многие тысячи пакетов в сборке Linux, если там всё так плохо?
Подсказка — там всё неплохо, плохо у домохозяйки с эрудицией.


V>>Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
V>>А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.
S>Дело даже не в том, что нейтив платформенно зависим. А в нежелании вообще заниматься вопросами организации сборочного конвеера.

Ты это сейчас всёрьез?
Большинство проектов в линухах собираются так:
make configure

потом:
make

потому:
make install

И это норма еще с 1985-го.

Но, блин, твои оценочные суждения доставляют, однако.
Я тоже львиную долю рабочего времени провожу в виндах, но достаточно эрудирован в 4-5 самых популярных сборках Linux.
А в которых не эрудирован — стараюсь не рассуждать.
Твой основной косяк — тебе нравится спорить на те темы, в которых ты ни бум-бум.
Ты тем самым экономишь себе время, собирая ключевую информацию от оппонентов, но в итоге всё-равно получается поверхностность.

Я помню наши споры про соционику.
Помню твои восклицания, мол, прочитал Есенине — да, это я.
Это как раз нормально.
Ненормально, когда ДонКихот говорит, да, я Есенин.
Потому что ты не Дн-Кихот.
Слишком поверхностен.
Слишком мало тебя интересует истинное устройство этого мира, тебе достаточно неких абстрактных представлений из оперы "оно примерно так".
Для возвышения над окружающим "быдлом" тебе этого достаточно.
А внутерннего стремления к абсолютному владению предметом у тебя нет — т.к. тебе всегда важно сравнивать себя с окружающими.
Это или безотцовщина или отец твоим воспитанием не занимался.

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


V>>Можно сказать, что существует — LLVM.
V>>Ой, это же опять "виртуальный процессор"!
S>И как мне llvm поможет собрать на винде библиотеку для ubuntu?

RTFM!