Установка Go (компилятора и инструментов) в Linux
Установка Go из стандартных системных репозиториев в Debian, Kali Linux, Linux Mint, Ubuntu
Для установки выполните команду:
Для Debian также рекомендуется добавить экспорт следующих переменных окружения в файле
/.zshrc если у вас ZSH):
Эти изменения вступят в силу после перезагрузки. Вместо перезапуска компьютера выполните:
Если вы не уверены, какая у вас оболочка, то выполните команду:
Если будет выведено:
Установка Go из стандартных системных репозиториев в Arch Linux, BlackArch и их производные
В Arch Linux и производные Go устанавливается следующим образом:
Для Arch Linux также рекомендуется добавить экспорт следующих переменных окружения в файле
Эти изменения вступят в силу после перезагрузки. Вместо перезапуска компьютера выполните:
Ручная установка самой последней версии компилятора Go
Ранее рекомендовалась именно ручная установка, поскольку она предусматривает добавление переменных окружения. Переменные окружения используются, например, в командах по установке, которые дают разработчики программ:
Без переменных окружения эта последовательность команд завершиться ошибкой.
Но эти переменные окружения можно добавить и при установке Go из репозитория, как это показано выше. Поэтому если вы это сделали (добавили экспорт переменных окружения), то каких либо преимуществ у ручной установки нет. Разве что, только если вам нужна самая последняя версия языка Go.
Если в источниках приложений для вашего дистрибутива отсутствует Go, либо вы хотите вручную установить самую последнюю версию компилятора, то следуйте этому руководству далее.
Следующая инструкция успешно протестирована в Kali Linux, Arch Linux, BlackArch, Linux Mint, Ubuntu. Также она должна работать в практически любом дистрибутиве Linux.
Если вы не уверены, какая у вас оболочка, то выполните команду:
Если будет выведено:
Если у вас Bash оболочка (большинство систем), то следуйте инструкциям из этого раздела:
Откройте файл .bashrc в директории пользователя любым текстовым редактором:
И для создания новых переменных окружения добавьте следующие строки в этот файл:
Когда всё готово, сохраните изменения и закройте файл.
Эти изменения вступят в силу после перезагрузки. Вместо перезапуска компьютера выполните:
Если у вас ZSH оболочка (по умолчанию, например, в Kali Linux), то следуйте инструкциям из этого раздела:
/.zshrc в директории пользователя любым текстовым редактором:
И для создания новых переменных окружения добавьте следующие строки в этот файл:
Когда всё готово, сохраните изменения и закройте файл.
Эти изменения вступят в силу после перезагрузки. Вместо перезапуска компьютера выполните:
Дальше одинаково для всех оболочек и систем.
Следующая команда автоматически определит и скачает последнюю версию файлов языка программирования Go:
Извлеките скаченный архив:
Кросс-компиляция в Go
Несмотря на то, что кроссплатформенность стала фактически стандартным атрибутом практически всех современных языков и библиотек, создавать по-настоящему кроссплатформенный продукт, всё равно было непросто. Компилируемые языки и сопутствующие библиотеки требовали сложной установки и настройки среды сборки и библиотек, а интерпретируемые — обязывали иметь или деплоить в составе необходимую версию интерпретатора. Есть немало проектов, пытающихся сделать этот процесс чуть более простым, но зачастую единственным решением оставалось устанавливать отдельный сервер и компилировать нативно.
В Go кросс-платформенность вышла на тот уровень, когда впервые можно смело отказаться от compile farms, специально настроенных dev-сред, виртуальных машин для сборки или chroot/docker-dev решений. И это ещё один серьезный game-changer, подробнее о котором я и хочу рассказать и показать на примерах
Поехали.
Как известно, в Go сознательно отказались от динамической линковки — по ряду причин, основная из которых очень схожа с обычным объяснением дизайна почти любого аспекта Go — «преимущества [динамической линковки] намного меньше её недостатков и сложности, которая она привносит в архитектуру». Что ж, главной причиной появления dynamic linking было желание экономить ресурсы — прежде всего диcковое пространство и память — которые сейчас достаточно дешевы, не только на серверах, но и в embedded-устройствах (коптеры, к примеру, несут на борту уже по 1-2 Гб RAM!). Вобщем, перечислять плюсы и минусы отдельного способа линковки — это потянет на отдельный пост, так что пока просто принимаем, как есть — в Go на выходе всегда имеем статический бинарник.
В Go 1.5 ожидается поддержка iOS.
Еще примечательно, что изначально поддержки Windows в Go не было — команда маленькая, и пачкать руки заниматься имплементацией кода для Windows было некому, но благодаря тому, что проект открыли для open-source разработки — порт для Windows был очень быстро написан сторонними людьми и интегрирован в официальную кодовую базу.
Хотя описанные далее процессы будут абсолютно одинаковы для всех платформ (за исключеним, разве что, Android и Native Client (NaCl), для которых нужны лишние телодвижения), далее в статье будет по-умолчанию считаться, что вы используете одну из трех самых популярных десктопных платформ — Linux, MacOS X или Windows. Кроме того, для большей простоты я буду подразумевать, что мы пишем и используем исключительно Go-код, без необходимости линковаться с С-библиотеками (и, тем самым, без необходимости использовать cgo/gcc). Есть еще отдельный кейс — когда нужно использовать ряд функций из стандартной библиотеки, завязанных на cgo, но об этом я напишу отдельной главой в конце.
Подготовка toolchain
Первый шаг, который необходимо выполнить — это собрать toolchain для нужной платформы.
Процесс занимает на Macbook Air 2012 около 26 секунд. Скрипт make.bash — это стандартный скрипт сборки Go, которым бы вы инсталлировали Go, если бы ставили из исходников. Он собирает, собственно, Go, и всю стандартную библиотеку, только в этот раз — для платформы windows/amd64.
Также, по упомянутой выше причине, мы отключили поддержку CGO.
Значения GOOS и GOARCH
Таблица значений GOOS (если кто знает, как на Хабре сделать таблица в 50% ширины — подскажите):
| OS | $GOOS |
|---|---|
| Linux | linux |
| MacOS X | darwin |
| Windows | windows |
| FreeBSD | freebsd |
| NetBSD | netbsd |
| OpenBSD | openbsd |
| DragonFly BSD | dragonfly |
| Plan 9 | plan9 |
| Native Client | nacl |
| Android | android |
И GOARCH:
| Architecture | $GOARCH |
|---|---|
| x386 | 386 |
| AMD64 | amd64 |
| AMD64 с 32-указателями | amd64p32 |
| ARM | arm |
Пример 1. Веб-сервер, написанный и собранный в Linux для Windows
Напишем простенький веб-сервер, который в Go писать проще, чем в некоторых языках/библиотеках парсить командную строку.
И соберем его для Windows 32- и 64-bit:
Думаю, не нужно говорить, что оба бинарника готовы к копированию на целевую Windows-систему и будут работать.
Пример 2. Кросс-компиляция под ARM для телефона Nokia N9
Сразу скажу, что сейчас я с embedded-девайсами плотно не работаю, поэтому могу какие-то детали не знать — так что постараюсь не углубляться в эту тему, но в целом за ситуацией с Go на embedded слежу. Вообще говоря, Go не позиционировался как язык для embedded-платформ, что, впрочем, не помешало народу активно начать его использовать в этой области. Возможно, причина в том, что embedded-индустрия сделала скачок вперед, и теперь «встраиваемое» устройство уже не означает критически малое количество ресурсов, а возможно компромиссы не в пользу экономии памяти в Go оказались гораздо менее ощутимыми на практике, но факт есть факт — для Go уже создано масса проектов вроде Gobot (robotics-фреймворк для целой кучи платформ — от Arduino, Raspberry PI и Beaglebone Back до LeapMotion, Pebble и ArDrone) или EMBD (фреймворк для работы с hobby-бордами), а PayPal уже пару лет использует Go в своем beacon-девайсе для беспроводных чекинов и платежей.
Для примера возьмем Nokia N9 (или N950, кому повезло) — и соберем вышеприведенный пример для него:
Для ARM-платформ, на самом деле, может понадобиться еще указывать флаг GOARM, но тут, если версия по-умолчанию не подходит, бинарник на целевой платформе выдаст понятное сообщение, вроде такого:
Автоматизируем процесс
Казалось бы, что может быть проще указания одной переменной перед go build. Но есть ситуации, когда код нужно собирать и деплоить на разные платформы по 100 раз в день. Для таких задач есть несколько проектов, для автоматизации процессов подготовки toolchain-ов и, непосредственно, сборки кода под нужную платформу.
Ссылка: github.com/mitchellh/gox
Инсталляция и подготовка сразу всех возможных toolchain-ов:
Теперь, вместо «go build», пишем «gox»:
Можно указывать конкретный пакет или конкретную платформу:
Остальные аргументы командной строки идентичны go build. Достаточно интуитивно.
Разбираемся с CGO
Если кто-то смотрел видео с конференции GopherCon 2014, которая проходила прошлой весной в Денвере, то, возможно, помнит выступление Alan Shreve «Build Your Developer Tools in Go» — и одну из вещей, которую он говорит достаточно категорично: «не используйте кросс-компиляцию, компилируйте нативно». Дальше идет объяснение — причина в Cgo. Если вам не нужно использовать cgo — все окей. И на самом деле, очень малая часть очень специфичного кода в Go нуждается в сторонних С-библиотеках. В чем же проблема?
Проблема в том, что некоторые функции стандартной библиотеки зависят от cgo. Тоесть, если мы собираем Go с CGO_ENABLED=0, они просто не будут доступны и на этапе компиляции мы получим ошибку. Несмотря на то, что тут есть очень удобный и красивый workaround, давайте разберемся, что же именно в стандартной библиотеке зависит от cgo.
К счастью, сделать это просто:
// goLookupIP is the native Go implementation of LookupIP.
// Used only if cgoLookupIP refuses to handle the request
// (that is, only if cgoLookupIP is the stub in cgo_stub.go).
// Normally we let cgo use the C library resolver instead of
// depending on our lookup code, so that Go and C get the same
// answers.
goLookupIP фактически резолвит только по Hosts-файлу и по DNS-протоколу, что для большинства систем — ок. Но могут быть проблемы, если в системе будут использоваться нестандартные методы резолвинга имён. Полагаю, что в 99% случаев, hosts и dns будут более, чем достаточно.
Первая часть (с X.509) на самом деле не такая уж редкая. Если я правильно понимаю — этот код нужен, если ваша программа использует стандартный net/http.StartAndListenTLS() — и вы используете реальные сертификаты, которые реально нужно проверять.
Поэтому вкратце о простом workaround вокруг этой темы — называется он gonative, и делает одну простую вещь — скачивает с официального сайта бинарные версии golang нужной версии для нужной платформы, в которой уже есть скомпилированные бинарники всех стандартных пакетов и, фактически, завершает процесс «собрать toolchain с cgo-кодом».
Всё что нужно сделать, это установить её (go get github.com/inconshreveable/gonative) и выполнить одну простую команду:
И дальше использовать стандартные процедуры кросскомпиляции, как и раньше, ручками или через gox/gocx.
Подробнее о gonative тут: inconshreveable.com/04-30-2014/cross-compiling-golang-programs-with-native-libraries
Практическое применение
Но тут возникает следующий момент — раз кросс-компиляция и деплой становятся такими простыми и быстрыми, появляется стимул все зависимости от файлов — будь-то конфиги, сертификаты или что угодно еще — встраивать в бинарник тоже. Впрочем, это достаточно простая задача, даже для сторонних библиотек, благодаря эффективному использованию io.Reader интерфейса и пакету go-bindata, но это уже тема для отдельной статьи.
Надеюсь, ничего из главного не упустил.
Но в целом это на самом деле очень существенная разница со всем предыдущим опытом кросс-сборки. Если честно, я до сих пор не привык к этой перемене. Больше не нужны виртуалки с настроенной dev-средой, не нужны докер-имиджи для сборки — да вообще dev-environment отпадает как таковой. Это слишком резкий game changer, чтобы так быстро привыкнуть.
Сборка приложений Go для разных операционных систем и архитектур
При разработке программного обеспечения важно учитывать операционную систему и базовую архитектуру процессора, для которой нужно скомпилировать двоичный файл. Поскольку запуск двоичного файла на платформе с другой ОС или архитектурой зачастую происходит медленно (если его вообще возможно обработать), принято собирать двоичный код для множества различных платформ, чтобы максимально увеличить аудиторию программы. Однако это может быть сложно, если платформа, которую вы используете для разработки, отличается от платформы, на которой вы хотите развернуть свою программу. В прошлом, например, разработка программы для Windows и ее развертывание на Linux или macOS требовали настройки компьютеров сборки для каждой из этих сред, для которых нужно было собрать двоичные файлы. Вам также необходимо синхронизировать инструменты, а также обратить внимание на ряд других аспектов, которые могут повысить расход ресурсов и затруднить совместное тестирование и распространение.
Go решает эту проблему путем встроенной поддержки нескольких платформ непосредственно в инструмент сборки go build (и в остальную часть цепочки инструментов Go). Используя переменные среды и теги сборки, вы можете контролировать, для какой ОС и архитектуры создается окончательный двоичный файл (а также объединить рабочий процесс, что позволит быстро переключать добавление зависимого от платформы кода без изменения вашей кодовой базы).
В этом мануале мы соберем тестовое приложение, которое объединяет строки в путь к файлу, создает и выборочно включает зависимые от платформы фрагменты и собирает двоичные файлы для нескольких операционных систем и архитектур в своей системе. Так вы научитесь использовать эту мощную возможность языка программирования Go.
Требования
Для работы вам понадобится среда разработки Go:
Доступные платформы для GOOS и GOARCH
Прежде чем учиться управлять процессом сборки бинарных файлов для разных платформ, давайте посмотрим, для каких платформ Go может собирать файлы и как Go ссылается на эти платформы с помощью переменных среды GOOS и GOARCH.
Инструментарий Go содержит команду, которая может вывести список доступных платформ для Go. Этот список может меняться с каждым новым релизом Go, поэтому обсуждаемые здесь комбинации могут не совпадать в другой версией Go. На момент написания этого мануала последней является версия Go 1.13.
Чтобы просмотреть список платформ, выполните следующую команду:
Вы получите подобный вывод:
aix/ppc64 freebsd/amd64 linux/mipsle openbsd/386
android/386 freebsd/arm linux/ppc64 openbsd/amd64
android/amd64 illumos/amd64 linux/ppc64le openbsd/arm
android/arm js/wasm linux/s390x openbsd/arm64
android/arm64 linux/386 nacl/386 plan9/386
darwin/386 linux/amd64 nacl/amd64p32 plan9/amd64
darwin/amd64 linux/arm nacl/arm plan9/arm
darwin/arm linux/arm64 netbsd/386 solaris/amd64
darwin/arm64 linux/mips netbsd/amd64 windows/386
dragonfly/amd64 linux/mips64 netbsd/arm windows/amd64
freebsd/386 linux/mips64le netbsd/arm64 windows/arm
Эти выходные данные представляют собой набор пар ключ-значение, разделенных символом /. Первая часть комбинации, перед слешем – это операционная система. В Go операционные системы являются доступными значениями для переменной среды GOOS, что означает Go Operating System. Вторая часть, после слеша, это архитектура. Эта часть показывает доступные значения для переменной среды GOARCH, что означает Go Architecture.
Давайте разберем одну из этих комбинаций, чтобы понять, что она означает и как она работает. Для примера можно взять пару linux/386. Пара ключ-значение начинается с GOOS, в этом примере это linux, что ссылается на ОС Linux. GOARCH здесь – 386, что указывает на микропроцессор Intel 80386.
Существует много платформ, доступных с помощью команды go build, но в основном в качестве значения GOOS вы будете использовать linux, windows или darwin. Они охватывают три большие платформы ОС: Linux, Windows и macOS, которая основаны на операционной системе Darwin и поэтому называются darwin. Однако Go может охватывать и менее распространенные платформы, такие как nacl, Google’s Native Client.
Когда вы запускаете команду типа go build, Go использует GOOS и GOARCH текущей платформы, чтобы определить, как собирать двоичный файл. Чтобы узнать, какая комбинация подходит вашей платформе, вы можете использовать команду go env и передать GOOS и GOARCH в качестве аргументов:
go env GOOS GOARCH
Мы запустили эту команду на macOS, на машине с архитектурой AMD64, поэтому мы получили такой вывод:
Здесь выходные данные команды говорят нам, что система имеет переменные GOOS=darwin и GOARCH=amd64.
Теперь вы знаете, что такое GOOS и GOARCH в Go, а также можете определять их допустимые значения. Далее мы соберем тестовую программу, чтобы показать, как использовать эти переменные среды, и создадим теги для сборки двоичных файлов для других платформ.
Создание зависимой от платформы программы с помощью filepath.Join()
Прежде чем приступить к созданию бинарных файлов для других платформ, давайте создадим простую тестовую программу. Для этого можно использовать функцию Join, которая доступна в пакете path/filepath стандартной библиотеки Go. Эта функция принимает несколько строк и возвращает одну строку, которая соединяется правильным разделителем пути к файлу.
Это хорошая тестовая программа, потому что ее работа зависит от того, на какой ОС она запускается. В Windows в качестве разделителя пути используется обратный слеш, \, а в Unix-системах используется обычный слеш /.
Начнем с создания приложения, которое использует filepath.Join(). Позже вы напишете собственную реализацию функции Join(), которая настраивает код для двоичных файлов платформы.
Сначала в каталоге src создайте папку и назовите ее именем вашего приложения:
Затем создайте в текстовом редакторе новый файл по имени main.go.
Когда файл откроется, добавьте следующий код:
package main
import (
«fmt»
«path/filepath»
)
func main() <
s := filepath.Join(«a», «b», «c»)
fmt.Println(s)
>
Функция main() в этом файле использует filepath.Join() для объединения трех строк с помощью правильного, зависимого от платформы разделителя пути.
Сохраните и закройте файл, затем запустите программу:
При запуске этой программы вы получите уникальный вывод – он зависит от используемой вами платформы. В Windows вы увидите строки, разделенные обратным слешем, \:
В системах Unix, таких как macOS и Linux, вы получите следующее:
Как видите, из-за разных протоколов файловой системы, используемых в этих операционных системах, программе придется создавать разный код для разных платформ. Но поскольку программа уже использует разные разделители файлов в зависимости от ОС, мы знаем, что filepath.Join() уже учитывает разницу в платформах. Это связано с тем, что цепочка инструментов Go автоматически обнаруживает GOOS и GOARCH вашего компьютера и использует эту информацию для выбора фрагмента кода с правильными тегами сборки и разделителем файлов.
Давайте посмотрим, где функция filepath.Join() находит разделитель. Запустите следующую команду, чтобы проверить соответствующий фрагмент из стандартной библиотеки Go:
Эта команда вернет содержимое path_unix.go. Найдите в нем эту часть:
В этом разделе определяется PathSeparator для всех разновидностей Unix-подобных систем, которые поддерживает Go. Обратите внимание на все теги сборки в верхней части, которые отображают все доступные платформы Unix GOOS,. Когда GOOS соответствует этим условиям, ваша программа выдает разделитель пути к файлу в стиле Unix.
Нажмите q, чтобы вернуться в командную строку.
Затем откройте файл, который определяет поведение filepath.Join() в Windows:
Вы увидите следующее:
Хотя значение PathSeparator здесь \\, код будет отображать один обратный слеш (\), необходимый для файловых путей Windows, а первый слеш здесь используется только в качестве escape-символа.
Обратите внимание: в отличие от файла Unix, в верхней части этого файла нет тегов сборки. Это связано с тем, что GOOS и GOARCH можно также передать в сборку, добавив подчеркивание (_) и значение переменной среды в качестве суффикса к имени файла (о чем мы поговорим подробнее в следующих разделах мануала). Здесь часть _windows в path_windows.go заставляет файл действовать так, как если бы он имел тег сборки // +build windows в верхней части файла. Поэтому когда программа запускается в Windows, она будет использовать константы PathSeparator и PathListSeparator из фрагмента кода path_windows.go.
Чтобы вернуться в командную строку, нажмите q.
Итак, вы создали программу, которая показала, как Go автоматически преобразует GOOS и GOARCH в теги сборки. Имея это в виду, вы теперь можете обновить свою программу и написать собственную реализацию функции filepath.Join(), используя теги сборки, чтобы вручную установить правильный PathSeparator для платформ Windows и Unix.
Реализация функции, зависимой от платформы
Теперь, когда вы знаете, как стандартная библиотека Go реализует специфичный для платформы код, вы можете использовать теги сборки, чтобы сделать это в своей собственной программе. Для этого напишите собственную реализацию filepath.Join().
Откройте файл main.go:
Замените содержимое main.go на следующее, используя вашу собственную функцию Join():
Функция Join принимает несколько parts и соединяет их вместе, используя метод strings.Join() из пакета strings, чтобы объединить части пути в одну строку с помощью PathSeparator.
Вы еще не определили PathSeparator. Сделайте это сейчас в другом файле. Сохраните и выйдите из main.go, откройте ваш редактор и создайте новый файл path.go:
Определите PathSeparator и задайте разделитель пути файла Unix, /:
package main
const PathSeparator = «/»
Скомпилируйте и запустите приложение:
Вы получите следующий вывод:
Все работает, и вы можете получить путь к файлу в стиле Unix. Но это не все, чего мы хотим: сейчас выводится только a/b/c, независимо от того, на какой платформе работает программа. Чтобы добавить функциональность для создания файловых путей в стиле Windows, вам необходимо добавить версию PathSeparator для Windows и сообщить команде go build, какую версию использовать. В следующем разделе мы применим теги сборки для достижения этой цели.
Использование тегов сборки GOOS или GOARCH
Для учета платформ Windows мы создадим альтернативный файл path.go и будем использовать теги сборки, чтобы фрагменты кода выполнялись только тогда, когда в GOOS и GOARCH указана подходящая платформа.
Сначала добавьте тег сборки в path.go, чтобы обозначить, что он собирается для всех платформ, кроме Windows. Откройте файл:
Добавьте следующий выделенный тег сборки в файл:
Теги сборки Go позволяют инвертировать (то есть вы можете настроить Go для сборки этого файла для любой платформы, кроме Windows). Чтобы инвертировать тег сборки, поместите перед ним восклицательный знак.
Сохраните и закройте файл.
Теперь, если вы запустите эту программу в Windows, вы получите следующую ошибку:
./main.go:9:29: undefined: PathSeparator
В этом случае Go не может включить path.go для определения переменной PathSeparator.
Теперь, когда вы убедились, что path.go не будет работать, если в GOOS указана система Windows, добавьте новый файл windows.go:
В windows.go определите PathSeparator, а также тег сборки, чтобы команда go build знала, что это реализация Windows:
// +build windows
package main
const PathSeparator = «\\»
Сохраните файл и выйдите из текстового редактора. Теперь приложение может компилироваться одним способом для Windows, а другим – для всех других платформ.
Хотя двоичные файлы теперь будут правильно собираться для разных платформ, необходимо внести дополнительные изменения, чтобы скомпилировать файлы для платформы, к которой у вас нет доступа. Для этого нужно изменить локальные переменные среды GOOS и GOARCH.
Использование локальных переменных GOOS и GOARCH
Ранее вы запускали команду go env GOOS GOARCH, чтобы выяснить, с какой ОС и архитектурой вы работали. Запущенная нами команда go env искала две переменные окружения GOOS и GOARCH; если она находит значения, она их использует, но если их нет, Go установит в них информацию для текущей платформы. Так вы можете изменить GOOS или GOARCH и установить значения, которые не относятся к вашей локальной ОС и архитектуре по умолчанию.
Команда go build ведет себя аналогично команде go env. Вы можете установить переменные среды GOOS или GOARCH для сборки для другой платформы, используя go build.
Если на локальной машине вы не используете систему Windows, создайте двоичный файл приложения, установив для переменной среды GOOS значение windows при запуске команды go build:
GOOS=windows go build
Теперь просмотрите файлы в вашем текущем каталоге:
Вывод показывает, что в каталоге проекта теперь есть исполняемый файл app.exe для Windows:
app app.exe main.go path.go windows.go
С помощью команды file вы можете получить больше информации об этом файле, в том числе и о его сборке:
file app.exe
app.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows
Вы также можете установить одну или обе переменные среды во время сборки. Запустите следующее:
GOOS=linux GOARCH=ppc64 go build
Ваш исполняемый файл приложения будет заменен файлом для другой архитектуры. Запустите команду file для этого двоичного файла:
Вы получите подобный вывод:
app: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, not stripped
Установив локальные переменные среды GOOS и GOARCH, вы можете создавать двоичные файлы для любой из совместимых платформ Go без сложной конфигурации или настройки. Далее вы научитесь использовать соглашения об именах файлов, чтобы ваши файлы были аккуратно организованы и автоматически собирались для конкретных платформ без тегов сборки.
Суффиксы имен GOOS и GOARCH
Как вы видели ранее, стандартная библиотека Go активно использует теги сборки для упрощения кода путем разделения реализаций разных платформ на разные файлы. Когда вы открыли файл os/path_unix.go, вы видели тег сборки, перечисляющий все возможные комбинации, которые считаются Unix-подобными платформами. Однако файл os/path_windows.go не содержал тегов сборки, поскольку суффикса имени файла было достаточно, чтобы указать Go, для какой платформы предназначен файл.
Обновите вашу программу, добавьте суффиксы имен файлов вместо тегов сборки. Сначала переименуйте файлы path.go и windows.go, чтобы использовать соглашение пакета os:
mv path.go path_unix.go
mv windows.go path_windows.go
Изменив имена двух фалов, вы можете удалить тег сборки, который вы добавили в path_windows.go:
Удалите // + build windows, чтобы ваш файл выглядел так:
package main
const PathSeparator = «\\»
Поскольку unix не является действительным значением GOOS, суффикс _unix.go ничего не значит для компилятора Go. Однако он передает предполагаемую цель файла. Как и в os/path_unix.go, в файле path_unix.go должны использоваться теги сборки, поэтому оставьте этот файл без изменений.
Следуя соглашению имен, вы можете удалить ненужные теги сборки из кода и сделать файловую систему чище.
Заключение
Возможность генерировать для нескольких платформ двоичные файлы, не требующие зависимостей – важная функция набора инструментов Go. В этом мануале вы научились использовать эту возможность через теги сборки и суффиксы имен файлов. Это позволяет пометить определенные фрагменты кода для компиляции только в файлах определенных архитектур. Вы создали свою собственную зависимую от платформы программу, а затем с помощью переменных среды GOOS и GOARCH сгенерировали двоичные файлы для других платформ. Это ценный навык, поскольку его можно использовать в процессе непрерывной интеграции: он автоматически читает переменные среды для создания двоичных файлов для всех платформ.