Наличие другой версии зависимости на основе профиля conan

Question

У нас есть несколько проектов для встроенных Linux сред. Мы переходим на Конан для нашего управления зависимостями. Общие библиотеки для этих проектов превращаются в пакеты conan. Эти пакеты создаются для нескольких платформ с использованием одной и той же базы кода. Для этих проектов мы используем googletest в качестве основы для модульного тестирования.

Для этих встроенных сред мы привязаны к кросс-компиляторам, поставляемым нам нашим поставщиком. Мы привязаны к g cc 4.4.3 и 5.2.0 для кросс-компиляции нашего кода, что приводит к различным пакетам построения поведения. Поскольку мы используем googletest, я кросс-компилирую версию googletest и добавляю ее в свой артефакт, чтобы можно было разрешить зависимости. Я только что сделал простой conanfile.py для googletest, чтобы создать его, вызывая обычный cmake, но, к сожалению, я не могу собрать версии 1.8.1 и 1.10.0 с использованием кросс-компилятора g cc 4.4.3.

Возможные решения:

1. Продолжайте использовать версию googletest 1.8.0 для каждого проекта. Возможно, но с недостатком - невозможность использования новых функций googletest.
2. Нет юнит-тестов при использовании профиля g cc 4.4.2. Возможно, но из-за того, что мы определили test_package, он хочет создать модульные тесты. Мы можем обойти это, указав несуществующую тестовую папку при создании пакета. Но это означает другую команду для создания пакета.
3. Используйте версию 1.8.0 при сборке для профиля g cc 4.4.3 и используйте более новую версию для других профилей. Возможно?

Хотя при сборке для разных платформ у меня есть кодовая база и один conanfile.py для определения пакета. Используя опции --profile, я кросс-компилирую для разных архитектур. Я хотел бы сохранить это так.

Я попытался указать версию пакета googletest как [> = 1.8.0] в надежде, что для профиля g cc 4.4.3 он подберет Версия 1.8.0, так как это единственная версия с двоичными файлами для этой архитектуры. К сожалению, он находит новые версии и выдает ошибку, что отсутствует готовый пакет для новой версии.

Как сделать так, чтобы один профиль использовал версию 1.8.0 зависимости, а другой профиль использовал версию 1.10 .0 для зависимости?

Одна вещь, которую я хочу предотвратить, - это проверка на основе настроек профиля в моем conanfile.py, так как это создаст зависимость между файлами. Это может заставить меня изменить conanfile.py при добавлении или удалении профилей в будущем.

Answer 1

Вы можете напрямую объявить build_requires в профилях, например:

[settings]
compiler=gcc
compiler.version=4.4.3

[build_requires]
gtest/1.8.0

И

[settings]
compiler=gcc
compiler.version=5.2.0

[build_requires]
gtest/1.10.0

Эти требования к сборке применяются ко всем пакетам, которые нужно собрать, но Вы также можете определить, к каким пакетам они применяются. Вы можете проверить в рецептах, используется ли эта сборка, и если ваш профиль не объявляет gtest как сборку, то пропустите тестирование.

Проверка https://docs.conan.io/en/latest/reference/profiles.html

Answer 2

Используйте версию 1.8.0 при сборке для профиля g cc 4.4.3 и используйте более новую версию для других профилей. Возможно?

Да, вполне возможно.

Но сначала вы должны понять, что test_package не для модульного тестирования вашего проекта. Пакеты тестов создаются только для проверки вашего пакета. Если вы хотите протестировать свой проект с использованием Conan, это следует сделать на этапе сборки:

class LibConan(ConanFile):
    ...

    def build_requirements(self):
        if self.settings.compiler == "gcc" and tools.Version(self.settings.compiler.version) < "5":
            self.build_requires("gtest/1.8.1")
        elif self.settings.compiler == "gcc":
            self.build_requires("gtest/1.10.1")

    def build(self):
        cmake = CMake(self)
        cmake.configure()
        cmake.build()
        if self.develop:
            cmake.test()

. Вы можете получить дополнительную информацию о development и unit test в Conan docs .

Теперь об этом примере build_requirements устанавливает пакет GTest в соответствии с версией вашего компилятора и его именем, в данном случае G CC <5. Кроме того, <code>self.develop доступно только при сборке пакета (команда conan create), поэтому модульные тесты запускаются только при создании, а не при установке.