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

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

gem install
pip install
npm install
go get

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


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

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

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

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

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

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

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

V>(опять тебе неуд)

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

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

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

V>Т.е., более-менее ориентируюсь в том, что и как потребуется делать.
Поверю вам на слово.

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

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

V>Но нужна будет в какой-то момент готовая инфраструктура, а именно — наполнение многими тысячами нетивных пакетов под разные платформы репозитория nuget.
Воот, вы уже начинаете потихоньку понимать, что проблема — вовсе не в том, чтобы написать .targets, который использует для сборки gcc вместо vc.
Кто будет делать это наполнение? Как вы их собираетесь мотивировать? Вот это — продуктовые вопросы, и на них удовлетворительных ответов нет.
Если бы комитет взялся продвигать какое-то одно решение — неважно, msbuild, nuget, или что-то особенное — то был бы шанс на консолидацию усилий.
А без этого над вами просто посмеются и всё.

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

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

V>Иначе бы она не называлась cross. ))

V>Но что-то хреново пока и там, и там.


V>В С++ с кроссплатформенностью в разы лучше.

V>Собсно, это пока единственное mature кроссплатформенное решение.

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

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

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