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

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

S>gem install
S>pip install
S>npm install
S>go get 
S>

S>и т.д. И в С++ неизбежно появится что-то вроде этого.

Я давал уже тебе ссылки.
Основные претенденты на лидерство в ближайшее десятилетие vcpkg и Conan.

Вангую за vcpkg.

Он гладко интегрируются с CMake и MSBuild-проектами С++, т.е. виндовыми.
Если MSBuild (ну а вдруг) когда-нибудь интегрируется с CMake и Make, то будет еще один.

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

Насколько я вижу, основной практикой будет подключать vcpkg как сабмодуль в git и давать на него ссылку в аргументах вызова CMake.
Предлагаю потратить 10 мин на это чтиво, чтобы увидеть, как именно решаются вопросы:
https://vcpkg.readthedocs.io/en/latest/examples/installing-and-using-packages/


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

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

А проблемы были созданы до нас, вот этой современной зоопарковостью линухов.
И были созданы в те времена, когда ни о какой онлайн-доставке зависимостей речи не шло.

Так-то, был бы у нас один Linux, примерно как есть одна Windows и MacOS (пусть даже одновременно нескольких используемых версий) — вопрос вообще никогда не стоял бы, хосподя...


V>>Проекты С++ уже давно собираются MSBuild на Windows.
V>>MSBuild уже есть на линухах.
V>>Его просто надо доработать, например, дописать к нему плагины плюс файлы-конфигурации targets в поставке для конкретной платформы.
S>Совершенно неважно, доработаете ли вы мсбилд или у вас там будет какой-нибудь cpp restore.
S>Вы всё ещё барахтаетесь на детсадовском уровне — "как мне сделать xxx".
S>Чтобы из него выйти, надо научиться задаваться вопросами типа "зачем", а не "как".

Вот в этом твой косяк.
Ты не ориентируешься в современной ситуации, но порассуждать охота.
Ссылку я тебе дал, поработай над эрудицией.


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

Это ты предлагаешь, от непонимания, как всё устроено и работает.


S>Потому что сейчас никто в здравом уме не собирает С++ на линуксе через msbuild, так что его наличие для линукса нерелевантно.

Опять мимо.
С++ проекты собираются по-разному.
Но всё это множество вариантов можно свести к make configure, make, make install.
Или к build.bat/build.sh.

А что там под капотом — какая разница тому, кому надо лишь собрать проект, не погружаясь в подробности?


V>>Э-э-э, не понял вопроса?
S>Оно и видно.

Это к тебе обращались — ты не понял вопроса? ))


S>>>Всё, что вы получили — ещё один способ собирать C++ проекты на линуксе.
V>>Я получу способ не просто доставлять зависимости в проект, а возможность тонко управлять этим процессом.
S>Что-то мне подсказывает, что это не будет сильно тоньше, чем в CMake.

Тоньше, ведь в CMake я просто указываю ID продуктов и их модулей, ограничения на версии.
Но я не указываю, откуда их брать и в каком виде.

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

Вариантов-то дофига.
Например, готовим одновременно выпуски над LTS-версиями зависимостей и самыми актуальными, в итоге можно добавить еще конфигураций в проект, где для каждой конфигурации будут свои ограничения на версии зависимостей, где эти ограничения могут быть не константами, а переменными — в CMake такое запросто, в отличие от простейших requirements.txt.

Мне тут даже несколько странно, что приходится всё это пояснять на такой итерации.


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

Угу, в этом твой косяк — пытаться рассуждать о вещах, в которых не компетентен.



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

Ну тебя же не смущает, что MSBuild многократно запускает MSBuild?
А Make многократно запускает Make?
Или ты и этого не знал?

И про CMake ты опять в спешке упустил — он не собирает проекты, он окучивает стадию configure.
Собирает уже Make или MSBuild.

Т.е., цепочка там такая может быть:

configure: MSBuild+CMake
build: MSBulid
package: Nuget
install: CMake или Nuget

Существующая сегодня цепочка аналогичная за тем исключением первой строки:

configure: CMake
build: MSBulid
package: Nuget
install: CMake или Nuget

Судя по твоим рассуждениям, этого ты тоже не знал.


S>Что-то не ладится. Главный вопрос: вот существующие проекты как перевести на вашу будущую технологию? Кто это будет делать, и зачем?

Если ты уже перешёл по ссылке и прочитал, то вопрос должен быть исчерпан.

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

Давай образно, у нас примерно такое обсуждение, ты начал:
— вот я взял электросамокат, нажал педаль и сразу поехал, а ты пока свою машину заправишь, пока масло проверишь — сликом много возни!
— ваши самокаты обслуживаются специальным сервисом и вам не принадлежат, и потому всегда готовы, а у нас исторически куча владельцев личных автомобилей... но да, тема удобная, у нас уже вовсю используют подобные сервисы, и вот рядом со мной построили сервис, который будет содержать мою машину в состоянии немедленной готовности к старту, хотя, постройка этого сервиса оошлась чуть дороже, чем постройка сервиса для самокатов... но и фиг с ним, это одноразовые затраты, верно?
— Что? Вам сервисы? Зачем? Вы же все там в своём коконе закуклились, куда вы лезете???
— через минуту проехал на 100 км/ч мимо ползущего на 20км/ч самокатчика и даже не посмотрел в его сторону...



