У меня был такой опыт работы в Acronis. У нас была та же кодовая база, которая использовалась для создания бинарных файлов (фактически, полностью упакованных инсталляторов), предназначенных для Win32 / 64, Linux и OS X (и множества других более экзотических платформ, таких как EFI), причем каждый работал в своей IDE по своему выбору. Хитрость заключается в том, чтобы избежать решений, специфичных для компиляторов и IDE, и сделать ваш проект полностью готовым из чистых кросс-платформенных файлов сборки. Обратите внимание, что вы можете прекрасно использовать любую систему make вместе с VC ++, так что это не проблема (мы использовали Watcom make по историческим причинам, но я бы не рекомендовал это).
Еще один трюк, который вы можете сделать, это добавить скрипт make, который автоматически создает файлы проекта из списков ввода в ваших make-файлах, для всех IDE, которые вы используете (например, VS и Eclipse CDT). Таким образом, каждый разработчик создает этот материал для себя, а затем открывает эти проекты в IDE для редактирования / сборки / отладки, но в исходном репозитории есть только make-файлы.
Обеспечение возможности компиляции кода для всех может быть проблемой, в основном потому, что VC ++, как правило, более слабо применяет правила, чем g ++ (например, это позволит вам связать значение r с неконстантной ссылкой, хотя и с предупреждением ). Если вы компилируете предупреждения как ошибки и наивысшие уровни предупреждений (возможно, отключено несколько отобранных предупреждений), вы в основном избежите этого. Создание непрерывной непрерывной сборки - еще один способ поймать их на ранней стадии. Еще один подход, который мы использовали в Acronis, заключается в том, чтобы в среде сборки Windows были инструменты кросс-компиляции на основе Cygwin, чтобы любой разработчик Windows мог сделать сборку, ориентированную на Linux (с той же версией g ++ и всеми), из своего устройства, и посмотрите, не получится ли это, чтобы убедиться, что его изменения скомпилированы в g ++.