Комментарии 13
Можно вопрос не по теме топика, но по теме Go.
Вопрос по организации кода.
У меня на машине такая структура:
Как должна быть организована структуру кода на Go? Я читал официальную и не официальную документацию.
В Go Есть понятие Workspaces. Которые содержат в себе следующую структуру
— src
— pkg
— bin
Что это такое? Каждый Workspace это отдельный проект на Go и в каждом проекте должна быть структура как выше? Для каждого проекта на Go путь до него обязательно добавлять в $PATH?
Такая банальная вещь, но в доках и других туториалах на этот вопрос нет очевидного ответа.
Буду признателен за ответ.
Вопрос по организации кода.
У меня на машине такая структура:
Projects ---ASP.NET ---Proj1 ---Proj2 ---PHP ---Proj1 ---Proj2 ---GO --- ???
Как должна быть организована структуру кода на Go? Я читал официальную и не официальную документацию.
В Go Есть понятие Workspaces. Которые содержат в себе следующую структуру
— src
— pkg
— bin
Что это такое? Каждый Workspace это отдельный проект на Go и в каждом проекте должна быть структура как выше? Для каждого проекта на Go путь до него обязательно добавлять в $PATH?
Такая банальная вещь, но в доках и других туториалах на этот вопрос нет очевидного ответа.
Буду признателен за ответ.
Ну как же нет? golang.org/doc/code.html#Workspaces
В 90% случаев вы один раз в жизни устанавливаете свой рабочий workspace — GOPATH=C:\Projects\GO (в вашем примере) и работаете в этой директории. К примеру, ваши проекты могут быть в:
C:\Projects\GO\src\test\mytestprj\
C:\Projects\GO\src\github.com\paco\mycoolprj\
Можно писать код и вне GOPATH, но все сторонние пакеты которые вы будете использовать (и ставить через go get) — будут сохраняться именно в GOPATH\src и оттуда браться компилятором.
В src хранятся исходные коды. В pkg — скомпилированные бинарные версии пакетов, которые предназначены для линковки (библиотеки, другими словами). В bin — скомпилированные файлы для исполнения (бинарники). $GOPATH/bin удобно добавить в PATH, потому как тогда легко инсталлировать внешние Go-программы (ту же go-bindata) одним телодвижением — go install — и оно готово к использованию в вашей системе.
В 90% случаев вы один раз в жизни устанавливаете свой рабочий workspace — GOPATH=C:\Projects\GO (в вашем примере) и работаете в этой директории. К примеру, ваши проекты могут быть в:
C:\Projects\GO\src\test\mytestprj\
C:\Projects\GO\src\github.com\paco\mycoolprj\
Можно писать код и вне GOPATH, но все сторонние пакеты которые вы будете использовать (и ставить через go get) — будут сохраняться именно в GOPATH\src и оттуда браться компилятором.
В src хранятся исходные коды. В pkg — скомпилированные бинарные версии пакетов, которые предназначены для линковки (библиотеки, другими словами). В bin — скомпилированные файлы для исполнения (бинарники). $GOPATH/bin удобно добавить в PATH, потому как тогда легко инсталлировать внешние Go-программы (ту же go-bindata) одним телодвижением — go install — и оно готово к использованию в вашей системе.
Благодарю за ответ. Разбитие namespace по папкам внутри src конечно не привычно.
Непривычно?
Это же классический java-style, а в PHP подобное поведение описывается в PSR4, не знаю правда что там с ASP.NET, но больее чем уверен что такая организация кода вполне возможна, и всякие гуру-папки активно ее используют, потому что не надо лишних слов — просто заставь имена пакетов и папок на диске кореллировать между собой.
Это же классический java-style, а в PHP подобное поведение описывается в PSR4, не знаю правда что там с ASP.NET, но больее чем уверен что такая организация кода вполне возможна, и всякие гуру-папки активно ее используют, потому что не надо лишних слов — просто заставь имена пакетов и папок на диске кореллировать между собой.
Но тут возникает следующий момент — раз кросс-компиляция и деплой становятся такими простыми и быстрыми, появляется стимул все зависимости от файлов — будь-то конфиги, сертификаты или что угодно еще — встраивать в бинарник тоже
+100500
У Меня тоже возник такой соблазн
Более того я это соблазну подался!!! И веб-морду (index.html) воткнул в виде зашифрованной в base64 строки
const indexPageD = "PCFkb2N0eXBlIGh0bWw+DQo8aHRtbD4NCg0KPGhlYWQ+DQoJPHRpdGxlPldlYlRvcDwvdGl0bGU+DQoJP
......
func (service *TopJsonService) ServePage(responseWriter http.ResponseWriter, request *http.Request) {
responseWriter.Header().Set("Content-Type: text/html", "*")
content, err := ioutil.ReadFile("index.html")
if err != nil {
val, _ := base64.StdEncoding.DecodeString(indexPageD)
responseWriter.Write(val)
return
}
responseWriter.Write(content)
}
github.com/Loafter/WebTop/blob/master/WebService.go
Вообще очень полезные вы статии пишите.
Кстати я не понимаю как еще полностью статически слинокованный дистрибутив линукс еще не вышел
Если вам нравится всё встраивать в бинарник, посмотрите проект go.rice, очень удобная штука :)
Можно целые папки автоматически встраивать, а во время разработки — читать из файла.
Можно целые папки автоматически встраивать, а во время разработки — читать из файла.
JFYI ещё одна либа для встраивания всякой внешней статики в бинарник github.com/rakyll/statik
Больше либ хороших и разных.
Больше либ хороших и разных.
Спасибо)
Ну, в base64 засовывать — это не очень продуктивно в общем случае. Лучше таки или go-bindata (+go-bindata-assetfs) или go-rice использовать.Тем более, что c go generate их еще удобнее стало использовать.
Ну, в base64 засовывать — это не очень продуктивно в общем случае. Лучше таки или go-bindata (+go-bindata-assetfs) или go-rice использовать.Тем более, что c go generate их еще удобнее стало использовать.
НЛО прилетело и опубликовало эту надпись здесь
Может кто сможет заставить работать influxdb под windows? Смог скомпилировать, даже запускается, но не делает того что надо.
github.com/influxdb/influxdb/blob/master/docs/contributing.md
Тоже написано на Go. Но почему-то их команда упорно игнорирует windows.
github.com/influxdb/influxdb/blob/master/docs/contributing.md
Тоже написано на Go. Но почему-то их команда упорно игнорирует windows.
Про GO386 забыли
Иначе вроде i386 а на athlon xp без sse2 не запустится!
В нете очень много i386 или x86 скомпилированных под >=sse2 и *i386*.deb в том числе.
$GO386 (for 386 only, default is auto-detected if built on either 386 or amd64, 387 otherwise)
This controls the code generated by gc to use either the 387 floating-point unit (set to 387) or SSE2 instructions (set to sse2) for floating point computations.
GO386=387: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).
GO386=sse2: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later.
Иначе вроде i386 а на athlon xp без sse2 не запустится!
В нете очень много i386 или x86 скомпилированных под >=sse2 и *i386*.deb в том числе.
$GO386 (for 386 only, default is auto-detected if built on either 386 or amd64, 387 otherwise)
This controls the code generated by gc to use either the 387 floating-point unit (set to 387) or SSE2 instructions (set to sse2) for floating point computations.
GO386=387: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).
GO386=sse2: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later.
SSE2 Не поддерживают:
Поскольку SSE2 — расширение IA-32, процессоры, не поддерживающие IA-32, не поддерживают SSE2. Все известные процессоры x86-64 также поддерживают SSE2.
Кроме того, не поддерживают IA-32-совместимые процессоры, появившиеся до SSE2:
Все AMD до Athlon 64
Все Intel до Pentium 4
VIA C3
Transmeta Crusoe
PS т.е. i386 точно работает на x86-64.
Поскольку SSE2 — расширение IA-32, процессоры, не поддерживающие IA-32, не поддерживают SSE2. Все известные процессоры x86-64 также поддерживают SSE2.
Кроме того, не поддерживают IA-32-совместимые процессоры, появившиеся до SSE2:
Все AMD до Athlon 64
Все Intel до Pentium 4
VIA C3
Transmeta Crusoe
PS т.е. i386 точно работает на x86-64.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кросс-компиляция в Go