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

V>Ресолвинг в С++ — это поиск и конфигурирование путей к заголовкам и библиотекам.
Изобретение своих трактовок для общепринятых терминов — ну, так.

V>Ты даже не представляешь, сколько всего мы ждём.
V>Но это всё бесплатное-опенсорсное.
V>Если ты или я это не сделаем — никто не сделает.
V>По крайней мере в ближайшие месяцы/годы/десятилетия.
V>А лично мне реально некогда...
V>Для меня эта задача, положа руку на — тьфу, за полтора года успею примерно такое:
V>- сделаю первую версию
V>- получу по мозгам критику отовсюду, исправлю/доработаю
V>- потом опять добавлю/исправлю, к 3-й версии всё будет более-менее.
V>Через полтора года ты сможешь хвастаться всем этим...
V>И буквально малюсенький вопрос стоит — кто мне будет ЗП платить за этот период? ))

Нет. Даже если мы наймём команду из десяти человек, то через пять лет у нас будет 115й способ собирать проекты на С++, с околонулевым комьюнити.
Мы только увеличим фрагментацию, которой и так достаточно.

V>Чем дальше, тем больше поддиректорий в поддиректории build.
Вот именно это наращивание поддиректорий и есть семидесятые.

V>С вероятностью успеха примерно 50%.
С чего это?

V>Для каждой сборки Linux свой файл.
V>Спасает то, что многие сборки являются как бы ответвлениями от "материнкой" сборки.
V>Например, чуть ли не половина сборок базируются на DEB-Linux.
Ну вот это и есть ужас.

V>Откуда именно?
Откуда наконфигурили, оттуда и устанавливаются.

V>Этого в Джава нет.
И maven и gradle умеют качать зависимости.

V>С++ тут не при чём, это заморочки платформенного уровня.
Нет.

V>>>Просто для поржать — вот дефолотный "центральный" репозиторий:
V>>>https://repo.maven.apache.org/maven2/
V>>>Пролистай до конца.
V>>>Это всё.
S>>Берём первый попавшийся Java проект на гитхабе: https://github.com/Anuken/Mindustry
S>>Все зависимости качаются (если нужно) в процессе билда. Всё делается одной командой.

V>Не-не-не.
V>Никакой "одной командой", и никаких "в процессе билда".
Именно одной командой.
gradlew desktop:dist

V>Это разработчики либы нехило озаботились впендюрить такую функциональность.
V>Но "стандартной" такой нет.
Берём другой первый попавшийся проект на java.
https://github.com/apache/pinot#building-pinot

[code]

mvn clean install -DskipTests -Pbin-dist
[/code]

V>А так-то, если поднапрячься, то в любой технологии можно впендюрить подобное.
V>Будет ли это что-то доказывать? — да аж ничего.
V>Незначительные флуктуации вакуума...
Всё наоборот. Флуктуации вакуума — это C++ проекты, которые можно собрать где-то, кроме заботливо подготовленного енвайронмента. Потому что нет общестандартного решения. И никто его не ищет.

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

V>При чём тут "особенности языка"?
V>Речь о зависимостях.
Я думал, это очевидно. В приличных языках ещё со времён Pascal есть средства модульности — прямо на уровне языка.
То есть я прямо в исходнике могу промаркировать зависимости.
Есть понятие модуля — есть искушение сделать систему распространения модулей. Это, конечно, необязательно (например, для паскаля или Delphi ничего подобного до сих пор не существует, афаик).
А в С++ всё что есть — #include "lib.h". Вот уж не думал, что придётся объяснять базовые вещи.

V>Проблема в том, что разные сборки линуха даже имеют разные АПИ уровня ОС.
А это-то тут при чём? В АПИ уровня ОС упирается маленькая часть RTL. Да, её можно делать платформенно-зависимой.
Большая часть логики никакого отношения к ОС не имеет. Нафига мне в каком-нибудь парсере/сериализаторе JSON АПИ уровня ОС?

Тем не менее, даже парсеры JSON вынуждены проходить через унижение "опиши 15 способов сборки для каждой среды".

