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

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

По-прежнему ждём


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

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

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

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

V>Но не сложилось единого мирового реестра.
Речь не о единости реестра, а о штатном способе инсталляции зависимостей — в том числе и внутри build pipeline.
Как видим, в С++ ничего похожего нет — каждый дрочит как он хочет. Кто-то через nuget, кто-то через apt, кто-то через yum, кто-то просто через externals.

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

V>Да понятно, что ответить тебе нечего.
Понятно, что С++ по-прежнему фокусируется на особенностях языка, забивая на тулчейн. "нам не нужны модули, достаточно текстового препроцессора для инклуда хидеров". "Нам не нужен ABI, пусть он остаётся платформенно- и компиляторо-зависимым". Повторное использование в С++ просто имеет самый низкий приоритет. Какая-нибудь убогая нода с самого начала проектировалась для повторного использования, поэтому там из коробки менеджер пакетов. Мейнстримом ноды является "я возьму 99% готового кода, добавлю в него немножко клея и специфической логики, и у меня получится редистрибьютабл приложение". Мейнстримом С++ является "я напишу мой личный код на моей личной машине и скомпилирую под неё же, чтобы запускать его прямо здесь". Все желающие собирать код на машине X так, чтобы он использовался на машине Y — экстремалы.
Все желающие писать код на машине X, чтобы его использовали при сборке на машине Y для исполнения на машине Z — ещё большие экстремалы, и должны страдать.

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

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

V>Ес-но.
V>Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
V>(по крайней мере в мейнстриме)
maven? gradle? you name it.
Можно посмотреть на то, как устроены GitHub actions для java, С#, node.js проектов.
А можно — на C++. Разница будет видна невооружённым взглядом.

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

V>Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
V>И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
Ну, то есть в С++ забит болт на вопросы сборки и дистрибуции, поэтому имеем вот этот вот зоопарк и геморрой на ровном месте. Просто комитету неважно, насколько легко повторно использовать написанный на С++ код.
И это странно — скажем, даже убогий повершелл, в котором специально ограничивали возможность повторного использования, т.к. его цель — это одноразовые однострочники, и тот имеет встроенный менеджер пакетов.
Можно сколько угодно кивать на тёмное прошлое C# и других языков, но по факту получается так, что С++ на поколение отстаёт от "языков для нубов".

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

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