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

V>>Ресолвинг зависимостей — это просто рекурсивное составление списка таких зависимостей.
S>По вашей же ссылке можно прочитать, что частью dependency resolution является скачивание файлов.

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


V>>Это ты и на работе так технические решения принимаешь?
S>Это не техническое решение, а продуктовое.

ОМГ, "продуктовое". ))

"Техническое решение" в целом есть "Описание в заданной форме объекта проектирования/разработки или его части, необходимое и достаточное для достижения поставленных целей/решения поставленных задач по созданию АС"

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

Проекты С++ уже давно собираются MSBuild на Windows.
MSBuild уже есть на линухах.
Его просто надо доработать, например, дописать к нему плагины плюс файлы-конфигурации targets в поставке для конкретной платформы.


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

Э-э-э, не понял вопроса?
Разве ты был не в курсе, зачем потребовалось интегрировать Nuget в MSBuild?
Ликбез:

Package references, using the PackageReference node, manage NuGet dependencies directly within project files (as opposed to a separate packages.config file). Using PackageReference, as it's called, doesn't affect other aspects of NuGet; for example, settings in NuGet.Config files (including package sources) are still applied as explained in Common NuGet configurations.

With PackageReference, you can also use MSBuild conditions to choose package references per target framework, or other groupings. It also allows for fine-grained control over dependencies and content flow.

S>Всё, что вы получили — ещё один способ собирать C++ проекты на линуксе.

Я получу способ не просто доставлять зависимости в проект, а возможность тонко управлять этим процессом.

И не обязательно "всё переделывать" в уже имеющихся проектах.
(опять тебе неуд)

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

Напомню, что MS Build — это просто платформа определения целей и их св-в, зависимостей м/у целями, а так же т.н. "элементов".
Это что-то типа NAnt (если ты в курсе, что из себя представляет NAnt).

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

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

Всё-таки, MSBuild, как и весь .Net Core — это платформенная весчь, которая может и должна брать на себя некие уникальные моменты текущей платформы, давая возможность разработчику абстрагироваться от них.


S>Если, конечно, вы освоите вот этот вот простой момент "портировать изменения в Linux".

Я этим последние 20+ лет и занимаюсь, собсно.
В последние годы еще портирование в MacOS.
Т.е., более-менее ориентируюсь в том, что и как потребуется делать.


S>У меня есть некоторый опыт сборки С++ на линуксе при помощи msbuild. Это совсем не так просто, как вам кажется.

Дык, MSBuild всё еще сырой, не зря его версии скачут чуть ли не в два раза быстрее версий Студии.
Его еще дорабатывать и дорабатывать.

Но он движется в правильном направлении.
Разумеется, рано или поздно он покроет и C++ проекты, причём, кроссплатформенно.

Но нужна будет в какой-то момент готовая инфраструктура, а именно — наполнение многими тысячами нетивных пакетов под разные платформы репозитория nuget.
В общем, речь просто шла о том, чтобы лучше всё это сделать раньше, чем позже.
Потому что прямо сейчас основная работа в .Net Core идёт над самим языком и над самой пожарной прикладной функциональностью — над тем же GUI, webasm/Blazor и т.д.
Остальное идёт по остаточному принципу.


V>>Импорт может быть вычислимым через exec:
S>На практике такого очень мало. 99.9% питонового кода просто пишет в начале import bb, и всё.

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

В итоге пришлось аж лезть на сайт билд-машины ActiveState Python и там формировать образ специфичной инсталляхи Питона с конкретно-прописанными зависимостями библиотек, бо в дефолтной инсталляхе это всё не взлетало из-за конфликтов версий зависимостей других модулей.

Огромное спасибо разработчикам ActiveState Python за саму онлайн-возможность создавать уникальную инсталляху Питона, конечно...

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

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

Предлагаю вернуться немного назад в обсуждении и перечитать с новыми знаниями.


V>>Что ужас, что есть несколько пакетных менеджеров?
S>Что кроссплатформенная сборка требует поддерживать N файлов зависимостей.

Иначе бы она не называлась cross. ))
Это была бы разработка под одну некую абстрактную платформу, коей уже 26 лет стремится стать Джава или почти 20 лет дотнет. ))
Но что-то хреново пока и там, и там.

В С++ с кроссплатформенностью в разы лучше.
Собсно, это пока единственное mature кроссплатформенное решение.


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

Это основная и единственная проблема.
Nuget работает как он работает лишь потому, что есть центральный репозиторий.
Было бы их десятки несовместимых (в т.ч. несовместимых по именованиям пакетов в них) — была бы такая же точно каша.


V>>А толку, если качать неоткуда, бо нет дефолтного репозитория, как есть у дотнета nuget.org?
S>Дефолтный репозиторий, конечно же, есть. https://repo1.maven.org/maven2/
S>В данный момент в нём ~7 миллионов JAR-ов.

Но по твоей ссылке настраивается еще несколько репозиториев.


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

Ловко ты решил сменить фокус вопроса, зачётная демагогия.

Но и тут не прокатило — когда абстракции над железом/архитектурой станут бесплатными, тогда я приму этот аргумент.
Особенно в контексте этого спора — сравнения с С++.

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