V>В исходниках затем ветвление на макропроцессоре: есть в АПИ ОС eventfd — пользуем, нет — эмулируем на пайпах и регистре-защёлке.


S>>"нам не нужны модули, достаточно текстового препроцессора для инклуда хидеров". "Нам не нужен ABI, пусть он остаётся платформенно- и компиляторо-зависимым". Повторное использование в С++ просто имеет самый низкий приоритет. Какая-нибудь убогая нода с самого начала проектировалась для повторного использования, поэтому там из коробки менеджер пакетов.

V>Поэтому она тормозит.
) Рассуждения уровня "а ещё я туда ем".
Нет, тормозит она не поэтому. По вашему же мнению, лучший в мире менеджер пакетов сейчас у C#. Как мы знаем из бенчмарков, C# вовсе не тормозит. Удивительным образом, оказывается что наличие модульности и менеджера пакетов не коррелирует с быстродействием.

V>Ну если нет в АПИ ОС eventfd, то никакие твои причитания на форумах это не изменят, не понимаешь, что ле? ))
А что, у нас 100% проектов нуждаются в eventfd? И те, которые нуждаются — никак не могут использовать некую абстракцию, изолированную в отдельной библиотеке, которая для каждой платформы предоставляет свою реализацию?
Или это упражнение по проектированию архитектуры — rocket science для C++?

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

V>Судя по описанию — это драйвер.
Нет, это любой первый попавшийся проект.
Попробуйте навелосипедить какой-нибудь простейший парсер CSV так, чтобы его мог использовать С++ разработчик, работающий на любой платформе и компиляющий под любую целевую платформу.
Либо страдать будет этот разработчик, привинчивая интеграцию со своим проектом, либо вы, готовя 150 инструкций про то, как вами пользоваться под каждой из платформ.

Драйвер, my ass.

V>Что угодно можно вылечить чем угодно.
Вопрос только в объёмах. Современные платформы разработки берут значительную часть геморроя на себя. С++ перекладывает его на конечного разработчика — вот и всё.
Как вы уже неоднократно доказали, можно и С++ проект научить нормально собираться — просто для этого придётся потратить на порядок больше усилий, чем в любой java/node/python/ruby/etc.

V>Но интересуют "стандартные" сценарии.
V>Остальное от лукавого.
Согласен. В С++ стандартных сценариев вовсе нет. Остальное — от лукавого.

V>И нода же пользуется отдельным файлом зависимостей?
V>И питон?
V>А почему С+ нельзя?
Можно, но С++ требует много файлов зависимостей.

V>Ты всерьёз считаешь, что для сборки С++ запрещено писать сборочные скрипты? ))
Не запрещено. Вопрос — в объёме.

V>У меня такое сложилось ощущение, что ты пока не определился, что именно ты пытаешься доказать.
Вот как раз наоборот. У вас то идёт бред про то, что одна команда npm install — это невыносимая боль; то про то, что написать 5 файлов зависимостей и десяток скриптов для сборки — это норм.
V>Судя по всполохам мыслей — чисто потрындеть ни о чём.

V>С++ не обязывает тебя к этому — пиши такие же скрипты.
V>Собсно, в большинстве С++ проектов есть готовые скрипты примерно под десяток платформ или больше.

V>Но соберу проект и без них под любую платформу.

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

V>Не имеет центрального реестра, поэтому не работает в ситуации, когда ты форкнул проект с github.
Можно пример проекта с github, который я не смогу собрать, форкнув?

V>Открой для себя TeamCity.


V>Всё-равно всё реально работающее написано на плюсах.
V>И нода, и питон, и дотнет.
Ну и что?

V>На практике 5 платформ: DEB, RPM, Pacman, Zypper, Nuget.
V>Остальное экзотика.
V>И даже экзотики вряд ли наберётся более 10 вариантов к перечисленному.
15 платформ. Ну, ок, вы считаете это нормой. Мы — нет.

V>Только моск не выносите своим нытьём.


V>А по банальной причине — универсального ответа на любой вопрос нет.
У всех есть, и только у С++ вместо него "а что вы имеете в виду???".
Детский сад.

