Почему все так любят vscode

А если серьёзно — не далее как вчера коллега плевался от этого самого VS Code, говорит, всё криво и неудобно. Он не линуксоид, к опенсорсу относится нейтрально и сабж запускал, ясное дело, под виндой.

Так что про «все» ТС, наверное, всё же преувеличил.

Чем мне не нравятся текстовые редакторы, по сравнению с IDE, так это немедленной необходимостью писать хотя бы простенький скрипт для какой-либо системы сборки, вместо того, чтобы первое время не отвлекаться на это. В IDE закинул файлы в проект, указал пути к библиотекам (если они вообще нужны) и спокойно занимаешься непосредственно задачей.

Так что про «все» ТС, наверное, всё же преувеличил.

А ты сам попробуй напиши хоть на лоре хоть на реддите мол «пичарм тормозит/не нравится/не умеет» - каждый отписавшийся в треде начнёт вскод советовать

Дедопроблемы, есть же cargo new и npm init.

Это для ограниченных двумя языками.

Сейчас уже практически для каждого языка есть такие тулзы. Даже для сишечки и плюсиков запилили.

А если проект на нескольких языках?

И самое важное: какие проекты их используют?

xenix на лет десять старше линя :|

wsl cat -n и прочее wsl ls -l :)

правильный гуи вс]ко через css :)

(python||rc||zsh||bash||sh||ash)&&c++

А если проект на нескольких языках?

Тогда сверху прикручивается обвязка типа Bazel или Nix.

И самое важное: какие проекты их используют?

Из плюсовых? Да достаточно много.

И нафиг они нужны? особенно для «сишечки и плюсиков»

Из плюсовых? Да достаточно много.

Еще больше не использует ибо не нужное не нужно. Особенно не нужны для сборки плюсов поделия на жабе, а покетный манагер тоже дурь которая пройдет, т.к. «автообновление зависимостей» не полезно — автоматическая поломка проекта дурачком девопсом это уже было :) Пионэры упорствовали в заблуждениях вплоть до бенефиса «как получить звездюлей на ровном месте за автоматическую поломку билда». Все остальное все равно требует прикладывания верхней головы, поэтому все эти потуги с покетными менеджерами «для удобства» чушь собачья, т.к. сомнительное удобство и костыль для безруких и безголовых.

Просто большинство пакетов в репе gentoo, например, используют cmake, meson, autotools. Что это за системы сборки то такие?

Велосипеды «нитаких как все» (тм) :) тянут всякий бред в зависимостях, типа жабы или пыхтона, потом заказчик удивляется «жаба для сборки плюсов — это зачем?», а пионЭры не могут объяснить. И особенно не могут срочно переделать чтоб без этого вот.

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

В репе генты у тебя сама гента играет эту роль, но этот подход далеко не всегда работает. Банальный случай: ты работаешь над двумя проектами и в них разные версии одной и той же библиотеки. Ишоделоц? Cargo и прочие npm позволяют делать локальные песочницы для каждого проекта, за что их собственно и используют.

Это ты путаешь систему сборки и менеджер пакетов.

К сожалению, нет. Они сейчас идут в формате «два в одном».

Cargo и прочие npm позволяют

Тоже мне невидаль, автоматом качать third-party в отдельный каталог, автоматом собирать его там и использовать для сборки проекта. Никакие cargo и npm для этого не нужны.

Нуу… окей? Если тебе нравится обмазываться самописными скриптами и дро^Wкомпилировать, тебе никто не мешает это делать.

Всё это умеют autotools, cmake, meson, scons.

Ещё расскажи,что cargo бинарники качает исключительно.

А можно пример проекта с autotools, который сам скачивает все нужные зависимости, собирает их и ставит в свою песочницу? Я бы поржал.

Насчёт скачивания не знаю, обычно часть с собой предоставляют по старинке, всё равно привязаны к определённой версии. Но собирает зависимости (их много) в своём каталоге SU-2, например. Ты же не думаешь, что там есть проблема добавить скачивание архива?

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

