Сообщение Re[29]: MS забило на дотнет. Питону - да, сишарпу - нет? от 04.08.2021 14:58
Изменено 04.08.2021 15:05 vdimas
Re[29]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, 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:
и т.д. и т.п. до бесконечности.
В общем, в Питоне тебе никто ничего не гарантирует, потому что язык такой.
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>
Смотрите сюда:
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>Но вместо примера репозитория, который честно стягивает зависимости и строится на более-менее любой платформе, мы имеем рассуждения о том, как круто было бы написать такой движок.
Потому что я рассуждаю о проблемах, а ты мне приводишь примеры, эти проблемы лишь демонстрирующие.
Тебе полегчало, что я тебе аналогичные примеры привёл?
Что-то это дало обсуждению?
Дурдом.
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>Но вместо примера репозитория, который честно стягивает зависимости и строится на более-менее любой платформе, мы имеем рассуждения о том, как круто было бы написать такой движок.
Потому что я рассуждаю о проблемах, а ты мне приводишь примеры, эти проблемы лишь демонстрирующие.
Тебе полегчало, что я тебе аналогичные примеры привёл?
Что-то это дало обсуждению?
Дурдом.
Re[29]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, 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:
и т.д. и т.п. до бесконечности.
В общем, в Питоне тебе никто ничего не гарантирует, потому что язык такой.
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>
Смотрите сюда:
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>Но вместо примера репозитория, который честно стягивает зависимости и строится на более-менее любой платформе, мы имеем рассуждения о том, как круто было бы написать такой движок.
Потому что я рассуждаю о проблемах, а ты мне приводишь примеры, эти проблемы лишь демонстрирующие.
Тебе полегчало, что я тебе аналогичные примеры привёл?
Что-то это дало обсуждению?
Дурдом.
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>Но вместо примера репозитория, который честно стягивает зависимости и строится на более-менее любой платформе, мы имеем рассуждения о том, как круто было бы написать такой движок.
Потому что я рассуждаю о проблемах, а ты мне приводишь примеры, эти проблемы лишь демонстрирующие.
Тебе полегчало, что я тебе аналогичные примеры привёл?
Что-то это дало обсуждению?
Дурдом.