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

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

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

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

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


person EAMann    schedule 19.11.2010    source источник


Ответы (4)


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

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

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

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

person taxilian    schedule 02.12.2010

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

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

person sbi    schedule 20.11.2010
comment
Мне нравится идея самодокументируемой сборки. - person anton.burger; 20.11.2010
comment
@sbi: вы полностью игнорируете тот факт, что эти файлы .vcproj генерируются с помощью FireBreath. - person Doc Brown; 21.11.2010
comment
@Док: О. Я не знаю FireBreath. Что оно делает? - person sbi; 21.11.2010
comment
@sbi: насколько мне известно, он генерирует файлы .vcproj. Поэтому изменение их напрямую или вручную может быть не лучшим способом решения проблемы. Загляните в FAQ по FireBreath, как я писал в своем посте. - person Doc Brown; 21.11.2010
comment
@all: Да, FireBreath динамически генерирует файлы .vcproj, и оказывается, что их не нужно держать под контролем источника. Папка projects содержит весь наш исходный код, папка build (содержащая .vcprojs) содержит только файлы проекта и решения, которые связывают исходный код проекта с FireBreath. Используйте SCM в проекте, не в Firebreath... затем запустите команды CMake на каждой машине, чтобы перестроить .vcproj со ссылками на локальную систему. Красиво работает! - person EAMann; 21.11.2010
comment
@Doc & @EAMann: Понятно. Я добавил в свой ответ предложение о сгенерированных файлах проекта. Надеюсь это поможет. - person sbi; 21.11.2010
comment
Точно; вы никогда не должны сохранять каталог build/ или повторно использовать файлы .vcproj. см. colonelpanic.net/2010/11/ - person taxilian; 02.12.2010

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

person Michael Repucci    schedule 19.11.2010

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

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

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

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

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

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

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

person Doc Brown    schedule 19.11.2010
comment
А что тогда делать, когда нужно переключить одного разработчика на другой проект? Переустановить всю его машину? - person sbi; 21.11.2010
comment
Ну, у меня никогда не было ситуации, когда файловые структуры разных проектов были бы совершенно несовместимы. Если мое предложение применимо, многое зависит от того, в какой организации вы работаете. - person Doc Brown; 21.11.2010