Насчёт скачивания не знаю, обычно часть с собой предоставляют по старинке, всё равно привязаны к определённой версии.

Ну вот с этого и начнём.

Ты же не думаешь, что там есть проблема добавить скачивание архива?

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

Так вот, внимание вопрос: а нахрена всё это писать на автолулзах, если для этого сделаны тулзы лучше и удобнее?

А что, есть популярные проекты на C++, использующие cargo и npm?

Есть проекты на C++, использующие Conan и VcPkg.

«Имя, сестра, имя! Назови мне его имя!»

Сорян, мне категорически лень искать :)

То есть они есть, но их не видно.

Да не, можешь по гейхабу полазать, там куча проектов на cmake+vcpkg. Vcpkg скачивает зависимости и собирает их, потому передаёт в cmake пути к ним и тот собирает локальный проект.

Мало ли там сумашедших

Сумасшедшие используют автолулзы в 2022 году. Вот что действительно попахивает шизой, так эти безумные портянки копипасты на m4, которую никто толком объяснить не может как она работает вообще.

Отдельно, кстати, вызывает усмешку, что у многих проектов ./configure занимает больше времени чем собственно сборка, потому что bash – тормоз. Мы даже шутки ради думали сделать форк баша с JIT, чтобы ./configure быстрее работал.

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

Я думаю, что автолулзы надо закопать вместе со всеми кто на них пишет, потому что большинство проектов с автолулзами имеют дикие баги в сборке, как только речь заходит о чём-то хоть на секунду нестандартном

Люто плюсую

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

Дык потому они и не связаны, что бывает открываешь сырцы проекта, а там автолулзы и прочий говнокод. И вот сидишь и думаешь: а на кой хер мне это вообще?

Давай так: если мне нужно потратить больше 10 минут, чтобы разобраться как собирать проект, я скорее всего забью болт и не буду в него патчи слать. Просто потому что нахрен. В итоге получается, что в попенсорцных проектах патчи получают те, кто заморочился и снизил затраты на вход в проект. Это касается не только автолулзов, но и адекватной документации и прочих вещей.

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

У некоторых на это дело есть generic Makefile

Вопрос не в осиливании. Вопрос в том, зачем трогать что-то, на что даже авторам пофиг.

Я так и не понял зачем авторам трогать то, что закрывает их потребности на текущий момент?

Generate то есть? Я такое видел в IDE. Как с расчётом взаимосвязей должен разобраться текстовый редактор не знаю, а если есть плагин, который их рассчитывает, то чего бы им же не собирать проект?

И вот тут grem начинает осознавать, зачем нужны cargo и npm.

И тут hateyoufeel начинает осознавать, как вообще работают высокоуровневые системы сборки.

высокоуровневые системы сборки

Сам придумал?

Как будто IDE для любых языков есть.

А если проект на нескольких языках?

То и

В IDE закинул файлы в проект, указал пути к библиотекам (если они вообще нужны) и спокойно занимаешься непосредственно задачей.

не получится. За исключением одной-двух комбинаций языков.

Просто патч для системы сборки на основе autotools даже я, не будучи программистом и видя его впервые, осилил

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

Вон codelite ide предлагает поддержку аж c++, python, php, node.js и rust.

Это не говоря о netbeans и eclipse.

Или ты об одновременной работе? Было б странно, если б получилось.

Или ты об одновременной работе? Было б странно, если б получилось.

— А вот в IDE можно закинуть файлы и заниматься задачей, в VSCode надо tasks.json писать. IDE лучше!
— Да вон для кучи систем сборки есть поддержка, без ручного написания tasks.json.
— А если проект на нескольких языках?
— А что, в IDE можно на нескольких языках одновременно?
— Нет, а что?
— …

Вообще-то, в некоторых ide можно на нескольких языках писать, если ты не знал. Что хотел сказать то?

Или ты об одновременной работе? Было б странно, если б получилось.

Вообще-то, в некоторых ide можно на нескольких языках писать, если ты не знал.

Мда…

Что хотел сказать то?

Да не, ничего. Забей.

Доброе утро!