Создание C++ и в Windows и в Linux

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

Здесь сравнение SCons с другими инструментами для сборки.

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

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

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

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 достаточно силен.

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

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

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

Поэтому любые изменения должны быть вместо этого в файлы CMake.

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

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

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

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

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

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

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

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

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

Повторная синхронизация вопроса:

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

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

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

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