Одновременная разработка на С++ в Linux и Windows

Ответ 1

Используйте CMake для управления вашими файлами сборки.

Это позволит вам установить один репозиторий с одним набором текстовых файлов. Затем каждый разработчик может запускать соответствующие сценарии cmake для создания правильной среды сборки для своей системы (сценарии сборки Visual Studio 2008/2005/GNU С++/и т.д.).

Здесь есть много преимуществ:

• Каждый разработчик может использовать собственную среду сборки
• Зависимости можно обрабатывать очень аккуратно, включая деления на платформе.
• Сборка может быть вне источника, что помогает предотвратить случайное использование несоответствующих файлов.
• Простая миграция на новый dev. (то есть: когда VS 2010 будет выпущен, некоторые разработчики могут перенести туда только путем восстановления своей папки сборки)

Ответ 2

Я сделал это и увидел, что это сделано без особых проблем.

Вы хотите попробовать изолировать код, который отличается для разных платформ. Кроме того, вам нужно подумать о структуре каталога. Что-то вроде

• project/src < -.cc и .h files
• project/src/linux | win < - код, который относится к одной платформе или другой
• project/linux < - создавать файлы и другие связанные с проектом материалы
• project/win < -.sln и .csproj файлы

В принципе, вы просто хотите четко понять, что конкретно для каждой системы и что общего.

Кроме того, модульные тесты будут действительно важны, так как может быть небольшая разница, и вы хотите, чтобы пользователям было легко выполнить некоторые тесты, чтобы убедиться, что код Linux работает так, как ожидалось и наоборот.

Ответ 3

У меня был такой опыт работы в Acronis. У нас была такая же кодовая база, которая использовалась для создания двоичных файлов (на самом деле, полностью упакованных инсталляторов), нацеленных на Win32/64, Linux и OS X (и множество других экзотических платформ, таких как EFI), со всеми, кто работает в своей среде IDE. Хитрость здесь заключается в том, чтобы избежать конкретных решений, связанных с компилятором и IDE, и сделать ваш проект полностью готовым к использованию из чистых межплатформенных файлов. Обратите внимание, что вы можете отлично использовать любую систему make вместе с VС++, поэтому это не проблема (мы использовали Watcom по историческим причинам, но я бы не рекомендовал ее).

Еще один трюк, который вы можете сделать, это добавить make script, который автоматически создает файлы проекта из входных списков в ваших файлах make файлов, для всех используемых вами IDE (например, VS и Eclipse CDT). Таким образом, каждый разработчик генерирует этот материал для себя, а затем открывает эти проекты в среде IDE для редактирования/сборки/отладки, но исходный репозиторий имеет только файлы make файлов.

Обеспечение компиляции кода для всех может быть проблемой, главным образом из-за того, что VС++, как правило, более непринужденно применяет правила, чем g++ (например, он позволит вам привязать значение r к неконстантной ссылке, хотя и с предупреждением). Если вы компилируете с предупреждениями о предупреждении как ошибки и самые высокие уровни предупреждений (возможно, с несколькими выбранными вручную предупреждениями), вы в большинстве своем избегаете этого. Создание смежных роликовых конструкций - еще один способ поймать их на ранней стадии. Еще один подход, который мы использовали в Acronis, заключается в том, чтобы в среде компоновки Windows были созданы инструменты кросс-компиляции на основе Cygwin, поэтому любой Windows-разработчик мог бы сделать сборку с таргетингом на Linux (с той же версией g++ и всеми) из своей коробки, и посмотрите, не сработает ли это, чтобы убедиться, что его изменения будут скомпилированы в g++.

Ответ 4

как упоминалось в предыдущих сообщениях, Qt - очень простой способ сделать реальную одновременную многоплатформенную разработку - независимо от вашей среды разработки и со многими различными компиляторами (даже для Symbian, ARM, Windows CE/Mobile...).

