Обработка бинарных зависимостей на разных платформах

Question

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

Однако у нас есть один двоичный файл, который зависит от кода на Фортране и т. Д. И который действительно сложен для сборки. Для Linux он также недоступен в виде пакета, но только в виде предварительно скомпилированных двоичных файлов или с полным исходным кодом (требуется установленная библиотека BLAS и несколько других зависимостей). Для окон та же библиотека доступна в двоичном виде, сборка для Windows кажется еще более сложной.

Вопрос в том, как вы справляетесь с такими зависимостями? Просто отметьте двоичные файлы для поддерживаемых платформ и попросите пользователя настроить свою среду сборки иначе (то есть вручную указать на двоичное местоположение), или вы действительно попытаетесь собрать их вместе (даже если это требует установки как 10 библиотек - библиотеки BLAS - самая большая проблема здесь), или есть какой-то другой рекомендуемый способ справиться с этим?

Answer 1

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

Answer 2

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

Я сделал нечто подобное. Я проверил архивы исходного кода необходимых мне библиотек / бинарных файлов. Затем я написал make-файл / сценарии, чтобы построить их в соответствии с целевой платформой / флагами в определенном месте (без стандартного расположения ОС) и сделать так, чтобы основной процесс сборки указывал на правильное местоположение. Я сделал это, чтобы иметь возможность обрабатывать правильные версии и опции нужных мне библиотек / бинарных файлов. Сделать работу на разных платформах довольно сложно, но оно того стоит!

О, и, конечно, проще, если вы используете инструменты кроссплатформенной сборки:)

Answer 3

Один вопрос к тебе. Нужно ли пользователям модифицировать этот двоичный файл, или они просто счастливы, что он есть, чтобы он мог использовать / получить к нему доступ? Если им не нужно изменять его, проверьте двоичные файлы.