V>На уровне исходников проблем нет.
Вот лучше даже не начинайте.

V>Главное что? — предоставить соотв. ср-ва для написания максимально-эффективного кода для данной платформы.
Вы опять пересказываете мои же высказывания своими словами. Да, совершенно верно — если я пишу на машине X код для сборки на машине X и исполнения на машине X, то всё хорошо.
Наверное, на заре С++ это была штатная ситуация; оттого никто вообще не заморачивался вопросами "а как мне собрать мой код вместе с библиотекой, которую разрабатывали на машине Y".
V>Все ср-ва сборки и конфигурирования тоже есть, иначе было бы невозможно включать эти проекты (а их многие-многие тысячи) в дистрибутивы Linux.
Ну это не означает, что эти средства чем-то хороши.

V>Это потому что сама Windows не имеет.
V>Отсылаю твои претензии к MS.
Ну, ноду вроде же проектировали вовсе не для винды, не так ли? Тем не менее, в неё сразу вставили npm. Буквально у всех современных языков или платформ есть свои средства управления пакетами.
Для них куда претензию отправлять? Торвальдсу?

V>И как же оно отстаёт, если использует тот же NuGet?

V>А как, по-твоему, вообще возможно собирать эти многие тысячи пакетов в сборке Linux, если там всё так плохо?
Как-как, известно — через ежедневный, тупой, монотонный труд.


V>Ты это сейчас всёрьез?
V>Большинство проектов в *никсах собираются так:
V>

V>make configure
V>

V>потом:
V>

V>make
V>

V>потом:
V>

V>make install
V>

V>И это норма еще с 1985-го.

Отлично. Дайте мне такой проект, я соберу его на своём ноуте.

V>Я помню наши споры про соционику.
Да, вы тогда фееричненько зажгли.

V>Помню твои восклицания, мол, прочитал о Есенине — да, это я.
V>Это как раз нормально.
V>Ненормально, когда ДонКихот говорит, да, я Есенин.
V>Потому что ты не Дн-Кихот.


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

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

V>Ресолвинг в С++ — это поиск и конфигурирование путей к заголовкам и библиотекам.
Изобретение своих трактовок для общепринятых терминов — ну, так.

V>Ты даже не представляешь, сколько всего мы ждём.
V>Но это всё бесплатное-опенсорсное.
V>Если ты или я это не сделаем — никто не сделает.
V>По крайней мере в ближайшие месяцы/годы/десятилетия.
V>А лично мне реально некогда...
V>Для меня эта задача, положа руку на — тьфу, за полтора года успею примерно такое:
V>- сделаю первую версию
V>- получу по мозгам критику отовсюду, исправлю/доработаю
V>- потом опять добавлю/исправлю, к 3-й версии всё будет более-менее.
V>Через полтора года ты сможешь хвастаться всем этим...
V>И буквально малюсенький вопрос стоит — кто мне будет ЗП платить за этот период? ))

Нет. Даже если мы наймём команду из десяти человек, то через пять лет у нас будет 115й способ собирать проекты на С++, с околонулевым комьюнити.
Мы только увеличим фрагментацию, которой и так достаточно.

V>Чем дальше, тем больше поддиректорий в поддиректории build.
Вот именно это наращивание поддиректорий и есть семидесятые.

V>С вероятностью успеха примерно 50%.
С чего это?

V>Для каждой сборки Linux свой файл.
V>Спасает то, что многие сборки являются как бы ответвлениями от "материнкой" сборки.
V>Например, чуть ли не половина сборок базируются на DEB-Linux.
Ну вот это и есть ужас.

V>Откуда именно?
Откуда наконфигурили, оттуда и устанавливаются.

V>Этого в Джава нет.
И maven и gradle умеют качать зависимости.

V>С++ тут не при чём, это заморочки платформенного уровня.
Нет.

V>>>Просто для поржать — вот дефолотный "центральный" репозиторий:
V>>>https://repo.maven.apache.org/maven2/
V>>>Пролистай до конца.
V>>>Это всё.
S>>Берём первый попавшийся Java проект на гитхабе: https://github.com/Anuken/Mindustry
S>>Все зависимости качаются (если нужно) в процессе билда. Всё делается одной командой.

