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

Это всего-лишь программа, что она может железу сделать? ))

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

А так? -ldflags "-w -s"

я чот уже путаю

Флаги для компиляции, погугли.

Размер сокращает существенно, у мну Линукс.

go env ... GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" ...

а раньше был другой

а раньше был другой

В смысле? А какая у тебя версия го?

Во, нашёл https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers

я взял да и установил как обычно 😂

я взял да и установил как обычно 😂

Я пытался указать в флаге компилятора gccgo а мне в ответ "Нет такого компилятора"

Я разницы не заметил, у мну проект может махонький, а так вот что нарыл https://habrahabr.ru/company/intel/blog/348230/

Во, ужал, почти с 7 MB до 2 с половиной File size Ratio Format Name -------------------- ------ ----------- ----------- 6889376 -> 2588452 37.57% linux/ElfAMD app

Доброе утро, коллеги. Посоветуйте пожалуйста, как лучше организовать репозитории. Есть проблема в том, что сейчас все находится в монорепе, но там слишком много всего и мержить все это - это проблема. При коммите там, происходит сборка всего разного. Вижу как решение все таки, это разделение процесса сборки в CI по разным веткам на разные компоненты. Однако потом встанет вопрос о разделении прав доступа различных разработчиков к различным кускам кода. Хочется все разбить на отдельные репозитории, однако столкнулись с не очень приятной вещью. Если у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg. Также было бы удобно, если все это хорошо показывалось в Goland. Разделением на репозитории, хотим решить проблему различного по времени деплоя различных проектов и разделения по правам доступа. Хотелось бы услышить какие нибудь советы и рекомендации, или аргументы почему нам не стоит так делать и как лучше тогда сорганизовать монорепозиторий. Спасибо.

Добавить эти пакеты в исключения, чтобы не импортировались в вендор.

А как же сборка в CI? Их же нужно импортить при сборке.

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

Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?

Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?

Коллеги, кто каким configuration manager пользуется? Я так понял на пике viper?

Доброе утро, коллеги. Посоветуйте пожалуйста, как лучше организовать репозитории. Есть проблема в том, что сейчас все находится в монорепе, но там слишком много всего и мержить все это - это проблема. При коммите там, происходит сборка всего разного. Вижу как решение все таки, это разделение процесса сборки в CI по разным веткам на разные компоненты. Однако потом встанет вопрос о разделении прав доступа различных разработчиков к различным кускам кода. Хочется все разбить на отдельные репозитории, однако столкнулись с не очень приятной вещью. Если у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg. Также было бы удобно, если все это хорошо показывалось в Goland. Разделением на репозитории, хотим решить проблему различного по времени деплоя различных проектов и разделения по правам доступа. Хотелось бы услышить какие нибудь советы и рекомендации, или аргументы почему нам не стоит так делать и как лучше тогда сорганизовать монорепозиторий. Спасибо.

Не надо сабмодулей

Мультирепо

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

Зачем удаляем?

> Если у тебя проект А зависит от проекта B, то glide скачивает его в свою папочку vendor. Первое неудобство, в том, что если ты хочешь одновременно работать в двух репозиториях, то тебе приходится удалять копию проекта B из папки vendor проекта А. Второе неудобство в том, что если между двуми проетами совместно используется какая то третья либа (ThirdPkg), то go начинает ругаться на то, что projectA/vendor/ThirdPkg не может бысть использован как projectB/vendor/ThirdPkg. У вас сборка одновременно двух сервисов чтоли?