Prototype Boot2Qt Conan approach

Test proof of concept, how to use Conan for B2Qt. 

• Yocto/b2qt builds generate conan profiles that match the build configurations
  • most of the build configuration options are set as cmake arguments which can be easily transferred from Yocto builds to profiles
  • package the generated profiles along with B2Qt product in Qt Installer
• Conan support via Qt Installer
  • During the installation of the selected B2Qt target build configurations conan client is called to create the conan packages on the fly from existing B2Qt target binaries
    • $ conan export-pkg <args> --profile=<b2qt target build profile)
  • When populating the conan cache qtbase module artifact(s) contain only custom "bin/qt-configure-module" script:
    • #!/bin/sh -x
      /home/sapiippo/Qt/test/conan/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/qt-configure-module $@
  • When populating the conan cache with leaf modules those packages are left empty
  • Use-case1: User deletes the local cache
    • Qt Installer can be used to re-install the packages -> re-populates the conan cache
  • Use-case2: User has different build configuration (done locally?)
    • User can run the same scripts manually to populate the conan cache with these artifacts
• Open items/issues:
  • No known way to support purely cmd line usage
    • qtbase (b2qt target) package is tied to sdk which can be installed anywhere
  • B2Qt snapshots are produced at different pace than Qt6.x snapshots so those may be created from different sha1's
    • This means that the related conan packages may be created from different sha1's (git sha1 of each Qt module repo)
      • This means that the conan recipe revision (per package) may differ between b2qt and Qt6
        • Installation of B2Qt Conan packages (via installer) may override conan packages in local cache installed earlier by the user (selecting regular Qt6.x conan packages)
        • User invoking "$ conan install <package> --update --remote qt" will cause packages from server to override the conan packages created (on the fly) by the B2Qt install scripts (Qt Installer)
    • preferably B2Qt snapshots should be created at the same pace as Qt6.x conan packages
  • When populating the local conan cache with "conan export-pkg" the dependency tree must be known or the check-sums may get wrong by Conan
    • For the current module checksum conan will include the checksums of all transitive dependencies -> order will matter
    • E.g. if running export-pkg for qtdeclarative before it has been ran for qtsvg Conan will check where to find qtsvg recipe and if not present in local cache it will find it from "qt" remote. At this point if the sha1's of the local and remote qtsvg should differ -> different checksum for qtdeclarative recipe revision -> re-using of pre-built binaries from server will get broken