Автоматизировать сборку, используя файлы проектов для конкретной платформы или генераторы проектов? - PullRequest
4 голосов
/ 24 декабря 2009

Существуют некоторые системы сборки, которые могут генерировать файлы проектов для конкретной платформы, например файлы Visual Studio sln, vcproj, vcxproj или XCode xcodeproj под OS X.

Одним из них является CMake, но я обнаружил, что поддержка этого довольно ограничена, глючит, и его очень сложно обновлять новыми версиями (например, VS 2010).

Кроме того, по крайней мере в CMake отсутствует поддержка страниц свойств для Visual Studio, что затрудняет управление и изменение конфигураций в масштабах проекта - например, включение / отключение анализа кода для всех проектов.

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

Довольно просто вызвать специфические для платформы команды сборки в общем сценарии автоматизации сборки. Например, я использовал waf (Python) для автоматизации этого в нескольких проектах без использования собственной части сборки.

Я хотел бы посмотреть, что вы выберете между: попыткой восстановить / сохранить генераторы проекта или сохранить отдельные файлы проекта?

Ответы [ 3 ]

3 голосов
/ 24 декабря 2009

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

Нашей основной платформой являются windows, почти вся разработка выполняется в VS IDE. Для других платформ (пока только для некоторых версий linux) мы используем исключительно CMake. По сути, мы выбрали способ «пытаться восстановить / поддерживать генераторы проектов», но с исходными файлами проекта Visual Studio.

  • мы используем файлы проекта visual studio в качестве контейнера для всех файлов в проекте
  • все параметры сборки задаются в листах свойств, каждый проект имеет стандартный набор и, в конечном итоге, несколько дополнительных листов для загрузки в определенные библиотеки и т. Д.
  • у нас есть несколько простых скриптов, которые позволяют добавлять / удалять таблицы свойств в одном пакете
  • все листы свойств имеют аналог cmake; оба хранятся в одном и том же каталоге, и если мы обновим один, мы также всегда обновляем аналог. Это не делается с помощью скрипта, и я признаю, что это «сложная» часть: хотя мы очень сильно работаем с макросами, всегда есть опции, доступные на одной платформе, но не на другой.
  • у нас есть скрипт, который преобразует файлы vcproj в файлы cmake, он в основном создает файл cmake, который включает в себя соответствующие листы свойств cmake и который содержит все исходные файлы, которые имеет vcproj.
  • И последнее, но не менее важное: я написал сервер сборки, работающий на всех платформах, которые мы используем. Он строится с использованием msbuild или cmake, и это ключ к поддержанию работоспособности этой системы: каждое внесенное нами изменение запускает сборку + тесты по крайней мере на двух машинах, поэтому мы немедленно узнаем, все ли в порядке.

Недавно мы начали использовать VS2010, и миграция заняла всего около дня: сначала мы разрешили VS преобразовать все наши проекты и таблицы свойств, а затем внесли некоторые изменения в сценарии для обработки новых форматов файлов XML.

Редактировать

извините, но я не могу опубликовать сценарии, политику компании, надеюсь, вы понимаете. Немного псевдокода не проблема, хотя. Добавление / удаление таблиц свойств в файлах проекта VS2008 выглядит следующим образом:

foreach proj in projectfiles //list of vcproj files
  foreach config in configuration //configurations eg 'Debug|Win32, Debug|x64'
    f = OpenFile( proj );
      //find start of Configuration element, then get what's after InheritedPropertySheets=
    propsheets = GetPropSheetsForConfig( f, config );
    propsheets = DoAction( action, args, propsheets ); //action is add/remove/.. with argument args
    SetPropSheetsForConfig( f, propsheets );

Для файлов CMakeLists это почти то же самое, за исключением того, что скрипт работает со строками include (..).

Преобразование из vcproj в CMakeLists:

f = OpenFile( proj );
projname = GetProjectName( f );
sources = GetSourceFiles( f ); //all File/RelativePath elements under Filter 'Source Files'
sources = CheckFilter( sources ); //apply rules to include/exclude platform specific files
propsheets[] = GetPropSheetsForConfig( f, configs[] );

fout = CreateCMakeFromProj( proj ); //CMakeLists.txt in corresponding directory
WriteCMakeHeader( fout, projname );
WriteCMakeSources( sources );
WriteCMakeIncludes( configs[], propsheets[] ); //write includes, conditional on CMAKE_BUILD_TYPE

Сервер сборки сейчас довольно сложный материал, но вначале он был просто слушателем TCP:

  • жду соединения
  • получить необязательные аргументы (листы свойств / действие)
  • обновление репозитория
  • в конечном итоге запустить пакетный скрипт для листов свойств с заданными аргументами
  • запустить командную строку, полное перестроение + тесты, записать вывод в файл
  • файл разбора для строк, содержащих 'error', результаты почты
0 голосов
/ 11 января 2010

Мы используем boost.build для наших проектов на платформе. Это хорошо работает для проектов библиотеки C ++. Нам это нравится, потому что нам нужен только один скрипт, и он хорошо интегрируется с Boost.Test.

У него очень крутая кривая обучения, и документация довольно скудная. Но он хорошо работает на Windows и Linux, на двух платформах, над которыми мы работаем.

0 голосов
/ 11 января 2010

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

Изучение Scons очень просто, когда вы знаете Python, не зная Python, вы отключаете две великие технологии, а не одну;)

...