У нас есть большое количество базовых библиотек и приложений, основанных на этих библиотеках. Мы поддерживаем систему сборки на основе Makefile в Linux и Windows, используя решение Visual Studio для каждого проекта или библиотеки.
Мы считаем, что это хорошо работает для наших нужд, каждая библиотека или приложение разрабатывается либо на Linux, либо на Windows с учетом кросс-компиляции (например, не используйте API для конкретной платформы). Мы используем boost для таких вещей, как пути к файлам, потоки и так далее. В определенных случаях мы используем шаблоны / # define, чтобы выбрать решение для конкретной платформы (например, события). Когда все будет готово, мы переходим на другую систему (Linux или Windows), перекомпилируем, исправляем предупреждения / ошибки и тестируем.
Вместо того, чтобы тратить время на поиск инструментов, которые могут кросс-компилировать на обеих платформах, мы используем систему, которая лучше подходит для каждой платформы, и тратим время на исправление конкретных проблем и совершенствование программного обеспечения.
У нас есть приложения с графическим интерфейсом только в Windows atm. поэтому нет графического интерфейса для кросс-компиляции. Большая часть нашей разработки, которая совместно используется Windows и Linux, связана с сетями на стороне сервера (сокеты, TCP / IP, UDP ...), а затем с инструментами на стороне клиента в приложениях Linux и GUI в Windows.
Используя во время выполнения для управления версиями исходного кода, во многих случаях мы обнаруживаем, что система Linux Makefile гораздо более гибкая для того, что нам нужно, чем Windows VS. Особенно для использования нескольких рабочих пространств (представлений версий исходного кода), где нам нужно указывать на общие каталоги и так далее. В Linux это можно сделать автоматически, запустив сценарий для обновления переменных среды, в Visual Studio ссылки на переменные среды очень негибки, поскольку трудно автоматически обновлять представления / ветви.
Вопрос повторной синхронизации:
Я предполагаю, что вы спрашиваете, как убедиться, что две системы сборки синхронизируются между Linux и Windows. На самом деле мы используем Hudson в Linux и CruiseControl в Windows (у нас сначала были окна с круиз-контролем, когда я перешел на установку версии linux, я подумал, что Hudson лучше, так что теперь у нас смешанная среда). Наши системы работают постоянно. Когда что-то обновляется, оно тестируется и выпускается (либо версия для Windows, либо для Linux), чтобы вы сразу знали, если это не работает. Во время тестирования мы удостоверимся, что все последние функции доступны и полностью функциональны. Полагаю, ничего страшного в этом нет.
О, вы имеете в виду сценарии сборки ... Каждое приложение имеет свое собственное решение, в котором вы настраиваете зависимости. На стороне Linux у меня есть make-файл для каждого проекта и сценарий сборки в каталоге проекта, который заботится обо всех зависимостях, это в основном означает сборку базовых библиотек и пару специфических сред, необходимых для данного приложения. Как вы можете видеть, это отличается для каждой платформы, легко добавить строку в сценарий сборки, которая изменит каталог и сделает необходимый проект.
Помогает согласованно настраивать проекты.
В Windows вы открываете проект и добавляете проект зависимостей. Опять не волшебство. Я рассматриваю задачи такого рода как связанные с разработкой, например, вы добавили новую функциональность в проект и должны ссылаться в рамках и заголовках. Так что, с моей точки зрения, нет причин автоматизировать их, поскольку они являются частью того, что делают разработчики при реализации функций.