Сообщение Re[25]: MS забило на дотнет. Питону - да, сишарпу - нет? от 03.08.2021 19:46
Изменено 03.08.2021 19:54 vdimas
Re[25]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Почему CMake?
V>>Я же написал — это уже "второй эшелон".
S>Вы написали, что CMake — это утилита ресолвинга зависимостей. Вот я хочу увидеть проект, в котором CMake зарезолвит зависимости.
Бери любой на CMake.
(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)
V>>Если в линуховых make configure есть ресторинг — то да.
V>>В виндовых для С++ проектов восстановления зависимостей делается через nuget restore.
S>Хм. А кросс-платформенных проектов С++ не существует?
Существуют.
В которых куча поддиректорий в поддиректории build, например.
V>>У меня такое в Питоне — зависимости не устанавливаются автоматом.
S>При всей моей нелюбви к питону, установка зависимостей в нём всё же предусмотрена из коробки. Это если мы говорим о питоновых зависимостях.
Это если разработчик предусмотрел какие-нить requirements.txt.
В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.
V>>В джаве аналогично — зависимости не устанавливаются автоматом, хотя проектов на Java всё еще больше, чем на C#.
S>А как же maven?
Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
Но не сложилось единого мирового реестра.
Просто для поржать — вот дефолотный "центральный" репозиторий:
https://repo.maven.apache.org/maven2/
Пролистай до конца.
Это всё.
V>>Да и студия до VS 2017 спотыкалась в процессе restore, в сети миллион обсуждений эпохи MSVS 2015.
S>
Да понятно, что ответить тебе нечего.
Скорее всего потому, что на тот момент ты не пользовался той функциональностью, про которую спрашиваешь сейчас.
А она тогда была реализована через packages-config.
И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.
Т.е. произошла интеграция системы сборки с пакетным менеджером.
До этого пакетный менеджер жил отдельно от системы сборки, как оно есть в node.js, питоне и т.д., где для восстановления зависимостей необходимо ручками пинать пакетный менеджер.
V>>Мы давно используем NuGet для обслуживания нейтивных зависимостей под виндами.
V>>Т.е., у тебя было недостаточно эрудиции относительно NuGet, но ты рассчитывал использовать его как аргумент, что является нарушением инженерной этики.
S>Нет, мне было интересно, как обстоят дела с управлением зависимостями в С++.
S>Хорошо, что есть nuget.
Ес-но.
Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
(по крайней мере в мейнстриме)
S>Не вполне понимаю, как управлять зависимостями на линуксе.
Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
И это верно не только для C++, ес-но.
Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.
S>Впрочем, похоже это неважно, т.к. кроссплатформенного тулчейна для С++ всё равно не существует.
Можно сказать, что существет — LLVM.
Ой, это же опять "виртуальный процессор"!
А может, в кавычках и кроется ответ на подобные вопросы?
Ты ж, вроде, неглупый человек...
V>>Почему CMake?
V>>Я же написал — это уже "второй эшелон".
S>Вы написали, что CMake — это утилита ресолвинга зависимостей. Вот я хочу увидеть проект, в котором CMake зарезолвит зависимости.
Бери любой на CMake.
(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)
V>>Если в линуховых make configure есть ресторинг — то да.
V>>В виндовых для С++ проектов восстановления зависимостей делается через nuget restore.
S>Хм. А кросс-платформенных проектов С++ не существует?
Существуют.
В которых куча поддиректорий в поддиректории build, например.
V>>У меня такое в Питоне — зависимости не устанавливаются автоматом.
S>При всей моей нелюбви к питону, установка зависимостей в нём всё же предусмотрена из коробки. Это если мы говорим о питоновых зависимостях.
Это если разработчик предусмотрел какие-нить requirements.txt.
В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.
V>>В джаве аналогично — зависимости не устанавливаются автоматом, хотя проектов на Java всё еще больше, чем на C#.
S>А как же maven?
Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
Но не сложилось единого мирового реестра.
Просто для поржать — вот дефолотный "центральный" репозиторий:
https://repo.maven.apache.org/maven2/
Пролистай до конца.
Это всё.
V>>Да и студия до VS 2017 спотыкалась в процессе restore, в сети миллион обсуждений эпохи MSVS 2015.
S>
Да понятно, что ответить тебе нечего.
Скорее всего потому, что на тот момент ты не пользовался той функциональностью, про которую спрашиваешь сейчас.
А она тогда была реализована через packages-config.
И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.
Т.е. произошла интеграция системы сборки с пакетным менеджером.
До этого пакетный менеджер жил отдельно от системы сборки, как оно есть в node.js, питоне и т.д., где для восстановления зависимостей необходимо ручками пинать пакетный менеджер.
V>>Мы давно используем NuGet для обслуживания нейтивных зависимостей под виндами.
V>>Т.е., у тебя было недостаточно эрудиции относительно NuGet, но ты рассчитывал использовать его как аргумент, что является нарушением инженерной этики.
S>Нет, мне было интересно, как обстоят дела с управлением зависимостями в С++.
S>Хорошо, что есть nuget.
Ес-но.
Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
(по крайней мере в мейнстриме)
S>Не вполне понимаю, как управлять зависимостями на линуксе.
Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
И это верно не только для C++, ес-но.
Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.
S>Впрочем, похоже это неважно, т.к. кроссплатформенного тулчейна для С++ всё равно не существует.
Можно сказать, что существет — LLVM.
Ой, это же опять "виртуальный процессор"!
А может, в кавычках и кроется ответ на подобные вопросы?
Ты ж, вроде, неглупый человек...
Re[25]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Почему CMake?
V>>Я же написал — это уже "второй эшелон".
S>Вы написали, что CMake — это утилита ресолвинга зависимостей. Вот я хочу увидеть проект, в котором CMake зарезолвит зависимости.
Бери любой на CMake.
(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)
V>>Если в линуховых make configure есть ресторинг — то да.
V>>В виндовых для С++ проектов восстановления зависимостей делается через nuget restore.
S>Хм. А кросс-платформенных проектов С++ не существует?
Существуют.
В которых куча поддиректорий в поддиректории build, например.
V>>У меня такое в Питоне — зависимости не устанавливаются автоматом.
S>При всей моей нелюбви к питону, установка зависимостей в нём всё же предусмотрена из коробки. Это если мы говорим о питоновых зависимостях.
Это если разработчик предусмотрел какие-нить requirements.txt.
В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.
V>>В джаве аналогично — зависимости не устанавливаются автоматом, хотя проектов на Java всё еще больше, чем на C#.
S>А как же maven?
Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
Но не сложилось единого мирового реестра.
Просто для поржать — вот дефолотный "центральный" репозиторий:
https://repo.maven.apache.org/maven2/
Пролистай до конца.
Это всё.
V>>Да и студия до VS 2017 спотыкалась в процессе restore, в сети миллион обсуждений эпохи MSVS 2015.
S>
Да понятно, что ответить тебе нечего.
Скорее всего потому, что на тот момент ты не пользовался той функциональностью, про которую спрашиваешь сейчас.
А она тогда была реализована через packages-config.
И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.
Т.е. произошла интеграция системы сборки с пакетным менеджером.
До этого пакетный менеджер жил отдельно от системы сборки, как оно есть в node.js, питоне и т.д., где для восстановления зависимостей необходимо ручками пинать пакетный менеджер.
V>>Мы давно используем NuGet для обслуживания нейтивных зависимостей под виндами.
V>>Т.е., у тебя было недостаточно эрудиции относительно NuGet, но ты рассчитывал использовать его как аргумент, что является нарушением инженерной этики.
S>Нет, мне было интересно, как обстоят дела с управлением зависимостями в С++.
S>Хорошо, что есть nuget.
Ес-но.
Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
(по крайней мере в мейнстриме)
S>Не вполне понимаю, как управлять зависимостями на линуксе.
Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
И это верно не только для C++, ес-но.
Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.
S>Впрочем, похоже это неважно, т.к. кроссплатформенного тулчейна для С++ всё равно не существует.
Можно сказать, что существует — LLVM.
Ой, это же опять "виртуальный процессор"!
А может, в кавычках и кроется ответ на подобные вопросы?
Ты ж, вроде, неглупый человек...
V>>Почему CMake?
V>>Я же написал — это уже "второй эшелон".
S>Вы написали, что CMake — это утилита ресолвинга зависимостей. Вот я хочу увидеть проект, в котором CMake зарезолвит зависимости.
Бери любой на CMake.
(будем считать, что я тебя "подловил", т.к. здесь ты просил заресолвить, а не восстановить их локально)
V>>Если в линуховых make configure есть ресторинг — то да.
V>>В виндовых для С++ проектов восстановления зависимостей делается через nuget restore.
S>Хм. А кросс-платформенных проектов С++ не существует?
Существуют.
В которых куча поддиректорий в поддиректории build, например.
V>>У меня такое в Питоне — зависимости не устанавливаются автоматом.
S>При всей моей нелюбви к питону, установка зависимостей в нём всё же предусмотрена из коробки. Это если мы говорим о питоновых зависимостях.
Это если разработчик предусмотрел какие-нить requirements.txt.
В плюсах ровно с аналогичной сложностью можно перечислить зависимости для yum, apt, zypper, pacman, NuGet и т.д., т.е. автоматизировать их установку.
V>>В джаве аналогично — зависимости не устанавливаются автоматом, хотя проектов на Java всё еще больше, чем на C#.
S>А как же maven?
Я не говорил, что в джаве нет пакетных менеджеров, их там несколько популярных, в т.ч. упомянутый maven.
Но не сложилось единого мирового реестра.
Просто для поржать — вот дефолотный "центральный" репозиторий:
https://repo.maven.apache.org/maven2/
Пролистай до конца.
Это всё.
V>>Да и студия до VS 2017 спотыкалась в процессе restore, в сети миллион обсуждений эпохи MSVS 2015.
S>
Да понятно, что ответить тебе нечего.
Скорее всего потому, что на тот момент ты не пользовался той функциональностью, про которую спрашиваешь сейчас.
А она тогда была реализована через packages-config.
И только в одном из обновлений VS 2017 появился новый MSBuld, в котором появился элемент PackageReference и соответсвующая стадия сборки — restore.
Т.е. произошла интеграция системы сборки с пакетным менеджером.
До этого пакетный менеджер жил отдельно от системы сборки, как оно есть в node.js, питоне и т.д., где для восстановления зависимостей необходимо ручками пинать пакетный менеджер.
V>>Мы давно используем NuGet для обслуживания нейтивных зависимостей под виндами.
V>>Т.е., у тебя было недостаточно эрудиции относительно NuGet, но ты рассчитывал использовать его как аргумент, что является нарушением инженерной этики.
S>Нет, мне было интересно, как обстоят дела с управлением зависимостями в С++.
S>Хорошо, что есть nuget.
Ес-но.
Именно поэтому я не мог ошибиться, что ты подразумевал именно NuGet, т.к. на сегодня не существует другого пакетного менеджера, интегрированного в систему сборки проектов.
(по крайней мере в мейнстриме)
S>Не вполне понимаю, как управлять зависимостями на линуксе.
Легко — перечисляя в файле зависимости и подавая этот файл родному пакетному менеджеру как аргумент, т.е. ровно так же как в питоне или node.js.
И это верно не только для C++, ес-но.
Но вся зоопарковость Linux тут проявляется в полной мере, т.к. одни и те же пакеты в разных сборках Linux могут называться по-разному.
И наличие того или иного пакета зависит от воли ментейнеров данной сборки Linux.
Собсно, необходимость быть независимым от всего этого зоопарка заставила питон и node.js обзавестись дублирующей функциональностью пакетных менеджеров.
А вот с нейтивными либами похуже (любыми нейтивными, не только С/С++) — там традиционно серьезная зависимость от конкретной платформы.
S>Впрочем, похоже это неважно, т.к. кроссплатформенного тулчейна для С++ всё равно не существует.
Можно сказать, что существует — LLVM.
Ой, это же опять "виртуальный процессор"!
А может, в кавычках и кроется ответ на подобные вопросы?
Ты ж, вроде, неглупый человек...