Я не знаком с Базелем, но, возможно, могу пролить свет на то, что нужно / ожидает cppyy. В частности, FindCppyy.cmake был написан с определенным типом использования c, который может подходить не всем.
Что нужно для cppyy, так это чтобы были доступны символы компоновщика кода C ++, используемого из Python во время выполнения. То, как они сделаны доступными, не имеет значения: пока они есть, это будет работать. Вот несколько вариантов:
Связать зависимые библиотеки с другой библиотекой, которая будет загружена. Это типично при использовании словарей (https://cppyy.readthedocs.io/en/latest/utilities.html#dictionaries): просто свяжите всю соответствующую библиотеку с общей библиотекой словаря, затем только загрузите словарь, остальное будет извлечено динамическим компоновщиком c. Это наиболее распространенный метод AFAIK, именно b / c зависимости легко определить, поскольку инструмент сборки уже имеет их и уже знает, как их связать.
Добавьте их в файл .rootmap (https://cppyy.readthedocs.io/en/latest/utilities.html#class -loader ): когда класс не найден, файлы .rootmap (которые должны находиться по некоторому пути, достижимому LD_LIBRARY_PATH в Linux / Ma c или PATH на Windows) выполняется поиск, и если класс найден там, все указанные библиотеки загружаются. Это было бы моим предпочтением (b / c class-lazy, а не project-lazy) и часто используется вместе с файлом словаря, как указано выше.
Использование cppyy.load_library явно в пределах Python модуль. Лично я не предпочитаю это, если код действительно хорошо комплементирован, и / или проект невелик (всего несколько библиотек), так как этот подход не ленив.
Используйте другое средство, например ctypes.CDLL. Это будет работать, но ctypes.CDLL ведет себя очень по-разному от одной ОС к другой, откладывая больше работы на разработчика, поэтому я бы не рекомендовал это. Это также не лениво.
Упомянутые макросы cppyy cmake предполагают, что целью является один python модуль на проект, и что в качестве детализации лени, проект (в отличие от отдельных классов ) достаточно хорошо. Если это соответствует вашим целям, то я бы go для первого варианта выше: сгенерировать словарь из всех заголовков для (каждой части) проекта и получить список библиотек для него из Bazel, а затем при создании сгенерированного Код словаря, просто ссылка с ним. Наконец, положитесь на автоматическую загрузку или просто load_library на одну общую библиотеку словаря.
Теперь, если я отвечу на ваш вопрос буквально (не знаю, стоит ли мне это делать), тогда может быть вариант чтобы Bazel явно загружал библиотеки в процесс, например, при запуске? Если это так, это будет работать до тех пор, пока библиотеки загружаются с флагом RTLD_GLOBAL (Linux, Mac; это распространено) или экспортируются соответствующие символы (Windows; также распространено, но требует большего внимания).