Один из способов решения проблемы - создать два отдельных пакета conan для статических и общих библиотек и включить требуемый статический пакет в файл conanfile, но это приведет к избыточности для управления артефактами (одинаковые файлы заголовков будут присутствовать в нескольких пакетах).
Это было бы моим первым предложением. Но не как два отдельных пакета, а с использованием одного и того же рецепта пакета с options={"shared": [True, False]}, и заставить его генерировать 2 разных двоичных файла пакета (но для одного и того же пакета. Если у вас нет огромной библиотеки с тысячами заголовков (и даже при этом), влияние в время загрузки и место на диске действительно мало. Это могло бы стать проблемой, если бы пакеты создавались или устанавливались вручную, но, поскольку все происходит автоматически, вы этого не заметите. Преимущество этого подхода заключается в более простом обслуживании в будущем, если некоторая конфигурация. h (с разной конфигурацией для разных платформ или статический / общий) или разные заголовки для разных платформ, обычно "header_win.h" и "header_linux.h" , можно полностью автоматизировать с помощью conan, чтобы получить единственный "header.h", который был бы прозрачен для потребителей.
Если вы все же не хотите, чтобы это дублирование было, могут быть разные подходы:
Во-первых, вы можете создать пакет "PkgHeaders" только с заголовками, которые будут required из пакета "Pkg", который будет содержать только двоичные файлы (общие или статические )
Другой подход: вы можете сделать так, чтобы пакет «Pkg» содержал как статическую, так и совместно используемую версии. Это было бы похоже на пакет с несколькими конфигурациями выпуска / отладки, описанный здесь, в документации. Идея в том, что в пакете нет опции shared. Он создаст и упакует оба. Метод package_info() объявит разные переменные для каждой, что-то вроде
def package_info(self):
self.cpp_info.shared.libs = ["libX.so"]
self.cpp_info.static.libs = ["libX.a"]
Это приведет к созданию различных переменных CMake в сгенерированном conanbuildinfo.cmake
set(CONAN_LIBS_SHARED libX.so ${CONAN_LIBS_SHARED})
set(CONAN_LIBS_STATIC libX.a ${CONAN_LIBS_STATIC})
Обратите внимание, однако, что эти переменные не будут использоваться в потребителе автоматически, но вам придется явно решить, какую из них использовать.
Так что дополнительных сложностей не стоит. Если в вашей библиотеке нет сотен мегабайт заголовков, я бы обязательно выбрал первый подход.
person
drodri
schedule
11.04.2018
