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

V>>Ресолвинг в С++ — это поиск и конфигурирование путей к заголовкам и библиотекам.
S> Изобретение своих трактовок для общепринятых терминов — ну, так.

Ну так надо владеть терминологией.
https://docs.gradle.org/current/userguide/dependency_resolution.html#:~:text=Dependency%20resolution%20is%20a%20process,be%20added%20to%20the%20graph.
Ресолвинг зависимостей — это просто рекурсивное составление списка таких зависимостей.


S>Нет. Даже если мы наймём команду из десяти человек, то через пять лет у нас будет 115й способ собирать проекты на С++, с околонулевым комьюнити.

Это ты и на работе так технические решения принимаешь?
Кошмар... ))

Взять тот же MSBuild и допилить его до интеграции с Nuget и для C++ проектов.
А потом портировать эти изменения в Linux, в которых и MSBuild и NuGet тоже присутствуют после установки .Net Core.
При этом для нейтивных проектов поле TargetFramework можно было бы использовать для ID платформы, например "Ubuntu 18.04".
Или добавить специальное поле — не принципиально.

А что ты там себе вообразил — я ХЗ.


S>Мы только увеличим фрагментацию, которой и так достаточно.

Остапа понесло...


V>>Чем дальше, тем больше поддиректорий в поддиректории build.
S>Вот именно это наращивание поддиректорий и есть семидесятые.

Наоборот, в 70-е практически не было кросс-платформенных проектов, готовых изкаробки к сборке и деплою.
Это всё современные веяния, кучно пошли где-то в нулевых и только расширяются со временем.


V>>С вероятностью успеха примерно 50%.
S>С чего это?

С того, что это эвристическая хрень.
У питона нет описания проектов и их зависимостей.
Зачастую "продукт" на Питоне — просто файл скрипта.
В самом файле питоновского скрипта зависимости ищутся через путь, настроенный для машинки питона, который (путь) можно изменять прямо из скрипта через вычисляемые в процессе работы скрипта строки.

Зависимости — не обязательно "пакеты", это просто просто еще один такой же файл, который ты скачал откуда-то из интернета и положил рядом или где-то в пути, который же и настроишь в процессе работы скрипта.

Импорт может быть вычислимым через exec:

aa="import bb" # здесь не обязательно константное выражение
exec(aa)

и т.д. и т.п. до бесконечности.

В общем, в Питоне тебе никто ничего не гарантирует, потому что язык такой.


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

Что ужас, что есть несколько пакетных менеджеров?
Это как раз ерунда — за 10 мин пишется скрипт-хелпер, который из списка зависимостей сделает список их для локального родного пакетного менеджера и вызовет того для установки пакетов из списка. В 99% случаев это будет просто текстовый файл с перечислением имен/версий пакетов, который (файл) не потребуется как-либо изменять, а надо будет просто подать в аргументы вызова.

Если бы дело было только в разнообразии пакетных менеджеров, этот вопрос был бы решен давным давно.

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


V>>Откуда именно?
S>Откуда наконфигурили, оттуда и устанавливаются.

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

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


V>>Этого в Джава нет.
S>И maven и gradle умеют качать зависимости.

А толку, если качать неоткуда, бо нет дефолтного репозитория, как есть у дотнета nuget.org?

Так-то и у плюсов дофига пакетных менеджеров сугубо для плюсов:
https://hackingcpp.com/cpp/tools/package_managers.html

Сценарий в каждом из них вполне характерный для среднестатистического пакетного менеджера:
https://habr.com/ru/post/342982/


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

Садись два, не выучил уроки.


V>>Не-не-не.
V>>Никакой "одной командой", и никаких "в процессе билда".
S>Именно одной командой.
S>

S>gradlew desktop:dist
S>

Смотрите сюда:
https://github.com/Anuken/Mindustry/blob/master/build.gradle
Это закат солнца вручную на пол-тыщи строк.

Такое можно для любого языка сделать.
Вот тебе аналогичное для CMake:
https://github.com/Slicer/Slicer/blob/master/SuperBuild.cmake#L226

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

Ты мне покажи проект на Джаве с лохматыми зависимостями, в котором оные указаны списком, не важно, плоским тектовым или в XML, типа requirements.txt или packages.config.
И чтобы "само" всё работало.
Найдёшь — приходи. ))


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

Ты мне приводил в точности такие же флуктуации вакуума для Джавы.
Или это другое, нельзя сравнивать?


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

Ну, CMake и git предварительно поставить придётся, не без этого.
(че-та ржу уже)


S>Потому что нет общестандартного решения. И никто его не ищет.

Как и в Джаве, во всех твоих примерах.
Ты ведь так и не привёл ни одного адекватного примера и никогда не приведёшь, потому что их для Джавы нет, в отсутствии единого репозитория пакетов.
И потому что у джавы слишком дохрена платформенно-зависимых этих пакетов, которые предназначены, скажем, для Linux, но не для Windows/MacOS и наборот.

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

Но это другое, нельзя сравнивать.


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

У тебя тоже был шанс, но ты не справился.
Я же не ожидал, что ты мне начнёшь приводить закаты солнца вручную.
А что, так можно было?

Если бы ситуация была наоборот, т.е. я тебя просил бы привести примеры, а ты бы привёл что привёл — я только поржал бы в лицо, как грится.


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

Потому что я рассуждаю о проблемах, а ты мне приводишь примеры, эти проблемы лишь демонстрирующие.

Тебе полегчало, что я тебе аналогичные примеры привёл?
Что-то это дало обсуждению?

Дурдом.