On Fri, Nov 6, 2020 at 10:24 AM Chris Koziarz
I'm setting up a new application (and the libraries coming with it) but I have hard time figuring out the process of building, esp. how CMake knows where to start building from.. By way of example, I'm trying to follow the process of setting up and building sel4test. Setting up the source dir structure:
repo init -u https://github.com/seL4/sel4test-manifest.git & repo sync
and creating the build dir
md build & cd build
Are perfectly understandable steps: create source tree that includes the app sources (./projects/sel4test/apps/sel4test-driver/ in this case) kernel (./kernel/) libraries (other subdirs under ./projects/) and misc tools (./tools/) and an extra subdir for build output The third "magic" CMake setup step
../init-build.sh -DPLATFORM=<platform> -DRELEASE=FALSE -DSIMULATION=TRUE
enables a simple "ninja" command (without any params) to build an application from the sources at ./projects/sel4test/apps/sel4test-driver/ This is a mystery to me. Where is the target (sel4test-driver) specification in these steps? I looked into init-build.sh and my understanding is the CMake setup must be carried by this command:
cmake -G Ninja "$@" -DSEL4_CACHE_DIR="$CACHE_DIR" -C "$project_dir/settings.cmake" "$project_dir"
You are right about this CMake command being how CMake is told to initialize a project. I'll quickly break down the components: - "-G Ninja" is setting the ninja build program for building the project (if this was left out CMake would default to Makefiles, but ninja is faster and has more features that we rely on that won't work with Makefiles) - "$@" Is for passing through any CMake cache options for configuring a particular build. seL4Test expects the options described in the easy-settings.cmake file such as SIMULATION, VERIFICATION or PLATFORM. These get used as initial CMake cache values and are effectively input arguments for the CMake build scripts. Projects like camkes-manfiest use CAMKES_APP for picking which application to build as the root task. - "-DSEL4_CACHE_DIR="$CACHE_DIR"" sets a directory that contains binaries for some intermediate build artifacts that take a while to build but don't change often. There isn't a requirement to use this option, but if you use it the builds will be a bit faster. It contributes to these output lines during a CMake script invocation: -- Detecting cached version of: capDL-tool -- Found valid cache entry for capDL-tool -- Detecting cached version of: musllibc -- Found valid cache entry for musllibc Finding a valid cache entry means that instead of building musllibc, the build will just copy the build version into the build directory. This cache is keyed on the muslc sources and build flags used to build muslc so there should only be a cache hit when the build would produce an identical binary. - "-C "$project_dir/settings.cmake"" Tells CMake to evaluate the settings.cmake file before loading the first CMakeLists.txt file. This is primarily needed for setting the cross-compilation options and setting CMAKE_TOOLCHAIN_FILE which can only be set once early in the CMake project initialization phase. The settings.cmake file also sets a series of project options at the same time as this in order to avoid any circular dependency issues that can otherwise arise (For example the application wants to specify the kernel configuration that it wants, but also needs to depend on kernel configurations that depend on how it configured the kernel). - "$project_dir" is the directory of the first CMakeLists.txt file for CMake to process. CMake variables are hierarchically scoped and so the order in which CMakeLists.txt files are processed is important. As sel4test is the application that you are building, the sel4test/CMakeLists.txt file gets processed first and it has to be responsible for importing and configuring all of the CMake files for the artifacts that it depends on (including the kernel, elfloader and user libraries). It is the seL4test project that declares sel4test-driver as the root app of the system. This is achieved with the `DeclareRootserver(sel4test-driver)` command which takes the sel4test-driver target and uses it to create a final target "rootserver_image" which will produce the final images for booting with. Ninja builds all targets that haven't been marked with EXCLUDE_FROM_ALL when they were defined. By convention all targets that get created have this property except the final rootserver_image one. So instead of calling ninja you could call ninja rootserver_image and have the same effect. You can also explicitly build any other target by specifying its name to ninja (eg ninja sel4test-driver). init-build.sh is a helper script that expects a specific directory layout and crafts the CMake initialization command with all of the default options. It looks for a easy-settings.cmake symlink in the top directory and uses realpath to resolve that to the actual application source directory. This is how $project_dir is set. This symlink is created by the repo tool and is described in the project's repo manifest file. If you were making your own project you could more easily just create a script that calls cmake with the arguments that you want and avoid using init-build.sh. If you want to use init-build.sh then you need to create a settings.cmake and easy-settings.cmake files in your app directory and symlink the easy-settings.cmake file to the directory where your init-build.sh script is. Or you might be able to symlink init-build.sh to the same directory as you app and just execute it from your build directory instead. Hope this clarifies things more. Kent.
but I cannot figure how said command finds that the application we are trying to build is located in ./projects/sel4test/apps/sel4test-driver/ Now, when I try to setup my own app, how do I tell init-build.sh command where my app is?
Thanks for any clarification, Chris _______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel