CMake FetchContent module

Tools
,
1

Noticed this in the LVGL docs:

https://cmake.org/cmake/help/latest/module/FetchContent.html

The LVGL example illustrates well how this might be used:

cmake_minimum_required(VERSION 3.14)
include(FetchContent)

project(MyProject LANGUAGES C CXX)

# Build an executable called "MyFirmware"
add_executable(MyFirmware src/main.c)

# Specify path to own LVGL config header
set(LV_CONF_PATH
    ${CMAKE_CURRENT_SOURCE_DIR}/src/lv_conf.h
    CACHE STRING "" FORCE)

# Fetch LVGL from GitHub
FetchContent_Declare(lvgl URL https://github.com/lvgl/lvgl.git)
FetchContent_MakeAvailable(lvgl)

# The target "MyFirmware" depends on LVGL
target_link_libraries(MyFirmware PRIVATE lvgl::lvgl)

I generally prefer Git submodules for tasks like this, but nevertheless interesting.

2

yeah this fetch module is well known in OE/yocto circuits because when you disable Network access during build ( which makes sense in many cases ) these packages started to fail to build. Generally for distro builders its a headache, but for app builders its perhaps a good thing. May be development part and distribution part should be designed separately in packages in general.

3

yeah, fetchers are a double edged sword – very convenient when the upstream sources exist, a real pain when they don’t. The source cache that Yocto uses makes a lot of sense. It seems Go and other package managers also maintain a cache – perhaps part of the build system tooling should be to maintain these caches and offer ways to back them up or replicate them.

4

Right. I think needs of developers are a bit different than say a distribution engineer or release engineer. A best component build system is one which can address both of these use cases. As a developer I always think hard, how can I make my user to consume my software easily. distro builders are also sort of users. If a project keeps this consideration then it gets a wide distribution platform.