Заставить CMake установить цели в специфичные для архитектуры каталоги? - PullRequest
0 голосов
/ 26 июня 2019

У меня сейчас проблема с библиотекой Google Protobuf , но это повторяющаяся проблема, которая, вероятно, будет возникать со многими, если не со всеми сторонними пакетами, которые я хочу собрать и установить из исходного кода. .

Я занимаюсь разработкой для Windows, и нам нужно иметь возможность генерировать как 32-битные, так и 64-битные версии наших DLL. Было довольно просто заставить CMake установить наши собственные модули в подкаталоги, зависящие от архитектуры, например D:\libraries\bin\i686 и d:\libraries\lib\i686 (и сим. Для bin). Но мне не удается добиться того же с помощью сторонних библиотек, таких как Protobuf. * ​​1008 *

Я мог бы, конечно, использовать различные комбинации CMAKE_INSTALL_PREFIX и CMAKE_PREFIX_PATH (например, D:\libraries-i686 и D:\libraries-x86_64, и, вероятно, в конечном итоге буду делать это, но меня беспокоит, что, кажется, нет лучшая альтернатива. docs для find_package() ясно показывают, что процедура поиска пытается использовать специфичные для архитектуры пути поиска, поэтому почему файлы CMake популярных библиотек, как правило, не поддерживают установку к специфичным для архитектуры подкаталогам?

Или, может быть, дело только в правильной переменной CMAKE_XXX?

1 Ответ

0 голосов
/ 26 июня 2019

Спасибо @arrowd за то, что он указал мне правильное направление, теперь у меня есть ответ, хотя это не совсем то, на что я надеялся.

CMAKE_LIBRARY_OUTPUT_DIRECTORY и CMAKE_RUNTIME_OUTPUT_DIRECTORY, однако, укажите build выходные каталоги, а не install каталоги.Однако, как выясняется, для каталогов установки также есть переменные, называемые CMAKE_INSTALL_BINDIR и CMAKE_INSTALL_LIBDIR - они на самом деле хорошо видны (вместе со множеством других) в интерфейсе cmake-gui, когда проверено «Advanced».

Я попытался установить эти два вручную (bin\i686 и lib\i686), и это работает: цель Protobuf INSTALL копирует файлы туда, где я хотел их получить, то есть, где скрипт CMake моего потребительского проектанайдет их безопасным для архитектуры способом.

Я не уверен, что я чувствую по этому поводу - я бы предпочел что-то вроде переменной CMAKE_INSTALL_ARCHITECTURE или CMAKE_ARCHITECTURE_SUBDIR, которую CMake автоматически добавлял бы к соответствующей установкепути.Приведенное выше решение требует переопределения значений по умолчанию, которые я предпочел бы оставить нетронутыми.

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

В конце концов, я все еще не определился.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...