Skip to content

Commit

Permalink
trivial: fix typos
Browse files Browse the repository at this point in the history
Signed-off-by: Gerwin Klein <[email protected]>
  • Loading branch information
lsf37 committed Jul 2, 2024
1 parent 70ca1a2 commit d66da26
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions projects/buildsystem/standalone.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

0 comments on commit d66da26

Please sign in to comment.