depthai-core

depthai-core copied to clipboard

During the creation of a yocto recipe, I had to make several changes to this package CMakeLists.txt file.

In my opinion the top level CMakeLists.txt file can be simplified.

First thing I encountered was the modification of the CMAKE_TOOLCHAIN_FILE variable (https://github.com/luxonis/depthai-core/blob/main/CMakeLists.txt#L16). I believe this is wrong, position independent code should be turned on differently. I commented out this section, since yocto uses its own toolchain.

Furthermore, I disabled hunter, since yocto has its own package manager for dependencies. Building without hunter is possible, but required several tweaks to dependencies. This seems not tested. For example, this line breaks and should be surrounded with if-hunter-enabled checks: https://github.com/luxonis/depthai-core/blob/main/CMakeLists.txt#L595

Third, there exists a DEPTHAI_INSTALL variable, which is not required, we can create the install targets allways, make install is a seperate step, so no harm in creating those targets. In other words, this if can be removed: https://github.com/luxonis/depthai-core/blob/main/CMakeLists.txt#L575

I'm unsure how to proceed, should I create pull requests for those changes?

Hi @windelbouwman Sorry for late reply

The modification of toolchain is required for Hunter to build its dependencies accordingly (eg enabling PIC, etc...)

I've added "combining" of toolchains, which will be merged soon with #410

Regarding disabling Hunter - I agree, those should have the check added.

The install variable's reasoning is same as https://github.com/nlohmann/json/commit/f049836d686f5e7817682e700c3f4822fa03c9e7 - I'd leave it there.

Please do open a PR. We can then continue discussion of any potential changes there.

Thanks!

@windelbouwman I'm putting my hand up for those tweaks, I'd really benefit here with a non-hunter build setup. I am trying to build in Buildstream where there is no internet connection at the build step for predictability/reproducible reasons.

Cheers

Another idea to simplify things, is to merge two repositories into this repository:

• FP16 (https://github.com/luxonis/FP16)
• Xlink (https://github.com/luxonis/XLink)

If we copied those two repositories into this repository, maybe in a vendor folder, things would become simpler for packaging and building without hunter. Now, you'll probably have to write packaging scripts for those two repos, and they are only being used by depthai-core. Theoretically FP16 and Xlink might be used elsewhere, but I do not see that happening anytime soon :).

These are the changes I made to be able to build sort-off offline, without hunter. The binary blobs are downloaded as part of my package recipe script, just like the sourcecode itself.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index cf366f7..1e08086 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -113,7 +113,7 @@ endif()
 set(PROJECT_EXPORT_GROUP "${PROJECT_NAME}Targets")
 
 ## Check if cloned or sources
-find_package(Git)
+# find_package(Git)
 if(GIT_FOUND)
     execute_process(
         COMMAND ${GIT_EXECUTABLE} rev-parse --is-inside-work-tree
@@ -292,50 +292,50 @@ if($ENV{CI})
     set(DEPTHAI_BOOTLOADER_SHARED_COMMIT_HASH_ENFORCE ON)
 endif()
 
+if(DEPTHAI_BINARIES_RESOURCE_COMPILE)
 
-# Then get the Depthai device side binaries (local or download)
-if(DEPTHAI_CMD_PATH OR DEPTHAI_USB2_CMD_PATH OR DEPTHAI_USB2_PATCH_PATH)
-    # Atleast one of the paths is set. include binaries locally
-    message(STATUS "Using local Depthai device side binaries...")
+    # Then get the Depthai device side binaries (local or download)
+    if(DEPTHAI_CMD_PATH OR DEPTHAI_USB2_CMD_PATH OR DEPTHAI_USB2_PATCH_PATH)
+        # Atleast one of the paths is set. include binaries locally
+        message(STATUS "Using local Depthai device side binaries...")
 
-    DepthaiLocal(
-        PATCH_ONLY ${DEPTHAI_USB2_PATCH_ONLY_MODE}
-        "${DEPTHAI_RESOURCES_OUTPUT_DIR}"            # Output folder
-        DEPTHAI_RESOURCE_LIST                       # List of output resources
-        "${DEPTHAI_CMD_PATH}"                       # depthai.cmd
-        "${DEPTHAI_USB2_CMD_PATH}"                  # depthai-usb2.cmd
-        "${DEPTHAI_USB2_PATCH_PATH}"                # depthai-usb2-patch.patch
-    )
+        DepthaiLocal(
+            PATCH_ONLY ${DEPTHAI_USB2_PATCH_ONLY_MODE}
+            "${DEPTHAI_RESOURCES_OUTPUT_DIR}"            # Output folder
+            DEPTHAI_RESOURCE_LIST                       # List of output resources
+            "${DEPTHAI_CMD_PATH}"                       # depthai.cmd
+            "${DEPTHAI_USB2_CMD_PATH}"                  # depthai-usb2.cmd
+            "${DEPTHAI_USB2_PATCH_PATH}"                # depthai-usb2-patch.patch
+        )
 
-else()
-    # No user specified paths, download from server
-    message(STATUS "Downloading Depthai device side binaries from server...")
-
-    DepthaiDownload(
-        "${DEPTHAI_SHARED_COMMIT_HASH}" "${DEPTHAI_SHARED_COMMIT_HASH_ENFORCE}"
-        PATCH_ONLY ${DEPTHAI_USB2_PATCH_ONLY_MODE}
-        "${DEPTHAI_RESOURCES_OUTPUT_DIR}"            # Output folder
-        DEPTHAI_RESOURCE_LIST                       # List of output resources
-        "${DEPTHAI_DEVICE_SIDE_MATURITY}"           # Maturity
-        "${DEPTHAI_DEVICE_SIDE_COMMIT}"             # commit hash
-        "${DEPTHAI_DEVICE_SIDE_VERSION}"            # Optional version
+    else()
+        # No user specified paths, download from server
+        message(STATUS "Downloading Depthai device side binaries from server...")
+
+        DepthaiDownload(
+            "${DEPTHAI_SHARED_COMMIT_HASH}" "${DEPTHAI_SHARED_COMMIT_HASH_ENFORCE}"
+            PATCH_ONLY ${DEPTHAI_USB2_PATCH_ONLY_MODE}
+            "${DEPTHAI_RESOURCES_OUTPUT_DIR}"            # Output folder
+            DEPTHAI_RESOURCE_LIST                       # List of output resources
+            "${DEPTHAI_DEVICE_SIDE_MATURITY}"           # Maturity
+            "${DEPTHAI_DEVICE_SIDE_COMMIT}"             # commit hash
+            "${DEPTHAI_DEVICE_SIDE_VERSION}"            # Optional version
+        )
+    endif()
+    list(APPEND RESOURCE_COMPILED_FILES ${DEPTHAI_RESOURCE_LIST})
+
+    # Add bootloader
+    DepthaiBootloaderDownload(
+        "${DEPTHAI_BOOTLOADER_SHARED_COMMIT_HASH}" "${DEPTHAI_BOOTLOADER_SHARED_COMMIT_HASH_ENFORCE}"
+        "${DEPTHAI_RESOURCES_OUTPUT_DIR}"                # Output folder
+        DEPTHAI_BOOTLOADER_RESOURCE_LIST                # List of output resources
+        "${DEPTHAI_BOOTLOADER_MATURITY}"                # Maturity
+        "${DEPTHAI_BOOTLOADER_VERSION}"                 # if maturity == snapshot -> hash else version
     )
-endif()
-list(APPEND RESOURCE_COMPILED_FILES ${DEPTHAI_RESOURCE_LIST})
+    list(APPEND RESOURCE_COMPILED_FILES ${DEPTHAI_BOOTLOADER_RESOURCE_LIST})
 
-# Add bootloader
-DepthaiBootloaderDownload(
-    "${DEPTHAI_BOOTLOADER_SHARED_COMMIT_HASH}" "${DEPTHAI_BOOTLOADER_SHARED_COMMIT_HASH_ENFORCE}"
-    "${DEPTHAI_RESOURCES_OUTPUT_DIR}"                # Output folder
-    DEPTHAI_BOOTLOADER_RESOURCE_LIST                # List of output resources
-    "${DEPTHAI_BOOTLOADER_MATURITY}"                # Maturity
-    "${DEPTHAI_BOOTLOADER_VERSION}"                 # if maturity == snapshot -> hash else version
-)
-list(APPEND RESOURCE_COMPILED_FILES ${DEPTHAI_BOOTLOADER_RESOURCE_LIST})
-
-message(STATUS "LIST OF RESOURCE COMPILED FILES: ${RESOURCE_COMPILED_FILES}")
+    message(STATUS "LIST OF RESOURCE COMPILED FILES: ${RESOURCE_COMPILED_FILES}")
 
-if(DEPTHAI_BINARIES_RESOURCE_COMPILE)
     # Add RC and resource compile the binares
     include(CMakeRC)
 
@@ -400,11 +400,11 @@ target_link_libraries(${TARGET_CORE_NAME}
         libnop
     PRIVATE
         Threads::Threads
-        BZip2::bz2
+        BZip2::BZip2
         FP16::fp16
-        archive_static
+        LibArchive::LibArchive
         spdlog::spdlog
-        ZLIB::zlib
+        ZLIB::ZLIB
 )
 
 # Add compile definitions
@@ -559,8 +559,10 @@ configure_file("cmake/${PROJECT_NAME}Dependencies.cmake" ${PROJECT_NAME}Dependen
 write_basic_package_version_file(${PROJECT_NAME}ConfigVersion.cmake VERSION ${PROJECT_VERSION} COMPATIBILITY AnyNewerVersion)
 
 # Configure config file (one for exporting build directory, one for installation)
+if(HUNTER_ENABLED)
 file(RELATIVE_PATH DEPTHAI_DEPENDENCIES_INSTALLATION_PATH_REL "${CMAKE_CURRENT_BINARY_DIR}" "${HUNTER_INSTALL_PREFIX}")
 configure_file(cmake/${PROJECT_NAME}Config.cmake.in ${PROJECT_NAME}Config.cmake @ONLY)
+endif()
 
 # Config for installation
 set(DEPTHAI_DEPENDENCIES_INSTALLATION_PATH_REL "./dependencies")
@@ -591,7 +593,10 @@ if(DEPTHAI_INSTALL)
     # Install depthai-bootloader-shared public headers
     install(DIRECTORY "${DEPTHAI_BOOTLOADER_SHARED_PUBLIC_INCLUDE}/" DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}")
     # Install Hunter dependencies
+    if(HUNTER_ENABLED)
     install(DIRECTORY "${HUNTER_INSTALL_PREFIX}/" DESTINATION "${CMAKE_INSTALL_LIBDIR}/cmake/${PROJECT_NAME}/dependencies")
+    endif()
+
     # Install resources if not RC'd
     if(NOT DEPTHAI_BINARIES_RESOURCE_COMPILE)
         install(DIRECTORY "${DEPTHAI_RESOURCES_OUTPUT_DIR}/" DESTINATION "${CMAKE_INSTALL_DATAROOTDIR}/${PROJECT_NAME}")
diff --git a/cmake/GitCommitHash.cmake b/cmake/GitCommitHash.cmake
index 0b1a406..87a4c39 100644
--- a/cmake/GitCommitHash.cmake
+++ b/cmake/GitCommitHash.cmake
@@ -1,5 +1,5 @@
 # for commit hash
-find_package(Git)
+# find_package(Git)
 
 set(commit_version "unknown")
 
diff --git a/cmake/depthaiDependencies.cmake b/cmake/depthaiDependencies.cmake
index bbbd606..8c8387b 100644
--- a/cmake/depthaiDependencies.cmake
+++ b/cmake/depthaiDependencies.cmake
@@ -23,19 +23,19 @@ endif()
 if(NOT CONFIG_MODE OR (CONFIG_MODE AND NOT DEPTHAI_SHARED_LIBS))
 
     # BZip2 (for bspatch)
-    find_package(BZip2 ${_QUIET} CONFIG REQUIRED)
+    find_package(BZip2 REQUIRED)
 
     # FP16 for conversions
-    find_package(FP16 ${_QUIET} CONFIG REQUIRED)
+    find_package(FP16 REQUIRED)
 
     # libarchive for firmware packages
-    find_package(archive_static ${_QUIET} CONFIG REQUIRED)
-    find_package(lzma ${_QUIET} CONFIG REQUIRED)
+    find_package(LibArchive REQUIRED)
+    find_package(LibLZMA REQUIRED)
     # ZLIB for compressing Apps
-    find_package(ZLIB CONFIG REQUIRED)
+    find_package(ZLIB REQUIRED)
 
     # spdlog for library and device logging
-    find_package(spdlog ${_QUIET} CONFIG REQUIRED)
+    find_package(spdlog REQUIRED)
 
     # Backward
     if(DEPTHAI_ENABLE_BACKWARD)

To remove downloading:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1e08086..f859d1c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -276,16 +276,12 @@ endif()
 
 # Set constant
 set(DEPTHAI_RESOURCES_OUTPUT_DIR "${CMAKE_CURRENT_BINARY_DIR}/resources")
+message(STATUS "resource folder: ${DEPTHAI_RESOURCES_OUTPUT_DIR}")
 
 # Include configuration
 include(Depthai/DepthaiDeviceSideConfig)    # Depthai device binary commit/version configuration
 include(Depthai/DepthaiBootloaderConfig)    # Depthai bootloader binary commit/version configuration
 
-# Include downloaders
-include(DepthaiDownloader)                  # Depthai device binary downloader
-include(DepthaiBootloaderDownloader)        # Depthai bootloader binary downloader
-
-
 # depthai-shared enforce commit hash match if CI
 if($ENV{CI})
     set(DEPTHAI_SHARED_COMMIT_HASH_ENFORCE ON)
@@ -293,47 +289,9 @@ if($ENV{CI})
 endif()
 
 if(DEPTHAI_BINARIES_RESOURCE_COMPILE)
-
-    # Then get the Depthai device side binaries (local or download)
-    if(DEPTHAI_CMD_PATH OR DEPTHAI_USB2_CMD_PATH OR DEPTHAI_USB2_PATCH_PATH)
-        # Atleast one of the paths is set. include binaries locally
-        message(STATUS "Using local Depthai device side binaries...")
-
-        DepthaiLocal(
-            PATCH_ONLY ${DEPTHAI_USB2_PATCH_ONLY_MODE}
-            "${DEPTHAI_RESOURCES_OUTPUT_DIR}"            # Output folder
-            DEPTHAI_RESOURCE_LIST                       # List of output resources
-            "${DEPTHAI_CMD_PATH}"                       # depthai.cmd
-            "${DEPTHAI_USB2_CMD_PATH}"                  # depthai-usb2.cmd
-            "${DEPTHAI_USB2_PATCH_PATH}"                # depthai-usb2-patch.patch
-        )
-
-    else()
-        # No user specified paths, download from server
-        message(STATUS "Downloading Depthai device side binaries from server...")
-
-        DepthaiDownload(
-            "${DEPTHAI_SHARED_COMMIT_HASH}" "${DEPTHAI_SHARED_COMMIT_HASH_ENFORCE}"
-            PATCH_ONLY ${DEPTHAI_USB2_PATCH_ONLY_MODE}
-            "${DEPTHAI_RESOURCES_OUTPUT_DIR}"            # Output folder
-            DEPTHAI_RESOURCE_LIST                       # List of output resources
-            "${DEPTHAI_DEVICE_SIDE_MATURITY}"           # Maturity
-            "${DEPTHAI_DEVICE_SIDE_COMMIT}"             # commit hash
-            "${DEPTHAI_DEVICE_SIDE_VERSION}"            # Optional version
-        )
-    endif()
-    list(APPEND RESOURCE_COMPILED_FILES ${DEPTHAI_RESOURCE_LIST})
-
-    # Add bootloader
-    DepthaiBootloaderDownload(
-        "${DEPTHAI_BOOTLOADER_SHARED_COMMIT_HASH}" "${DEPTHAI_BOOTLOADER_SHARED_COMMIT_HASH_ENFORCE}"
-        "${DEPTHAI_RESOURCES_OUTPUT_DIR}"                # Output folder
-        DEPTHAI_BOOTLOADER_RESOURCE_LIST                # List of output resources
-        "${DEPTHAI_BOOTLOADER_MATURITY}"                # Maturity
-        "${DEPTHAI_BOOTLOADER_VERSION}"                 # if maturity == snapshot -> hash else version
-    )
-    list(APPEND RESOURCE_COMPILED_FILES ${DEPTHAI_BOOTLOADER_RESOURCE_LIST})
-
+    file(COPY "${DEPTHAI_BOOTLOADER_FWP}" DESTINATION "${DEPTHAI_RESOURCES_OUTPUT_DIR}")
+    file(COPY "${DEPTHAI_DEVICE_FWP}" DESTINATION "${DEPTHAI_RESOURCES_OUTPUT_DIR}")
+    file(GLOB RESOURCE_COMPILED_FILES "${DEPTHAI_RESOURCES_OUTPUT_DIR}/*.tar.xz")
     message(STATUS "LIST OF RESOURCE COMPILED FILES: ${RESOURCE_COMPILED_FILES}")
 
     # Add RC and resource compile the binares

As a follow up, I made a suggestion here, on how to include the FP16 library for example: https://github.com/luxonis/depthai-core/pull/492

Cheers @windelbouwman this looks similar to what I came up with but looks a lot cleaner than going to town with commenting out Hunter. I'm explicitly downloading up-front the firmware in the Buildstream script also.

Thanks @windelbouwman on the PR (wanted to post there first, but will be better to discuss here as it has more context).

I'm generally against monorepoing ext dependencies.

If we'd go in this direction, I'd prefer #492 being a submodule.

That said I think there is a better way of handling this - still using Hunter but not downloading these external dependencies but packing them together, to create a final source release (as for instance prepackaged shared submodules here: https://github.com/luxonis/depthai-core/releases/download/v2.15.5/depthai-core-v2.15.5.tar.gz)

This would have an added benefit of not being a separate maintanance configuration, but being very close to mainline.

• we can add in DepthaiLocal download option for resources and pack those along as well.

Final produced release tar.gz would then be completely enclosed and not requiring internet connection to compile.

Still, the public dependencies will have to be handled separately (nlohmann, libnop, optional opencv) (eg by system package manager, etc...). For that we'll also create a means of skiping only those to not being handled by Hunter.

Thoughts @windelbouwman @saching13 @boberfly ?

@themarpe sure that sounds great to me and would simplify things a great deal more

I'm generally against monorepoing ext dependencies.

What's your reasoning here? I think there is a distinction to make here, there are bigger third party libraries, such as opencv and libarchive. Those big libraries should not be mono-repoed any time soon. The other category of dependencies is the small FP16 header file, or the xlink repository. These libraries are either small in size or tied to depthai-core. For this second category of libraries mono-repo seems a good choice to me.

If we'd go in this direction, I'd prefer #492 being a submodule.

That would certainly be a better option in my opinion as well. One option would be to include FP16 as a submodule, and have a CMakeLists.txt file in the depthai-core repo. That way we could probably refer to the original version of FP16 as a submodule, no need for custom fork in which hunter support was added (I believe hunter support is the reason for the FP16 fork?).

That said I think there is a better way of handling this - still using Hunter but not downloading these external dependencies but packing them together, to create a final source release (as for instance prepackaged shared submodules here: https://github.com/luxonis/depthai-core/releases/download/v2.15.5/depthai-core-v2.15.5.tar.gz)

This sound great, having a tarball with all sourcecode required packaged would make a packagers life easier.

Still, the public dependencies will have to be handled separately (nlohmann, libnop, optional opencv) (eg by system package manager, etc...). For that we'll also create a means of skiping only those to not being handled by Hunter.

That's perfectly fine, there are already existing system packages for those common libraries. The main issue is the uncommon/forked/tuned libraries.

@windelbouwman For Yocto I would add an option for each dependency via XXX_USE_SYSTEM pattern for each dependency, defaulting to off. Then have the external projects and toolchain exist only if these flags are off. Then have independent recipes for each dependency. Happy to submit a PR and create the Yocto recipes.

@jwinarske that'd be great to add.

There is already such pattern in ros-release & ros-release_use_external_spdlog. Not yet generalized however.

HUNTER_SKIP_PACKAGE_xxx - where then the "finding of a specific dependency" falls back to the usual "find_package" mechanism of CMake

Let me know

@themarpe sure I'll put something together

@themarpe I had some time today and created meta-luxonis for Yocto kirkstone based on depthai-core v2.20.2: https://github.com/jwinarske/meta-luxonis

I haven't had time to validate runtime artifacts on hardware yet, but all the package installs look correct.

Summary

• I disabled all of the hunter related cmake
• removed install of dependencies, as yocto provides this based on dev packages, etc
• everything is discovered via "system libs"
• broke everything into separate recipes so nothing is hidden. This helps with SBOM creation.
• package config flags are used to set build time features
• two packages added - examples and tests
• bins get installed to /usr/bin/luxonis/examples + /usr/bin/luxonis/tests if enabled
• models get installed to /usr/share/luxonis/examples and models get installed to /usr/share/luxonis/tests if enabled

One thing that needs to be addressed on my end is disable the firmware download during configure, and pull during do_fetch. As having anything download during configure or compile prevents LTS and reproducible builds. What I wasn't clear on was is the what and why of the usb2 patching logic. I need to understand this.

I updated recipe to pull FWP external to CMake. Long Term Support (LTS) is now feasible.

One thing that needs to be addressed on my end is disable the firmware download during configure, and pull during do_fetch. As having anything download during configure or compile prevents LTS and reproducible builds. What I wasn't clear on was is the what and why of the usb2 patching logic. I need to understand this.

The USB2 patching is "deprecated"/not needed anymore. There is only an internal patching happening for various OpenVINO versions, but also that will likely go out of window soon. FWP download is all that is needed.

I updated recipe to pull FWP external to CMake. Long Term Support (LTS) is now feasible.

Awesome! We can likely pull such a PR into mainline of core

@themarpe Okay cool. Yeah I pruned that out, and implemented FWP download.

I just validated the layer on a Raspberry PI 4 64-bit OS image. All tests pass with exception of the stability_stress_test. All the examples I tried ran.

What's the common pattern to use a single set of FWP on filesystem? Set location using environmental variable? The resource compiled approach is cool for a single app, only the packages get quite big with tests and examples.

@jwinarske

The FWP resource compiled is still prefered due to tight integration between the library & FWP. I'd recommend a shared library in this case.

While intended, there isn't currently a mechanism to load the FWP from OS instead. TBD

Sounds great - the stability_stress_test isn't well defined at the moment and might cause issues in some runs. So if all others went through, is definitely looking good!

@themarpe Okay cool. I have some more work to do on a formal PR for Hunter re-work. I made a first pass then switched to the Yocto layer so I could better understand how things worked.

@jwinarske great - any big changes to address eg. Dunfell or other Yocto version with the current layer?

@themarpe For a dunfell branch it just needs minor changes for specifier change. ':' -> '_'. I'll sort out shared flag option first, then create a dunfell branch. That would cover the two current Yocto LTS releases. For post kirkstone it's just a matter of adding the name to the config file. e.g. langdale.

@themarpe I added support for shared build in kirkstone, and started dunfell. It looks like between do_configure_prepend and do_configure the filesystem gets cleared. Not sure what's happening will look later. But that should be last issue in dunfell

If your working on yocto, the snippet in this issue might be of use: https://github.com/luxonis/depthai-core/issues/447

Specifically this comment: https://github.com/luxonis/depthai-core/issues/447#issuecomment-1164015416

@windelbouwman I saw that in kirkstone when I used a newer version of spdlog. I created a new recipe called spdlog-luxonis that matches the version in the release. This works since I'm not building spdlog as a shared module; so no install conflict. The other option I initially used was set a PREFERRED_VERSION_spdlog, which I since removed. It's FOSS: https://github.com/jwinarske/meta-luxonis

Kirkstone branch has been validated. Dunfell should be done today.

@themarpe dunfell is done, just needs target validation. Minor changes. One was with stability test on c++20, which was complaining about missing pthread function. I added generic pthread detection pattern for this. langdale branch created, and main updated to langdale. Only one known issue is around use of rm_work.bbclass, which will get resolved with CMake refactor.

meta-luxonis now supports:

• main (currently langdale)
• langdale
• kirkstone
• dunfell

When is your next planned release? It would be good to line up CMake refactor.

@jwinarske Nice work! @themarpe would it be possible to use upstream/unpatched versions of libarchive, spdlog and backward? This would simplify things as well.

Thanks both! Great to see this worked on.

@jwinarske Planned release in a couple of weeks - still having some TODOs to iron out first.

@windelbouwman backward & spdlog should be okay as is (check the before mentioned branch, which tries relying on quite an old spdlog version, by backporting skme things). Libarchive a fork is used due to Hunter. Otherwise shouldn't be needed. That is if this skip mode is used, system version could be relied upon

@themarpe I have a functioning proof for Hunter replacement. Can you take a look and tell me if this would suffice for depthai-core? I'd like to ensure I'm not headed down the wrong path. In theory it should be 100% platform agnostic in it's current state. Thanks

https://github.com/jwinarske/cmake_json

This seems like shifting the problem from using hunter, to using cmake_json. At least in yocto there is already a system for managing dependencies, so in yocto we would then have to patch the cmake_json usage, to use yocto's dependency management.

@windelbouwman

A configuration dataset is factored out into a single file: https://github.com/jwinarske/cmake_json/blob/main/configuration.json This follows the pattern in my depthai-core Yocto recipe: https://github.com/jwinarske/meta-luxonis/blob/main/recipes-multimedia/depthai-core/depthai-core_2.20.2.bb

Selection between system libraries and staged sysroot happens here: https://github.com/jwinarske/cmake_json/blob/main/cmake/configuration.cmake#L5 My meta-luxonis recipes solely target system library use cases.

The cmake_json repo is only meant for storing the proof of concept, nothing beyond. I plan to integrate the functionality into depthao-core via PR. The repository isolates the concept into a Minimum Viable Product (MVP) to communicate the approach.

The JSON concept addresses artifact downloading, managing dependent libraries, and managing release variables.

I'm taking into account the following platform support:

• Mac OSX (Host)
• Mac iOS (Cross Canadian, Toolchain file)
• Android (NDK, Cross Canadian, Toolchain file)
• Windows (Host / Cross Canadian)
• Linux (Host / Cross Canadian)
• Yocto (Cross Canadian, Toolchain File, Reproducible builds, ROS via meta-ros)
• Buildroot (Cross Canadian, Toolchain file)
• CI use case support for the above. Should enable CI build matrix.

I may have missed something, but in general the approach of using JSON to isolate the configuration data enables the following:

1. Single file for defining release components
2. Isolates data from behavior logic
3. Easy way to swap configs to try out artifact changes, or revert to a prior release dataset
4. Enables options for CI regression testing
5. Provides a way to auto-roll Yocto recipe release versions; using a Python utility script to auto-generate a recipe version include

As you can see there are plenty of tasks left that will have an important impact in "Simplifying the CMake". The JSON config is just one piece of the puzzle.