Я прошу прощения за длинный вопрос, но это то, о чем я долго размышлял, и я не могу найти хорошее решение.
Я являюсь частью команды, которая работаетна нескольких проектах, которые иерархически зависят друг от друга, и я пытаюсь решить некоторые проблемы.Проекты структурированы следующим образом (это для игры):
Утилита
RenderSystem - зависит от Утилиты
PhysicsSystem - зависит от Утилиты
GameEngine - зависит от Утилиты, RenderSystemи PhysicsSystem
Game - зависит от Utility и GameEngine
Мы используем svn и CMake.
У нас есть несколько программистов, каждый из которых работает над разными компонентами, и каждый разэто обновление, скажем, RenderSystem, программист Game не хочет перекомпилировать все это.
В настоящее время svn настроен так:
Util
RS
PS
GE
Игра
bin
Двоичные файлы должны быть в SVN, чтобы программисту не приходилось компилировать те, которые он не делаетработа над.Это означает, что на локальной стороне двоичные файлы должны присутствовать в исходном каталоге для связи, и эти же двоичные файлы также должны присутствовать в каталоге сборки для запуска исполняемых файлов (динамическое связывание).
При настройке CMake каждый программист выбирает, для каких проектов они хотят быть построены, а какие для которых они хотят просто использовать предварительно скомпилированные двоичные файлы.
При сборке проекта двоичные файлы автоматически копируются в папку bin.(и, таким образом, привержен SVN).Когда программист обновляет и получает новые двоичные файлы, они копируются в каталог сборки.
На данный момент у нас нет сервера сборки, поэтому автоматическое построение двоичных файлов не вариант.
При использовании этого метода есть несколько неприятностей:
- при фиксации окно фиксации загромождается .dlls и .libs
- и наоборот, при обновлении окно обновления загромождается .dlls и .libs
- , если программист А создаетВ общем и целом, программист B получит конфликт с dll и lib файлами.Это может произойти, только когда два программиста работают над общим проектом, и поскольку двоичные файлы генерируются из кода, не имеет значения, как будет разрешаться конфликт.Это является дополнительным раздражением.
- иногда программист получает две сборки, сгенерированные из источника, и когда одна перестраивается, двоичные файлы должны быть скопированы из папки bin в другую.Это означает, что CMake должен добавить событие сборки, чтобы копировать любые двоичные файлы, которые отличаются во время каждой сборки.
- каждый раз, когда создается проект, все двоичные файлы должны быть скопированы из исходного каталога в каталог сборки (для обновлениялюбой, который был изменен из внешней сборки), а затем собранные двоичные файлы необходимо скопировать обратно из директории сборки в директорию источника.Это приводит к большому количеству копирования файлов и подвержено ошибкам.
- Существуют различные двоичные файлы для отладки и выпуска, и если программист А строит в режиме отладки во время работы, то забывает собрать релиз перед его фиксацией,заголовки и двоичные файлы не будут совпадать.
Текущая система выполняет две основные вещи, которые мы хотели бы сохранить: есть одна корневая директория с исходным кодом, которую необходимо извлечь и обновить, никто не хочетвозиться с несколькими вещами, чтобы проверить;и все это не должно быть построено каждым программистом, они могут построить только то, над чем они работают.
Я хотел бы получить любые предложения о том, как сделать это более плавным.На переднем крае он работает нормально, но парень, которому приходится иметь дело с файлами CMake (я), чертовски разочарован.