Components are a group of build targets that can be built and installed
separately. Whether a component should be built can be configured with
CMake arguments: -DBUILD_<NAME>=ON|OFF, where <NAME> is the name of the
component (in all caps).
Components can be marked as REQUIRED if they're necessary for a
minimally functional base system or they can be marked as RECOMMENDED
if they're not strictly necessary but are useful for most users.
A component can have an optional description which isn't used by the
build system but may be useful for a configuration UI.
Components specify the TARGETS which should be built when the component
is enabled. They can also specify other components which they depend on
(with DEPENDS).
This also adds the BUILD_EVERYTHING CMake variable which lets the user
build all optional components. For now this defaults to ON to make the
transition to the components-based build system easier.
The list of components is exported as an INI file in the build directory
(e.g. Build/i686/components.ini).
Fixes#8048.
PR #7970 added a line clarifying the requirement for QEMU 5.
Unfortunately, this location this line was added changed the meaning
of the following line, referencing the availability of GCC in Ubuntu
20.04.
QEMU 5 is not available in Ubuntu 20.04, so this change is incorrect,
as well as misleading.
This option replaces the use of ENABLE_ALL_THE_DEBUG_MACROS in CI runs,
and enables all debug options that might be broken by developers
unintentionally that are only used in specific debugging situations.
When debugging kernel code, it's necessary to set extra flags. Normal
advice is to set -ggdb3. Sometimes that still doesn't provide enough
debugging information for complex functions that still get optimized.
Compiling with -Og gives the best optimizations for debugging, but can
sometimes be broken by changes that are innocuous when the compiler gets
more of a chance to look at them. The new CMake option enables both
compile options for kernel code.
This only tests "can it be parsed", but the goal of this commit is to
provide a test framework that can be built upon :)
The conformance tests are downloaded, compiled* and installed only if
the INCLUDE_WASM_SPEC_TESTS cmake option is enabled.
(*) Since we do not yet have a wast parser, the compilation is delegated
to an external tool from binaryen, `wasm-as`, which is required for the
test suite download/install to succeed.
This *does* run the tests in CI, but it currently does not include the
spec conformance tests.
If you don't need/want to use Fuse+ex2 then half of the existing
install command is unnecessary, and it's hard to pick out which you
do and don't need to, for example, build Lagom. This makes it clear
which commands you can skip if you don't need ex2 support.
- Fix headings
- Consistent & more accurate code block language specifiers
- Add some newlines where appropriate
- Remove the strange "run ninja but actually you don't have to run ninja
as ninja install takes care of that" part
- Don't repeat specific build commands in "Ports" section
- Reword "Keymap" section to more generic "Customize disk image"
The QEMU's `--accel hvf` command was recently enabled in the `run.sh`
script, but it sadly doesn't work on macOS Big Sur: you need to first
sign your code by adding an `entitlements.xml` file and running a
simple command.
I just ran through successfully building and running SerenityOS under
macOS. I ran into two main things that I struggled with, which were
- properly enabling osxfuse (through System Preferences)
- running the suggested command about compiler versions in such a way
that would be compatible with Ninja (as it turns out, I just needed
to add `-G Ninja` to the command)
This commit clarifies those things for anyone who may follow
We already have installation instructions for ubuntu but not yet for
Debian. Gcc-9 is not available on Debian stable so instructions for
switching to and from Debian testing are added.
Gcc 8.3.0 (which is the current version in debian 10 stable) seems to
fail at building AK. New people might get stuck when they try to run
make inside the ./Build folder and fail at building serenity.
It seems that new people go to the build instructions from the main
README, don't see Windows and are then stuck.
We do have instructions for Windows, but they aren't noted in the build
instructions, so new people get stuck thinking there's no way to build
on Windows.