V>Не-не-не.
V>Никакой "одной командой", и никаких "в процессе билда".
Именно одной командой.

gradlew desktop:dist

V>Это разработчики либы нехило озаботились впендюрить такую функциональность.
V>Но "стандартной" такой нет.
Берём другой первый попавшийся проект на java.
https://github.com/apache/pinot#building-pinot

mvn clean install -DskipTests -Pbin-dist

V>А так-то, если поднапрячься, то в любой технологии можно впендюрить подобное.
V>Будет ли это что-то доказывать? — да аж ничего.
V>Незначительные флуктуации вакуума...
Всё наоборот. Флуктуации вакуума — это C++ проекты, которые можно собрать где-то, кроме заботливо подготовленного енвайронмента. Потому что нет общестандартного решения. И никто его не ищет.

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

V>При чём тут "особенности языка"?
V>Речь о зависимостях.
Я думал, это очевидно. В приличных языках ещё со времён Pascal есть средства модульности — прямо на уровне языка.
То есть я прямо в исходнике могу промаркировать зависимости.
Есть понятие модуля — есть искушение сделать систему распространения модулей. Это, конечно, необязательно (например, для паскаля или Delphi ничего подобного до сих пор не существует, афаик).
А в С++ всё что есть — #include "lib.h". Вот уж не думал, что придётся объяснять базовые вещи.

V>Проблема в том, что разные сборки линуха даже имеют разные АПИ уровня ОС.
А это-то тут при чём? В АПИ уровня ОС упирается маленькая часть RTL. Да, её можно делать платформенно-зависимой.
Большая часть логики никакого отношения к ОС не имеет. Нафига мне в каком-нибудь парсере/сериализаторе JSON АПИ уровня ОС?

Тем не менее, даже парсеры JSON вынуждены проходить через унижение "опиши 15 способов сборки для каждой среды".

V>В исходниках затем ветвление на макропроцессоре: есть в АПИ ОС eventfd — пользуем, нет — эмулируем на пайпах и регистре-защёлке.


S>>"нам не нужны модули, достаточно текстового препроцессора для инклуда хидеров". "Нам не нужен ABI, пусть он остаётся платформенно- и компиляторо-зависимым". Повторное использование в С++ просто имеет самый низкий приоритет. Какая-нибудь убогая нода с самого начала проектировалась для повторного использования, поэтому там из коробки менеджер пакетов.

V>Поэтому она тормозит.
) Рассуждения уровня "а ещё я туда ем".
Нет, тормозит она не поэтому. По вашему же мнению, лучший в мире менеджер пакетов сейчас у C#. Как мы знаем из бенчмарков, C# вовсе не тормозит. Удивительным образом, оказывается что наличие модульности и менеджера пакетов не коррелирует с быстродействием.

V>Ну если нет в АПИ ОС eventfd, то никакие твои причитания на форумах это не изменят, не понимаешь, что ле? ))
А что, у нас 100% проектов нуждаются в eventfd? И те, которые нуждаются — никак не могут использовать некую абстракцию, изолированную в отдельной библиотеке, которая для каждой платформы предоставляет свою реализацию?
Или это упражнение по проектированию архитектуры — rocket science для C++?

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

V>Судя по описанию — это драйвер.
Нет, это любой первый попавшийся проект.
Попробуйте навелосипедить какой-нибудь простейший парсер CSV так, чтобы его мог использовать С++ разработчик, работающий на любой платформе и компиляющий под любую целевую платформу.
Либо страдать будет этот разработчик, привинчивая интеграцию со своим проектом, либо вы, готовя 150 инструкций про то, как вами пользоваться под каждой из платформ.

Драйвер, my ass.

V>Что угодно можно вылечить чем угодно.
Вопрос только в объёмах. Современные платформы разработки берут значительную часть геморроя на себя. С++ перекладывает его на конечного разработчика — вот и всё.
Как вы уже неоднократно доказали, можно и С++ проект научить нормально собираться — просто для этого придётся потратить на порядок больше усилий, чем в любой java/node/python/ruby/etc.

