IDE и docker

https://www.jetbrains.com/help/clion/clion-toolchains-in-docker.html

Ну ты либо каждый раз собирай в докере и тестируй (либо CI/CD, либо локальный стенд собрать), либо организуй все, что нужно, на локальный машине.

Такое ощущение, что здесь неправильно используется Docker.

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

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

Это ты так красиво спросил «Зачем нужен этот ваш докер»?

Еще про devcontainers слышал, но сам не использовал. Может быть подойдет.

Нет, докер нужен ибо удобно, вопрос в кейсе использования. Вилкой тоже можно суп есть, но зачем?

Ну тут либо он что-то делает не так в целом, либо нам что-то не дорассказал.

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

Аааааа! понял это вы докером решили проблему того что в плюсах нет пакетного менеджера но сделали это криво.

Спасибо за ответ

Да там может дофига разных ЯП. Мир не крутится вокруг плюсов.

Докер - это образ со средой сборки, в которой есть всё необходимое: кросс-компилятор, все базовые зависимости, плюс всякие заголовки

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

В рамках вопроса речь наверно про непосредствено вендор либы (как код так и подключаемые артефакты) иначе это полноценный сервис и это правильно завернуть его в докер и дергать условное апи не парясь. Для меня странно что сорцы которые учасвтуют в компиляции не примаунтили на локальную фс что бы без бубна иметь к ним доступ.

Бгг. Вершина контейнеризации - изолировать код от IDE. Осталось изолировать код от компилятора и мир станет совершенным.

(Впрочем, уже)

Вероятно, ты что-то делаешь не так. Если тебе дали такой образ, то рабочий процесс может выглядеть так: запускается контейнер, в него монтируется каталог с твоим кодом, ты средствами IDE подключаешься к контейнеру по SSH и пишешь там свой код, имея доступ к нужному окружению. Нет?

Есть же гомоморфное шифрование. Как раз для него задача. И название под повесточку подходит.

IDE сейчас умеют ходить куда надо по SSH, так что включать их в образ для контейнера не требуется.

Да, пожалуй, sshfs должно хватить. Осталось только выяснить, есть ли там SSH сервер.

Не пользуюсь ни докером ни модными IDE - нет проблем.

sshfs

??? Так, конечно, можно получить доступ к каким-то заголовочным файлам, но для компиляторов будет не очень. Я, может, чего-то ее понял, но выглядит как типичный кейс для «удалённой разработки», когда ты просто указываешь указываешь IDE нужный хост (контейнер) и пользуешься всем инструментарием, который там есть.

IDE сейчас умеют ходить куда надо по SSH, так что включать их в образ для контейнера не требуется.

Возможно.

Но это всё звучит как создание самому себе проблем на ровном месте с целью героического их решения. Если убрать из этой всей цепочки докер, всё станет намного проще. И ssh никакой не понадобится тоже.

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

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

Если убрать из этой всей цепочки докер, всё станет намного проще.

Итак, тебе нужно замороченное окружение: кросс-компиляторы, библиотеки своей разработки от разных филиалов/партнёров, какие-то патченные зависимости и прочее говно. Примерно такая ситуация у автора темы. Тебе дают образ, ты запускаешь контейнер и бесшовно работаешь над своей частью. Ты предлагаешь «упростить» себе жизнь, выкинув контейнер. Каким образом?

Вот это читал? https://code.visualstudio.com/docs/remote/remote-overview

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

Если я правильно понял анона, то в докере находятся все утилиты с зависимости для сборки, к докеру через volume или bind монтируется каталог с исходниками. К этому всему подключается IDE (хотя по идее среда может быть тоже в докере). Дальше написание кода и сборка идёт как обычно, потому что для компилятора в докере всё доступно локально без приседаний с sshfs.

https://docs.docker.com/storage/volumes/

https://docs.docker.com/storage/bind-mounts/

С докером сам не работал, имею только поверхностное представление о нём.

• Не работаю в IDE, поэтому не имею таких идиотских ограничений.
• Не работаю с проектами у которых зависимости лежат в докере. Зависимости лежат в системе и никак иначе.
• Имею мозг, что позволяет мне догадаться прописать пути к зависимостям, если они не прописаны.

прописать пути к зависимостям,

А зачем, если нет IDE? Или это ты к тому, что можешь настроить сборку без докера?

Зависимости лежат в системе и никак иначе

Имею мозг

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

Пункты если что были ортогональные. Нет IDE - нет проблемы, но если уж у тебя есть IDE и есть проблема что не настроены пути к зависимостям, то 💡💡💡 решением может быть их настройка!!!

Если для кого-то проблема установить нужные пакеты - то ему нечего делать в таких местах. Докер для этого никаким боком не нужен.

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

Именно потому что я делаю софт который собирается вне локалхоста, ему не нужно повторять никакое окружение. cmake . && cmake --build ., motherfudger, do you speak it?

В нормальных контейнерах не требуется делать ssh самому себе на локалхост, чтобы увидеть что там за файлы

Ты написал какую-то чушь© SSH нужно не для этого, перечитай тему, пожалуйста.

И для чего же оно нужно? В то время как в нормальном случае можно просто написать /opt/my_build_jail/usr/local/include в качестве пути поиска инклюдов и видеть их напрямую через файловую систему.

И для чего же оно нужно?

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

Development Containers не предлагали?

Гугли разработка через контейнеры в VS

Нет (linux.org.ru)

Кто сказал «dev containers»?! ))

а примонтировать разве нельзя?

Дополню тем что опция «подключиться к docker-окружению» для IDE разработки постепенно становится элементом минимально необходимого и появилась даже в отстающем и не самом популярном QtCreator.

Пока глюковато, но для проекта средней сложности уже норм.

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

О да, как это мне знакомо

необходимые для сборки, лежат в докере?

не очень понял, у этих зависимостей нет репозитория?

А разве любой дистрибутив линукс не является пакетным менеджером для плюсов?

Так может проще и IDE в докер засунуть, раз пошла такая пьянка?

Так может проще и IDE в докер засунуть, раз пошла такая пьянка?

Так VSCode именно так и делает. При использовании контейнерного режима в контейнере запускается специальный сервер, который выполняет всю реальную логику IDE, а хостовая часть просто обеспечивает отображение UI.