Создание С++ для Windows и Linux

Я участвую в проекте С++, предназначенном для платформ Windows и Linux (RHEL). До сих пор разработка была выполнена исключительно на Visual Studio 2008. Для компиляции Linux мы использовали сторонний плагин Visual Studio, который читал VS-решения/файлы perojects и удаленно скомпилировался на Linux-машине.

В последнее время принято решение отказаться от стороннего плагина.

Теперь моя большая забота - это система сборки. Я искал возможности для создания кросс-платформенных инструментов. Таким образом, мне не нужно поддерживать два набора файлов сборки (например, vcproj/solution для Windows и делать файлы для Linux).

Я нашел следующих кандидатов: а. Scons б. CMake

Что вы думаете о инструментах для кросс-платного развития?

Еще один момент, который меня беспокоит, заключается в том, что Visual Studio (+ Visual Assist) потеряет много функциональности без файлов vcproj - как вы справляетесь с проблемой с помощью инструментов?

Спасибо Дима

PS 1: Что-то, что мне нравится в Scons, это то, что он (a) использует python и, следовательно, он гибкий, в то время как cmake использует язык приличий (я понимаю, что это не функция победителя для системы сборки) (b) автономно (нет необходимости создавать make файлы в Linux, как с cmake).

Так почему же не Сонс? Почему в ваших проектах было принято решение использовать cmake?

Ответ 1

CMake позволит вам по-прежнему использовать решения Visual Studio и файлы проектов. Cmake не создает исходный код сам, скорее он сгенерировал файлы сборки для вас. Для Linux это может быть Code:: Blocks, KDevelop или простой make файл или еще более эзотерический выбор. Для Windows это может быть среди других файлов проекта Visual Studio, а для других - для MacOS. Таким образом, решения и проекты Visual Studio создаются из вашего CMakeLists.txt. Это прекрасно работает для больших проектов. Например. текущий Ogre3d использует CMake для всех платформ (Windows, Linux, MacOS и IPhone), и он работает очень хорошо.

В этом отношении я мало знаю о scons, но я использовал только одну библиотеку и только в Linux. Поэтому я не могу сравнить эти два на справедливых основаниях. Но для наших многоплатформенных проектов CMake достаточно силен.

Ответ 2

Я раньше не использовал Scons, поэтому не могу сказать, как это работает, но CMake работает очень хорошо.

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

При использовании для таргетинга VС++ он создает файлы решений и проектов, поэтому из VS они выглядят так, как если бы они были родными проектами VS. Единственное различие, конечно, в том, что если вы отредактируете проект или решение напрямую через VS, изменения будут удалены при следующем запуске CMake, поскольку он перезаписывает ваши файлы проекта/решения.

Таким образом, любые изменения должны быть внесены в файлы CMake.

Ответ 3

Еще один вариант - премирование. Это похоже на cmake, поскольку он генерирует решения из файлов определений. Это с открытым исходным кодом, и последняя версия очень настраивается с использованием сценариев Lua. Мы смогли добавить поддержку пользовательской платформы без особых проблем. Для вашей ситуации он поддерживает стандарт Visual Studio и GNU make файлов.

См. Домашняя страница Premake 4.0

CruiseControl - хороший выбор для непрерывной интеграции. Мы успешно работаем с Linux с помощью Mono.

Ответ 4

У нас есть большое количество основных библиотек и приложений на основе этих библиотек. Мы поддерживаем систему сборки на основе Makefile в Linux и Windows, используя решение Visual Studio для каждого проекта или библиотеки.

Мы находим, что это хорошо работает для наших нужд, каждая библиотека или приложение разрабатывается либо в Linux, либо в окнах с перекрестной компиляцией (например, не используйте специфичные для платформы api). Мы используем boost для таких вещей, как пути к файлам, потоки и т.д. В конкретных случаях мы используем шаблоны /# для выбора решения для конкретной платформы (например, события). Когда мы готовы, мы перейдем к другой системе (linux или windows), перекомпилируем, зафиксируем предупреждения/ошибки и протестируем.

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

У нас есть графические приложения только для Windows atm. поэтому нет графического интерфейса для перекрестного компиляции. Большинство наших разработок, которые разделяют между Windows и Linux, - это серверная сеть (сокеты, TCP/IP, UDP...), а затем клиентские инструменты для Linux и графических приложений в Windows.

Используя с perforce для управления версиями исходного кода, мы довольно часто обнаруживаем, что система Linux Makefile намного более гибкая для того, что нам нужно, чем Windows VS. Специально для использования нескольких рабочих пространств (представления версий исходного кода), где мы должны указывать на общие каталоги и т.д. В Linux это может быть сделано автоматически с помощью script для обновления переменных среды, в средах Visual Studio, ссылающихся на переменные среды, очень негибко, потому что трудно автоматически обновлять их между представлениями/ветвями.

Повторите синхронизацию:

Я предполагаю, что вы спрашиваете, как убедиться, что две системы сборки синхронизируются между linux и windows. Мы фактически используем Hudson для Linux и CruiseControl в Windows (у нас были окна с круиз-контролем, когда я пошел на установку версии Linux, я понял, что Хадсон лучше, так что теперь у нас смешанная среда). Наши системы работают все время. Когда что-то обновляется, оно протестировано и выпущено (либо Windows, либо версия Linux), чтобы вы сразу узнали, не работает ли он. Во время тестирования мы следим за тем, чтобы все новейшие функции были доступны и полностью функциональны. Я предполагаю, что это не было темной магией.

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

Это помогает последовательно создавать проекты.

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

Ответ 5

Вот article о решении разработчиков KDE выбрать CMake over SCons. Однако я должен указать, что этой статье почти три года, поэтому scons должны были улучшиться.

Здесь - сравнение SCons с другими инструментами построения.

Ответ 6

Пришлось делать это много в прошлом. То, что мы сделали, это использовать gnu для практически всех, включая окна в разы.

Вы можете использовать файлы проекта под окнами, если вы предпочитаете использовать gnu для Linux.

Существует не очень хороший способ создания кросс-платформенных make файлов, потому что целевой файл будет быть разными между прочим (и проблемы с именем пути, \vs/etc). В общем, вы, вероятно, будете настраивать код на разных платформах, чтобы учесть тонкие различия, поэтому потребуется настроить файл make и проверить на других платформах в любом случае.

Многие проекты ОС поддерживают Makefile для разных платформ, таких как zlib, где они называются Makefile.win, Makefile.linux и т.д. Вы можете следовать их примеру.