Организация решений, проектов и SVN
Я хотел бы получить некоторую помощь в настройке проекта в SVN в отношении структуры каталогов. Я прочитал несколько ответов на этот вопрос на SO, но поскольку я новичок в этом, большинство из них трудно понять.
Я создаю единую библиотеку, от которой зависит несколько других различных проектов:
Мне нужна возможность экспортировать MyLibrary (заголовки и .lib only) легко для использования третьими лицами
MyLibrary1
- зависит от внешних библиотек, должно быть возможность управлять различными версиями этих библиотек!
MyLibrary2
- зависит от внешних библиотек fmod, glew, ...
Проект 1, 2, 4, 5, 6 ...
- зависит от MyLibrary1, 2 или от обоих
- каждому проекту могут потребоваться версии для нескольких платформ (osx, windows ...)
////////////////////////////////////////////////////////////////////////////////////////////////////////////
/ / Edit
Я не могу поместить это в комментарий, поэтому здесь идет: @J. N, спасибо за подробный ответ, я хотел бы прояснить некоторые вещи, надеюсь, я правильно понял, что вы имели в виду:
root
library foo
/branches // old versions of foo
/tags // releases of foo
/trunk // current version
/build // stuff required by makefiles
/tools // scripts to launch tests ect
/data // test data needed when running
/output // binaries, .exe files
/dependencies // libraries that foo needs
/lib name
include
lib
/docs // documentation
/releases // generated archives
/sample // sample project that shows how to use foo
/source // *.h, *.cpp
program bar
/branches // old versions of bar
/tags // releases of bar
/trunk // current version
/build // stuff required by makefiles
/tools // scripts to launch tests ect
/data // test data needed when running
/output // binaries, .exe files
/dependencies // libraries that bar needs
/lib name
include
lib
/docs // documentation
/releases // generated archives
/sample // sample project that shows how to use bar
/source // *.h, *.cpp
1) Откуда берутся *.файлы sln идут? В /строить?
2) Нужно ли копировать foo / source в bar / dependencies/foo / include? В конце концов, бар зависит от foo
3) где делать *.dll файлы идут? Если foo имеет зависимости от dll-файлов, то все программы, использующие foo, должны иметь доступ к одним и тем же dll-файлам. Следует ли это сделать в root / DLL?
1 ответ:
Есть несколько уровней для ваших вопросов: как организовать одно дерево исходных текстов проекта, как поддерживать различные проекты вместе, как поддерживать зависимости этих проектов, как поддерживать различные варианты каждого проекта и как их упаковать.
Пожалуйста, имейте в виду, что независимо от того, что вы делаете, ваш проект в конечном итоге вырастет достаточно большим, чтобы сделать его неприспособленным. Это нормально-менять структуру несколько раз за время существования проекта. Ты почувствуешь это. что это уже не правильно, когда это произойдет: обычно это происходит, когда установка беспокоит вас больше, чем помогает.
1-ведение различных вариантов каждого проекта
Нет вариантов для каждого проекта, Вы не будете решать несколько вариантов, поддерживая парралевые версии или ветви. Имейте единственное дерево исходных текстов для каждого проекта/библиотеки, которое может быть использовано для всех вариантов. Не управляй разными "операционками", Управляй разными функциями. То есть, иметь варианты на такие вещи, как" поддержка posix сокетов "или"поддержка пользовательского интерфейса". Это означает, что если появляется новая ОС, то вам просто нужно выбрать набор функций, которые она поддерживает, а не начинать новую версию.
Когда требуется конкретный код, создайте интерфейс (абстрактный класс В C++) и реализуйте поведение по отношению к нему. Это позволит изолировать проблемный код и поможет добавить новые варианты в будущем. Используйте макрос, чтобы выбрать правильный во время компиляции.
2 - Поддержание зависимостей каждого проекта
Имеют определенную папку "dependencies", в которой каждая подпапка содержит все необходимое для одной зависимости (то есть включает и подчиненные зависимости). В начале, когда кодовая база не слишком велика, вы не слишком заботитесь о том, чтобы автоматически обеспечить совместимость всех зависимостей друг с другом, сохраните ее на потом.
Не пытайтесь объединить зависимости из их корневого расположения выше в иерархии svn. Формально доставляйте каждую новую версию командам, нуждающимся в ней, до тех пор, пока они не обновят свою собственную часть SVN.
Не пытайтесь использовать несколько версий одной и той же зависимости одновременно. Это плохо кончится. Если вам действительно нужно (, но старайтесь избегать этого, насколько это возможно), разветвляйте свой проект для каждой версии.
3-ведение различных проектов
Я бы посоветовал поддерживать каждый репозиторий проектов независимо (с SVN они все еще могут быть одним и тем же РЕПО, но в отдельные папки). Ветви и теги должны быть специфичны для одного проекта, а не для всех. Постарайтесь максимально ограничить количество ветвей, они не решают проблем (даже с git). Используйте ветви, когда вам нужно параллельно поддерживать различные хронолигические версии (Не варианты ) и отбиваться как можно больше, прежде чем вы действительно сделаете это, все выиграют от использования более нового кода.
, что позволит наложить ограничения безопасности (не уверен, что это возможно с vanilla SVN, но есть некоторые свободно доступные серверы, которые поддерживают его).
Я бы рекомендовал отправлять уведомления по электронной почте, когда кто-то совершает коммиты на проект, всем потенциально заинтересованным.
4-организация исходного дерева проекта
Каждый проект должен иметь следующие структуры SVN:
- магистраль (текущая версия)
- ветви (старые версии, все еще используются)
- теги (релизы, используемые для создания ветвей без лишних размышлений при необходимости исправления ) Когда проект становится больше, организуйте ветви и теги в подпапках (например, ветви / V1. 0/V1. 1 и ветви/V2. 0/V2.1).
Есть корневая папка со следующими подпапками: (некоторые из них могут быть созданы самим VC)
- система сборки (материал, необходимый для ваших файлов Makefile или других)
- инструменты (если таковые имеются, например XSLT-инструмент или SOAP-компилятор, скрипты для запуска тестов)
- данные (тестовые данные, необходимые в то время как бег)
- вывод (куда система сборки помещает двоичные файлы)
- временный вывод (временные файлы, созданные компиляцией, необязательно)
- зависимости
- Docs (если есть ;) или сгенерированные docs)
- релизы (сгенерированные архивы см. ниже)
- пример (небольшой проект, демонстрирующий, как использовать проект / библиотеку)
- Источник (я не люблю разделять заголовки и .cpp, но это мой путь. )
- избегайте слишком большого количества уровней вложенных папок., трудно искать деревья, списки проще
- правильно определите порядок сборки каждой папки (менее необходимый для VC, но все же)
- я делаю так, чтобы мои пространства имен совпадали с именами моих папок (старые привычки Java, но работает)
- четко определите "публичную" часть, которую необходимо экспортировать
- Если проект достаточно велик, чтобы содержать несколько двоичных файлов / DLL, каждый должен иметь свою собственную папку
Не фиксируйте никаких двоичных файлов, которые вы создаете,только релизы. Двоичный код любят конфликтовать друг с другом и причинять боль другим людям в команде.
5-упаковка проектов
Во-первых, обязательно включите текстовый файл с редакцией SVN и датой, есть автоматический способ сделать это с помощью auto props.
У вас должен быть скрипт для генерации релизов (если позволяет время). Он проверит, что все исправлено, сгенерирует новый номер версии .... Создайте zip/tar.GZ архив необходимо зафиксировать/архив, имя которого содержит SVN ревизия, ветвь и текущая дата (формат должен быть нормализован по всем проектам). В архиве должно быть все, что необходимо для запуска приложения / использования библиотеки в файловой структуре. Создайте тег, чтобы вы могли начать с него для экстренного исправления ошибок.