Организация кодекса Голанга для многоплатформенного многоязычного проекта

Я ищу хорошую организацию проекта для многоплатформенного проекта с несколькими компонентами, написанными на Go. Я знаю рекомендуемый макет от http://golang.org/doc/code.html, но предложенный там макет, похоже, не соответствует моим требованиям.Организация кодекса Голанга для многоплатформенного многоязычного проекта

Компоненты проекта являются:

сервер (написанный в Go)
клиента, кросс-платформенный (Go)
библиотека, совместно между сервером и клиентом (Go)
несколько больше клиентов (IOS, Android)

Мои требования:

Все компоненты в одном хранилище git
Храните компоненты отдельно (например. один каталог на компонент)
компоненты Go могут быть структурированы в нескольких суб-пакетов

Мой текущий подход:

project/ (this is the repository root) 
    server/ 
    server.go (package main) 
    src/   
     server/ 
     package1/ 
      package1.go 
     ... 
    client/ 
    client.go (package main) 
    src/ 
     client/ 
     package2/ 
      package2.go 
     ... 
    lib/ 
    src/ 
     lib/ 
     lib.go 
     ... 
    client-ios/ 
    ... 
    client-android/ 
    ...

Чтобы построить, я использую Makefile, который

Копии lib/на сервер и клиент/
Создает сервер и клиент/отдельно, каждый раз устанавливая GOPATH на r соответствующий каталог.

Он работает, но чувствует себя действительно klunky и сильно отличается от рекомендуемого макета кода.

Вот альтернатива я рассматриваю:

project/ (this is the repository root) 
    gospace/ 
    src/ 
     server/... 
     client/... 
     lib/... 
    client-ios/ 
    ... 
    client-android/ 
    ...

При такой схеме у меня есть один GOPATH (gospace /) и не нуждаются в klunky Makefile. Однако компоненты не разделяются так же аккуратно, как в первом варианте (то есть через каталог верхнего уровня).

Мой вопрос: Какой макет проекта лучше всего подходит как для моих требований, так и для соглашений Go и поддержки инструментов? Есть ли лучшие варианты, которые я еще не видел?

источник

2014-02-06 henning77

Почему бы не '$ GOPATH/src/gospace/{server, client, lib, ios, android}'. Типичная структура GOPATH - $ GOPATH/{src, bin, pkg}. Таким образом, легко просто «запустить gospace/server» или «gospace/client» из любого места на вашем GOPATH. – elithrar

Это хорошая альтернатива, так как все компоненты находятся на одном уровне. Чуть немного странно вставлять ios и android в рабочее пространство Go под управлением src.ios и android имеют собственную структуру подкаталогов со своими собственными src dirs и т. д. и не связаны с Go. – henning77

Вы можете проверить свое репо под GOPATH (путь будет похож на GOPATH/src/project/{gospace, client-ios, client-android}). Поскольку go не будет касаться клиентских * каталогов, пока вы не попросите его сделать это, они будут счастливо жить вместе в этом каталоге. В качестве бонуса ваш проект станет 'go get'able. – mechmind

Это, как я организовал подобный проект:

$GOPATH/src/project-root/ 
    lib.go 
    lib_test.go 

    server/ 
     server.go 
     server_test.go 

     main/ 
      server.go // package main; import "project-root/server" 

    client/ 
     client.go 
     client_test.go 

     main/ 
      client.go //package main; import "project-root/client" 

    client-ios/ 
     .... 

    client-android/ 
     ....

В то время как в основном имеющие server/server.go и client/client.go, как package main должны работать, то лучше, чтобы отделить его, чтобы вы могли встраивать клиент/сервер в других проектах.

источник

2014-04-16 00:09:29 OneOfOne

Организация кодекса Голанга для многоплатформенного многоязычного проекта

ответ

Смежные вопросы