V>Но интересуют "стандартные" сценарии.
V>Остальное от лукавого.
Согласен. В С++ стандартных сценариев вовсе нет. Остальное — от лукавого.

V>И нода же пользуется отдельным файлом зависимостей?
V>И питон?
V>А почему С+ нельзя?
Можно, но С++ требует много файлов зависимостей.

V>Ты всерьёз считаешь, что для сборки С++ запрещено писать сборочные скрипты? ))
Не запрещено. Вопрос — в объёме.

V>У меня такое сложилось ощущение, что ты пока не определился, что именно ты пытаешься доказать.
Вот как раз наоборот. У вас то идёт бред про то, что одна команда npm install — это невыносимая боль; то про то, что написать 5 файлов зависимостей и десяток скриптов для сборки — это норм.
V>Судя по всполохам мыслей — чисто потрындеть ни о чём.

V>С++ не обязывает тебя к этому — пиши такие же скрипты.
V>Собсно, в большинстве С++ проектов есть готовые скрипты примерно под десяток платформ или больше.

V>Но соберу проект и без них под любую платформу.

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

V>Не имеет центрального реестра, поэтому не работает в ситуации, когда ты форкнул проект с github.
Можно пример проекта с github, который я не смогу собрать, форкнув?

V>Открой для себя TeamCity.


V>Всё-равно всё реально работающее написано на плюсах.
V>И нода, и питон, и дотнет.
Ну и что?

V>На практике 5 платформ: DEB, RPM, Pacman, Zypper, Nuget.
V>Остальное экзотика.
V>И даже экзотики вряд ли наберётся более 10 вариантов к перечисленному.
15 платформ. Ну, ок, вы считаете это нормой. Мы — нет.

V>Только моск не выносите своим нытьём.


V>А по банальной причине — универсального ответа на любой вопрос нет.
У всех есть, и только у С++ вместо него "а что вы имеете в виду???".
Детский сад.

V>На уровне исходников проблем нет.
Вот лучше даже не начинайте.

V>Главное что? — предоставить соотв. ср-ва для написания максимально-эффективного кода для данной платформы.
Вы опять пересказываете мои же высказывания своими словами. Да, совершенно верно — если я пишу на машине X код для сборки на машине X и исполнения на машине X, то всё хорошо.
Наверное, на заре С++ это была штатная ситуация; оттого никто вообще не заморачивался вопросами "а как мне собрать мой код вместе с библиотекой, которую разрабатывали на машине Y".
V>Все ср-ва сборки и конфигурирования тоже есть, иначе было бы невозможно включать эти проекты (а их многие-многие тысячи) в дистрибутивы Linux.
Ну это не означает, что эти средства чем-то хороши.

V>Это потому что сама Windows не имеет.
V>Отсылаю твои претензии к MS.
Ну, ноду вроде же проектировали вовсе не для винды, не так ли? Тем не менее, в неё сразу вставили npm. Буквально у всех современных языков или платформ есть свои средства управления пакетами.
Для них куда претензию отправлять? Торвальдсу?

V>И как же оно отстаёт, если использует тот же NuGet?

V>А как, по-твоему, вообще возможно собирать эти многие тысячи пакетов в сборке Linux, если там всё так плохо?
Как-как, известно — через ежедневный, тупой, монотонный труд.


V>Ты это сейчас всёрьез?
V>Большинство проектов в *никсах собираются так:
V>

V>make configure
V>

V>потом:
V>

V>make
V>

V>потом:
V>

V>make install
V>

V>И это норма еще с 1985-го.

Отлично. Дайте мне такой проект, я соберу его на своём ноуте.

V>Я помню наши споры про соционику.
Да, вы тогда фееричненько зажгли.

V>Помню твои восклицания, мол, прочитал о Есенине — да, это я.
V>Это как раз нормально.
V>Ненормально, когда ДонКихот говорит, да, я Есенин.
V>Потому что ты не Дн-Кихот.


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