Как несколько разработчиков могут использовать одни и те же файлы vcproj?

Question

Я работаю над проектом с двумя другими разработчиками, который построен на FireBreath . До сих пор мне удавалось наладить идеальную работу на моей машине, но мы должны координировать нашу разработку через Mercurial. Поэтому я отправил свои файлы в хранилище и подумал, что все хорошо.

К сожалению, это не работает.

Различные .vcproj файлы, составляющие решение, содержат жестко запрограммированные ссылки на мою локальную файловую систему. Это прекрасно работает для меня, потому что я не перемещаю проект. Но когда вы пытаетесь построить решение на другом компьютере с другой файловой структурой (другой буквой диска, другим расположением папки и т. Д.), Все ломается.

Я использовал стандартный сценарий создания проекта FireBreath (Python), а затем сценарий Visual Studio CMake (prep2008.cmd) для создания файлов решения. Что я могу сделать, чтобы настроить, чтобы другие разработчики могли использовать ту же базу кода?

Answer 1

Если ваши разработчики не используют одни и те же файлы build / make / project, это может быстро стать кошмаром обслуживания.Таким образом, вы должны окончательно все использовать одинаковые .vcproj файлы.(Исключением из этого является то, что файлы проекта были сгенерированы из некоторых других файлов. В этом случае обрабатывайте эти другие файлы способом, описанным выше.)

есть два способа решения проблемы различных настроек наразные машины.Один - сделать все пути относительно пути проекта .Другой - использовать переменные окружения для ссылки на файлы / инструменты / библиотеки / что угодно.IME, лучше всего использовать относительные пути для всего, что может быть проверено проектом, а для остальных - переменные среды.Добавьте сценарий, который проверяет наличие всех необходимых переменных среды, указав значение всех отсутствующих переменных, и запустите его как предварительное условие сборки, чтобы тот, кто пытается запустить и запустить новую сборочную машину, получил подсказку о том, что делать.

Answer 2

Чтобы убедиться, что все поймали обновленные комментарии из ответа sbi, позвольте мне дать вам "окончательный" ответ от разработчиков FireBreath.

Ваш каталог сборки одноразовый; вы должны никогда обмениваться файлами .vcproj. Вместо этого вам следует заново создавать каталог build / при каждом изменении проекта и на каждом новом компьютере, как и в любом проекте, использующем CMake.

Для получения дополнительной информации см. http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/

Для справки, я являюсь основным автором FireBreath и написал статью.

Answer 3

Я не знаком с FireBreath, но вам нужно сделать ссылки относительными, а затем воссоздать эту относительную структуру на каждой машине. То есть, если ваш проект находится в «c: \ myprojects \ thisproject» и имеет дополнительный каталог include «c: \ mydir \ mylib \ include», то последний путь необходимо заменить на «.... \ mydir \» MyLib \ включают в себя».

Answer 4

РЕДАКТИРОВАТЬ: я переписал мой ответ, чтобы сделать его более понятным.Когда я вас правильно понял, ваша проблема в том, что FireBreath генерирует эти файлы .vcproj с абсолютными путями в нем, и вы хотите использовать эти файлы .vcproj на другом компьютере разработчика.

Я вижу 3 варианта:

1. Жить с этим.Это означает, что каждый член команды должен иметь одинаковую файловую структуру / представление для файловой системы, инструменты установлены в одном месте.

2. Попросите авторов FireBreath изменить их .vcprojгенератор для разрешения относительных путей, использования переменных среды и т. д.

3. Если 1 или 2 не работает, напишите программу или скрипт для изменения абсолютного пути к родственникам в этих файлах .vcproj.Запускайте этот сценарий всякий раз, когда вам нужно восстановить проект FireBreath.

Чего не следует делать из-за FireBreath FAQ : не изменяйте .vcproj вручную,эти изменения будут потеряны при следующей регенерации проекта.

EDIT : кажется, что «вариант 4».оказалось лучшим решением: генерировать эти .vcproj файлы для каждого разработчика в отдельности.Надеюсь, мои предложения тоже были полезны.