Как использовать различные цепочки инструментов

Question

В проекте, где некоторые цели должны быть построены и запущены на платформе сборки, а другие цели должны быть построены для кросс-платформы; какие у нас есть варианты при использовании cmake?

В настоящее время я использую CMAKE_BUILD_TYPE для определения цепи инструмента, типа сборки и платформы (например, -D CMAKE_BUILD_TYPE=arm_debug). В одном месте в сборке я переключаю инструменты (компиляторы, ссылки и т. Д.), Флаги командной строки, библиотеки и т. Д. В соответствии со значением CMAKE_BUILD_TYPE. Для каждого типа сборки я создаю каталог сборки.

У этого подхода есть свои недостатки: несколько каталогов сборки и простой способ зависеть от одной цели от одного типа сборки на цели в другом типе сборки (какой-то прекомпилятор, необходимый на платформе сборки, для сборки для кросс-платформы например).

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

Answer 1

«один тип сборки и платформа для CMake run« Ограничение является основополагающим, и я настоятельно рекомендую не пытаться его обойти.

Правильное решение здесь кажется мне разбить сборку на несколько этапов. В частности, для сценария, в котором цель из одного типа сборки зависит от цели от другого типа сборки, вы не должны пытаться использовать эти две цели в одном проекте CMake. Здесь важна правильная модуляция. Эффективное использование команды CMake include может помочь избежать дублирования кода в скриптах сборки.

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

Печальная правда заключается в том, что эти сложные построения построены hard для управления. CMake отлично справляется с предоставлением ряда инструментов для решения этой сложности, но не может волшебным образом облегчить проблему. Большинство ограничений, которые CMake накладывает на своего пользователя, есть по какой-то причине, а именно, что вещи будут еще сложнее, если вы попытаетесь работать без них.