Макет директории с исходным кодом на разных языках

Question

Мы работаем над большим проектом на нескольких языках: Java, Python, PHP, SQL и Perl.

До сих пор люди работали в своих личных хранилищах, но теперь мы хотим объединить весь проект в одном хранилище. Теперь возникает вопрос: как должна выглядеть структура каталогов? Должны ли мы иметь отдельные каталоги для каждого языка или мы должны разделить их по компонентам / проектам? Насколько хорошо python / perl / java справляется с общей структурой каталогов?

Answer 1

Мой опыт показывает, что этот вид макета лучше всего:

mylib/
    src/
       java/
       python/
       perl/
       .../
    bin/
       java/
       python/
       perl/
    stage/
    dist/

src ваш источник, и единственное, что зарегистрировано.

bin - это место, где происходит «компиляция» во время сборки, и оно не зарегистрировано.

stage - это место, где вы копируете вещи во время сборки, чтобы подготовить их к упаковке

dist - это место, куда вы кладете артефакты сборки

Я поместил модуль / компонент / библиотеку на вершину иерархии, потому что я строю каждый модуль отдельно и использую менеджер зависимостей, чтобы объединить их при необходимости.

Конечно, соглашения об именах могут быть разными. Но я нашел, что это работает вполне удовлетворительно.

Answer 2

Я думаю, что лучше всего было бы убедиться, что ваши различные модули не зависят от того, находятся ли они в одном и том же каталоге (то есть разделены по компонентам). Многие люди, кажется, смертельно боятся этой идеи, но хороший набор сценариев сборки должен быть в состоянии автоматизировать любую боль.

Конечной целью было бы упростить установку инфраструктуры, а затем действительно легко работать с одним компонентом после настройки среды.

(Важно отметить, что я пришел из миров Perl и CL, где мы устанавливаем «модули» в некое глобальное расположение, например ~ / perl или ~ / .sbcl, вместо того, чтобы включать каждый модуль в каждый проект, например в Java люди думают. Вы могли бы подумать, что это будет проблема с обслуживанием, но в конечном итоге это не так. С помощью скрипта, который регулярно обновляет каждый модуль из вашего репозитория git (или CPAN), это действительно лучший способ.)

Редактировать: еще одна вещь:

Проекты всегда имеют внешние зависимости. Мои проекты нуждаются в Postgres и работающей установке Linux. Было бы безумно связывать это с кодом приложения в системе управления версиями, но очень полезен скрипт для настройки всего на новой рабочей станции.

Полагаю, что я пытаюсь сказать, окольным путем, что я не думаю, что вы должны относиться к своим внутренним модулям иначе, чем к внешним модулям.