V>>Дык, MSBuild всё еще сырой, не зря его версии скачут чуть ли не в два раза быстрее версий Студии.
S>Дело не в MSBuild, а в том, как реализовать на нём кроссплатформенную сборку.

Это шутка такая?


S>Всё упирается в то, что под виндой уже написаны targets и props, рассчитанные на vc.

Точно "упирается"? ))
Откуда тогда там взялись targtes и props под clang?
Ты иногда как скажешь, так не знаешь, как реагировать...

И вообще, в Visual Studio ты можешь по ssh зайти на Linux (в докер, допустим), собирать и визуально отлаживать в привычной манере свой код.
Чем я обычно и занимаюсь по работе.


S>А для того, чтобы собирать, допустим, на линуксе те же самые проекты, таргетящие винду, придётся упасть и отжаться.

Для дотнета аналогично — в дотнете первый офциальный кроссплатформенный UI собираются выкатить только ближе к ноябрю:
https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/

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


V>>Но он движется в правильном направлении.
V>>Разумеется, рано или поздно он покроет и C++ проекты, причём, кроссплатформенно.
S>Насчёт "разумеется" я вовсе не уверен. Потому что ни Микрософт, ни Линукс комьюнити это не интересно.

Интересно и тем, и другим, т.к. облака в MS на линухах.
И всё чаще под Linux разрабатывают из под Windows.
Выходит, ты и этого не знал.


V>>Но нужна будет в какой-то момент готовая инфраструктура, а именно — наполнение многими тысячами нетивных пакетов под разные платформы репозитория nuget.
S>Воот, вы уже начинаете потихоньку понимать, что проблема — вовсе не в том, чтобы написать .targets, который использует для сборки gcc вместо vc.

Да это вообще не проблема, ес-но.
Прблемы всегда инфраструктурного характера, остальные решаются относительно малой кровью.


S>Кто будет делать это наполнение?

А кто уже наполнил nuget тысячами нейтивных проектов?


S>Как вы их собираетесь мотивировать?

Удобством.
А как еще?


S>Вот это — продуктовые вопросы, и на них удовлетворительных ответов нет.

Та самая паника из истории про самокаты? ))


S>Если бы комитет взялся продвигать какое-то одно решение — неважно, msbuild, nuget, или что-то особенное — то был бы шанс на консолидацию усилий.

Комитет чего?


S>А без этого над вами просто посмеются и всё.

Конкретно ты просто паникуешь.


S>Но эти технические проблемы — ничто перед вопросом "а как сделать так, чтобы в мире, заполненном телегой, вайбером, ватсаппом и вконтактом, вашим мессенджером пользовался хоть кто-то".

Но почему-то появились и телега, и вайбер и т.д.
Хотя были и скайп, и ICQ, и google-talk/hangouts/duo.


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

Добро пожаловать в Питон! ))


V>>Но по твоей ссылке настраивается еще несколько репозиториев.
S>Вы так говорите, как будто это плохо.

Конечно, плохо.
Ты же хотел взять проект 10-тилетней давности и чтобы он собрался.
А там захардкоженные ссылки в интернет.


S>Кто-то из вендоров выбирает публикацию через свой репозиторий — это совершенно нормально. Вот вы же сами мне рассказываете о том, что в ваших проектах используются дополнительные репозитории nuget.

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

Мир изменчив, поэтому захардкоженные ссылки — это убожество.
Показывает весь блеск и нищету, как грится.


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

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

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


S>На голубом глазу делая вид, что не приводили только что LLVM как аргумент кроссплатформенности C++.

Привёл, попросил включить голову. ))
Когда LLVM покажет сравнимое кач-во оптимизации с vc, gcc, intel compiler, тогда можно будет чуть по-другому смотреть на этот аргумент.
Но пока оно есть как есть.


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

Какой? Я сказал, что происходящее "круче", выяснилось, что "не круче".
Ну пусть на сравнимом уровне, но фиг с ним — я высмеял оба варианта как не отвечающие современным требованиям.
Нахрена мне такая система сборки, где я должен ручками писать скрипт на полторы тыщи строк?

Знаешь, почему CMake стал таким популярным?
Не потому что "вот так случилось", перевод на него проектов бывал относительно болезненным, и у нас в т.ч.

Там банальная причина — это поддержка библиотек.
Сам CMake обрастает библиотеками, мы у себя тоже разработали несколько библиотек нему.
В итоге, на описания целевых проектов любо-дорого посмотреть.

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


S>Только что загрузка исходников в С++ проекте была "в разы круче, чем в java", и тут же оказывается, что джава может делать то же самое — просто я невнимательно смотрел.
S>Прикольно с вами спорить — можно просто хмыкать, а вы сами себя закопаете.

Или ты опять накосячил — так и не посмотрел на свои ссылки.
Ссылку на джава-проекты, где среди прочих тоже были ссылки на проекты в исходниках, ты дал уже в следующем сообщении.
И было сказано "это даже круче", т.к. система сборки по моим ссылкам делала больше, чем по твоим, на которые я отвечал.

И насколько я понимаю, тебе бы стоило посыпать голову пеплом, когда я привёл аналогичные твоим ссылкам для С++, а не искать, к чему бы еще прицепиться. ))

Как ни крути, подход POM.XML — это деревянная телега из 19-го века, где лошадь заменили паровым двигателем.
В общем, бесконечно далеко от представлений о современном инструменте описания сборки.