Проблема:
Я пишу SDK, в основном C ++. Исходный код будет лицензирован разработчикам, которые его оплачивают, а выходные библиотеки и заголовки будут бесплатными для публичного использования. SDK будет ориентирован на множество платформ, включая Windows, Xbox, Playstation, Android, iOS, Mac OS X и Linux. Я - тип парня, который в основном любит Visual Studio и обычно разрабатывает программное обеспечение на машинах с Windows. За последние несколько лет Visual Studio сделала это намного проще, чем раньше, где у меня есть в основном четкий путь для нацеливания на все ранее упомянутые платформы с использованием набора файлов проекта Visual Studio в качестве источника правды, который объединяет все мои исходные файлы вместе ... за исключением Mac OS X, к сожалению. Visual Studio может создавать исполняемый код для iOS и Linux путем удаленного взаимодействия с Mac или Linux, соответственно, для компиляции и отладки, что на самом деле довольно круто, но по какой-то причине Mac OS X в качестве цели здесь отсутствует. Кроме того, мне хорошо известно, что существует множество других профессиональных разработчиков, которые не пишут код на компьютерах с Windows и не заинтересованы в приобретении коммерческой лицензии на Visual Studio.
Вопрос:
Поскольку C ++ до сих пор не имеет стандарта системы сборки и, возможно, никогда, как мне поддерживать единый источник правды, который поддерживает конфигурации сборки для всех моих исходных файлов, ориентированных на очень много разных платформ, одновременно сводя к минимуму барьер для входа поддержки Клиенты-разработчики программного обеспечения, которым нужно создавать, запускать и отлаживать мой исходный код?
Возможные ответы, которые мне известны:
A) Проекты Visual Studio остаются источником истины, из которого извлекаются любые другие типы проектов C ++ (такие как файлы Android Studio, XCode и .make). Мне известны инструменты, которые могут конвертировать VS в .make и тому подобное, но на самом деле я еще не пробовал их (моя база исходного кода уже начинает становиться несколько больше). Или я мог бы просто откусить пулю и написать их от руки и попытаться синхронизировать их все.
B) CMake. Вздох. Настолько разочаровывающий, что он очень популярен и, кажется, точно решает мои проблемы, но у него есть свой набор проблем, которые, похоже, нарушают условия сделки. Для начала, как только вы войдете в CMake, вы почти не сможете вернуться. Используя Visual Studio и таблицы свойств, я смог настроить свои конфигурации сборки с помощью свойств, которые в основном наследуются и редко дублируются в проектах и конфигурациях. Насколько я вижу, CMake не заботится о соблюдении таких вещей, а для общих свойств он просто дублирует их во всех файлах vcxproj. Что еще хуже, все пути к файлам, которые он генерирует в выходных проектах, являются абсолютными, а не относительными, и, в довершение всего, он заставляет всех, кто создает ваш код, использовать CMake, запрещая распространение создаваемых им файлов сборки проекта без него. , Кроме того, это работает даже для игровых приставок? В последний раз я проверял, что не могу найти разумный способ поддержать их, не взломав исходный код.
C) Сверните мой собственный скрипт, который похож на CMake, но позволяет перераспределять его выходные проекты и поддерживает все платформы, которые мне нужны. Само собой разумеется, что это потребовало бы много времени на разработку.
Любые другие варианты, которые я здесь упускаю? Ваш вклад очень важен.