From d66da26e9426ae59e031099fc199e7461a738a43 Mon Sep 17 00:00:00 2001 From: Gerwin Klein Date: Tue, 2 Jul 2024 12:44:24 +1000 Subject: [PATCH] trivial: fix typos Signed-off-by: Gerwin Klein --- projects/buildsystem/standalone.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/buildsystem/standalone.md b/projects/buildsystem/standalone.md index 2c9daff4e0..77b308e19a 100644 --- a/projects/buildsystem/standalone.md +++ b/projects/buildsystem/standalone.md @@ -128,6 +128,6 @@ Note that the contents of the `support/` directory may differ depending on the t It is non-trivial to take a standalone kernel.elf and use it in another build environment. This is because the system configuration is not exported with the kernel.elf and so a different build environment will need to know exactly how the kernel was configured so that bootloaders and userlevel applications can be configured in a compatible way. Using the CMake scripts provided in seL4_tools and importing the kernel into an existing CMake project hierarchy will ensure that the system configuration is properly shared with other parts of the project. -However sometimes a standalone build is required when the kernel is being used in a different environment that doesn't use a CMake based build system. One example of this is the verification project, L4V, that uses the stand alone build to poroduce the source and binary artifacts that the verification is performed on. +However sometimes a standalone build is required when the kernel is being used in a different environment that doesn't use a CMake based build system. One example of this is the verification project, L4V, that uses the stand alone build to produce the source and binary artifacts that the verification is performed on. -Other use cases include projects that want to build a non-C roottask, or projects that are already sophisticated enough to manage the different configuration settings that the kernel requires. In these scenarios, it would be expected that these projects provide their own Configuration.cmake files that have correct configurations. +Other use cases include projects that want to build a non-C root task, or projects that are already sophisticated enough to manage the different configuration settings that the kernel requires. In these scenarios, it would be expected that these projects provide their own Configuration.cmake files that have correct configurations.