В моей последней и текущей компании я работаю в смешанных командах Linux и Windows-разработчиков, которые работают вместе, используя Subversion и Qt (у которой есть очень простая и мощная система сборки QMake, которая скрывает все различные платформы/компилятор специфических построений - вам просто нужно написать один файл сборки для всех платформ - так просто!).

И: Qt содержит почти все, что вам нужно:

• простая обработка строк, простая поддержка перевода и простое преобразование строк (utf8, utf16, asci...)
• простые классы для ввода/вывода файлов, изображений, сетей и т.д.
• удобные классы gui
• графический дизайнер для макета/дизайна gui
• инструмент графического перевода для создания динамических переводов для ваших приложений (вы можете запускать один двоичный код с различными выбираемыми языками - даже кириллические, азиатские шрифты...)
• интегрированная платформа тестирования (модульные тесты)

Итак, Qt - полнофункциональная и очень надежная среда - я использую ее в течение 10 лет.

И: Qt легко интегрируется в IDE, такие как VС++, Eclipse или предоставляет собственную среду IDE "QtCreator".

см.: http://www.trolltech.com + http://doc.trolltech.com

С наилучшими пожеланиями, Крис

Ответ 5

Я лично использую cmake/mingw32/Qt4 для всех моих потребностей на С++. QtCreator - это кроссплатформенная среда разработки, которая несколько оптимизирована для программирования qt4.

Ответ 6

Мы также работаем над кросс-платформенным проектом. Мы используем Emacs для кодирования, для сборки SCons и Visual Studio 2008 для отладки. Это мой первый раз с использованием Emacs + SCons, и я должен сказать, что он очень изящный, как только вы выясните, как работают SConstruct и SConscripts.

Ответ 7

Я опаздываю на этот вопрос, и здесь есть много хороших ответов, но я не видел, чтобы кто-либо перечислял все проблемы, с которыми я столкнулся (большая часть моей работы на С++ - платформа), поэтому:

• Кросс-платформенная компиляция. Все это хорошо освещали. CMake, и SCons полезны среди прочих.
• Различия в платформе. Они фактически не ограничены Linux v Windows. В разных версиях Windows есть много тонких проблем. Если вы когда-нибудь захотите перейти с Linux на OS X, вы найдете то же самое. Так что разница в архитектуре процессора: 32 v 64 бит обычно не имеет значения - пока это не произойдет, и все очень сильно сломит вас. Это то, что С++ программисты сталкиваются с более, чем в большинстве других языков, чьих реализации упорно трудится, чтобы скрыть такие вещи от программистов.
• Проверить все. Алан упоминает модульные тесты, но позвольте мне подчеркнуть их. Реальная проблема с кросс-платформенным программированием - это не код, который не будет компилироваться: это код, который компилируется просто отлично и делает неправильные вещи в тонких случаях. Модульные тесты важны здесь гораздо больше, чем при работе на одной платформе.
• При необходимости используйте портативные библиотеки. Получение этого права полна тонких ошибок. Лучше воспользоваться кем-то другим, чем катиться самостоятельно. Qt полезен здесь, а NSPR и APR (последние два являются C, но обертки существуют, если вы не хотите связываться с ними напрямую.) Эти это библиотеки, которые явно нацеливают абстракцию платформы как цель, но для этого нужно проверить большинство других библиотек, которые вы используете. Будьте осторожны с классными библиотеками, которые не имеют послужной список переносимости. Я не говорю, что не использую их: сначала проверьте. Выполнение этого права экономит ваши огромные усилия на тестировании.
• Pavel упоминает постоянную интеграцию. Это может быть неважно, есть ли только несколько из вас. Но я обнаружил, что количество платформ, которые вы получаете, когда вы рассматриваете все варианты ОС, ОС и процессоров, означает, что без какого-либо цикла непрерывного цикла сборки всегда будет отсутствовать некоторый край. Если ваш проект становится больше, чем несколько человек, подумайте об этом.
• Контроль версий. Наиболее очевидной проблемой является обработка новых строк и чувствительность к регистру, но есть и другие. Большинство известных VCS с открытым кодом делают это прямо сейчас, но это примечательно тем, что обычно им требуется несколько лет, чтобы найти все свои ошибки, связанные с переносимостью. В качестве примера Mercurial, который имел портативность как один из своих торговых точек, имеет ряд исправлений, охватывающих три или четыре выпуска, связанных с именами файлов Windows в необычных ситуациях. Убедитесь, что вы можете проверить, что другие проверяют раньше.
• Scripts. Используйте Perl/Python/Ruby (или что-то в этом роде) для ваших сценариев. Попытка сдержать синхронные скрипты Linux и ОС Windows очень скучна.

