Чтобы уточнить ответ jnml в:
При использовании import "foo/bar"
в вашем коде, вы не ссылаясь на исходные файлы (которые будут расположены в $GOPATH/src/foo/bar/
).
Вместо этого вы ссылаетесь на скомпилированный файл пакета по адресу $GOPATH/pkg/$GOOS_$GOARCH/foo/bar.a
. Когда вы создаете свой собственный код, и компилятор обнаруживает, что пакет foo/bar
еще не скомпилирован (или устарел), он сделает это за вас автоматически.
Он делает это путем сопоставления всех соответствующих исходных файлов в каталоге $GOPATH/src/foo/bar
и построения их в один файл bar.a
, который он устанавливает в каталоге pkg. Затем компиляция возобновляется с вашей собственной программой.
Этот процесс повторяется для всех импортированных пакетов и пакетов, импортированных этими пользователями, вплоть до цепочки зависимостей.
*) Как сортируются файлы, зависит от того, как назван файл и какие теги сборки присутствуют внутри него.
Для более глубокого понимания того, как это работает, обратитесь к build docs.
@elithrar: Не верно. Область видимости файла и область пакета - разные области. Например, импорт имеет только область пакета, поэтому сложение всех исходных файлов пакета вместе не работает в общем случае. – zzzz
@jnml okay, поэтому его в основном, как и все файлы, объединены в один большой файл, с правилами области действия, указанными в ссылке, которую вы указали ниже, не так ли? – pymd
@nomad: Я так не думаю. Спецификаторы импорта являются файлами и не могут быть воспроизведены путем присоединения файлов к одному. IOW, например, идентификатор 'template' может ссылаться на пакет 'text/template' в одном файле, но для пакета 'html/template' в другом файле. Эта область не может быть «поднята» до области пакета. – zzzz