Краткий обзор тегов сборки Go
Распространенной проблемой, с которой я сталкиваюсь при написании библиотеки Go, является управление поддержкой нескольких платформ. Первые библиотеки, которые я создал, имели ужасную кроссплатформенную совместимость. Однако это было результатом плохого кода. Например, я объединил строки пути к файлу с помощью оператора +. Это привело к тому, что некоторые функции не работали вообще. Хотя мне удалось решить проблему. Я импортировал пакет file/filepath , который уже поддерживает несколько сред ОС, чтобы исправить проблему. В этом посте я попытаюсь написать библиотеку. Эта библиотека проверит, установлена ли определенная программа. Я выбрал эту проблему, поскольку операционные системы Windows и Unix размещают программы в разных местах файлов.
Библиотека
Чтобы создать эту библиотеку, я позаимствую некоторые принципы из Test Driven Development (TDD). Имея это в виду, я начну с написания модульного теста. Этот модульный тест проверит, возвращает ли функция правильное имя операционной системы. Я реализую фактическую функцию, которую я тестирую, позже. Тест определит требования к функции, и я буду обновлять функцию до тех пор, пока тест не пройдет. Вот код для теста:
Первая строка файла, определенного выше, является тегом сборки. Я могу передать теги сборки команде go test для выполнения определенного теста. Это полезно, потому что этот тест не будет запускаться автоматически с помощью команды go test. Например, тест Windows обречен на провал на компьютере Unix. Я выполню следующую команду, чтобы запустить тест выше:
go test --tags=unix_test
Тест провалится, так как я не определил функцию FindExe. Для начала я определю Unix-версию функции. Вот код для этого:
Первые строки файла — это теги сборки. Он скомпилирует этот файл, если целевой ОС является Linux или MacOS. Функция вернет 2 строки. Один из них — путь к программе, которую я ищу, а другой — имя операционной системы. В этом случае имя операционной системы всегда Unix. В духе TDD пришло время запустить мои тесты:
Теперь, когда функциональность Unix заработала, пришло время добавить поддержку Windows. Начну с написания теста. Тестовый файл будет иметь тег сборки windows_test . Вот код для этого теста:
Имея необходимые требования, я приступлю к определению реализации функции FindExe в Windows. Этот файл будет иметь тег сборки, чтобы указать Windows в качестве цели сборки. Вот код, выполняющий это:
Первая строка файла укажет компилятору выполнять сборку только в том случае, если целевой ОС является Windows. Вот как мне удается избежать дублирования имен функций в пакете, который я пишу. Возвращаемый путь к файлу значительно отличается от реализации Unix. Вот почему теги сборки полезны, без них мне пришлось бы давать своим функциям имена, ориентированные на ОС, или втиснуть несколько операторов «если». Теперь пришло время запустить тесты Windows с соответствующим тегом сборки:
go test --tags=windows_test
Как и ожидалось, команда завершится ошибкой. В тесте используется реализация unix FindExe , которая возвращает Unix в качестве имени операционной системы.
Заключение
Еще в 2016 году я попытался создать фреймворк Go. Первая версия библиотеки имела ужасную/отсутствие поддержки Windows. Я полагал, что с Go работает больше Linux-разработчиков. Я ошибся, потому что после добавления поддержки Windows во фреймворк количество загрузок увеличилось. На сегодняшний день большинство пользователей фреймворка используют Windows. Вот график, иллюстрирующий эти данные:
Есть и другие способы добиться кросс-платформенной поддержки без тегов сборки. В стандартной библиотеке Go есть пакеты, предназначенные для нескольких операционных систем. Одним из примеров является пакет file/filepath . Он имеет функцию под названием «Присоединиться». Функция объединяет набор частей пути с правильным разделителем пути.
Вы можете найти ссылку на библиотеку, написанную в этом посте ниже.