Несмотря на все вышеперечисленное: общая кросс-платформа вполне выполнима, и нет никакой реальной причины ее избежать. Мой опыт заключается в том, что проблемы, как правило, возникают спорадически, но когда они делают, они берут больше, чем есть достаточная доля времени. Если вы программируете некоторое время, хотя вы не найдете этого необычного.

Ответ 8

Проблема не в том, чтобы редактировать исходные файлы на С++, но сам процесс сборки. VS не использует ту же архитектуру Makefile, что и Linux. Радикальное предложение, но обе группы действительно могут использовать один и тот же С++ IDE и процесс сборки - см. Code:: Blocks для получения дополнительной информации.

Ответ 9

Это возможно (я делаю это, чтобы заработать мои ежедневные деньги:-)).

Но вы должны иметь в виду различия в поставляемых ОС библиотеках, которые могут быть очень неприятными. Два хороших варианта - это BOOST и QT.

Оба предоставляют вам независимые от платформы функции полезного материала, которые не обрабатываются C lib и STL.

Ответ 10

Я сделал это двумя способами:

• Каждая платформа имеет свою собственную систему сборки. Всякий раз, когда кто-то что-то меняет (добавляет исходный файл), они либо адаптируют другую платформу, либо отправляют уведомление, а кто-то, более знакомый с другой платформой, соответствующим образом адаптирует его.
• Используйте CMake.

Я не могу сказать, что мне очень понравился CMake, но кросс-платформенный инструмент, безусловно, имеет свои преимущества.

Как правило, использование разных компиляторов для компиляции кода из первых нескольких строк всегда является хорошей идеей, так как это помогает улучшить качество кода.

Ответ 11

Еще одно голосование за cmake.
Одна вещь, на которую нужно обратить внимание, имена файлов обрезаны, но не чувствительны к регистру в Windows. Они чувствительны к регистру в большинстве файловых систем unix.

Это обычно проблема С#include

например. задан файл FooBar.h

 #include "foobar.h" // works on Windows, fails on Linux.

Ответ 12

Я согласен со всеми здесь, что предложил cmake для кросс-платформенной разработки на С++. Это отличный инструмент.

Еще одна вещь, которую я хотел бы предложить, - использовать eclipse CDT в качестве среды разработки. Он работает в любом месте, где вы можете запускать Java gcc и объединяете среду разработки.

Я думаю, это был Алан Джексон, который сделал акцент на unit test. Для этого вам понадобится несколько кроссплатформенных библиотек unit test. Я прочитал этот post в отношении С++ unit test фреймворков. Он немного устарел, но вдумчивый. Тот, который отсутствует, который также работает на обеих платформах, googletest.

Наконец, если вы хотите запустить этот тест автоматически на обеих платформах, у cmake есть другой инструмент ctest, который очень хорош для этого.

Ответ 13

Отметьте премьера... Это очень похоже на CMake, но написано с помощью lua.

Я использовал это в ряде проектов разработки и нашел его легким в освоении и интеграции в существующие структуры компаний и проектов.

Попробуйте!

http://industriousone.com/premake