| Age | Commit message (Collapse) | Author |
|---|
|
Previously, `serenity.sh rebuild-toolchain x86_64 clang` would simply
start building GCC instead and call it a day. With this change, if a
toolchain is passed as an argument, it is validated if it is either
"GNU" or "Clang" and exits with an error otherwise.
The `TOOLCHAIN` value defaults to the `SERENITY_TOOLCHAIN` environment
variable if not provided explicitly.
|
|
Various Clang binaries are now considered when choosing the compiler for
Lagom.
The selection precedence is as follows:
1. Use the compiler set via CC/CXX if it's a supported version
2. Use newest available GCC if it's supported
3. Use newest available Clang if it's supported
Note that Apple Clang is still not supported, as its versioning scheme
and the fact that it masquerades as both GCC and Clang would complicate
this logic even more.
Fixes #12253
|
|
I'm not sure when this changed, but the path is wildly different now.
|
|
This lets GDB resolve the kernel symbols correctly.
|
|
Because of ninja's default behavior of using all processors this gave
the correct behaviour because MAKEJOBS was empty. However this meant
that the processor count was printed to stderr when building.
|
|
The default behavior of using all cores will still apply if no
MAKEJOBS variable is supplied.
|
|
We now pass along the toolchain type to all subcommands. This ensures
that gdb will load the correct debug information for kernels compiled
with Clang, and the following warning won't appear with the GNU
toolchain:
> WARNING: unknown toolchain 'gdb'. Defaulting to GNU.
> Valid values are 'Clang', 'GNU' (default)
|
|
|
|
Also add a check to serenity.sh to ensure that the toolchain is new
enough for this feature to work.
|
|
Bump macOS CI version to macOS 11 while we're here.
|
|
egcc is the alias for the GCC compiler (since OpenBSD uses Clang by
default). Toolchain/BuildIt.sh has the necessary adjustments, but the
compiler check occurs before BuildIt.sh is called.
|
|
This is just silly :^)
$ serenity run lagom js
WARNING: unknown toolchain 'js'. Defaulting to GNU.
Valid values are 'Clang', 'GNU' (default)
|
|
'bootmode' now only controls which set of services are started by
SystemServer, so it is more appropriate to rename it to system_mode, and
no longer validate it in the Kernel.
|
|
Bootmode used to control panic behavior and SystemServer.
This patch factors panic behavior control into a separate flag.
|
|
Bootmode used to control framebuffers, panic behavior, and SystemServer.
This patch factors framebuffer control into a separate flag.
Note that the combination 'bootmode=self-test fbdev=on' leads to
unexpected behavior, which can only be fixed in a later commit.
|
|
With this, the subcommands 'addr2line` and `kaddr2line` work as with the
GNU toolchain.
|
|
This commit updates the Clang toolchain's version to 13.0.0, which comes
with better C++20 support and improved handling of new features by
clang-format. Due to the newly enabled `-Bsymbolic-functions` flag, our
Clang binaries will only be 2-4% slower than if we dynamically linked
them, but we save hundreds of megabytes of disk space.
The `BuildClang.sh` script has been reworked to build the entire
toolchain in just three steps: one for the compiler, one for GNU
binutils, and one for the runtime libraries. This reduces the complexity
of the build script, and will allow us to modify the CI configuration to
only rebuild the libraries when our libc headers change.
Most of the compile flags have been moved out to a separate CMake cache
file, similarly to how the Android and Fuchsia toolchains are
implemented within the LLVM repo. This provides a nicer interface than
the heaps of command-line arguments.
We no longer build separate toolchains for each architecture, as the
same Clang binary can compile code for multiple targets.
The horrible mess that `SERENITY_CLANG_ARCH` was, has been removed in
this commit. Clang happily accepts an `i686-pc-serenity` target triple,
which matches what our GCC toolchain accepts.
|
|
It's "Clang" (capitalized). Silently building gcc if the toolchain
isn't know seems a bit unfriendly. So print a warning for this
(and for other unknown toolchains).
|
|
If the superbuild created the lagom binary directory, it won't set
BUILD_LAGOM=ON in the CMake cache for that binary directory. Insert a
check into build_target() to make sure that if the user explicitly asks
for the lagom target, we have all our ducks in a row.
|
|
Direct build commands to the SuperBuild's binary directory, and
image/run commands to the Serenity binary directory.
As a side benefit, make the lagom target only build Lagom instead of the
entire OS alongside Lagom.
|
|
This allows us to step through the initial boot instructions.
|
|
This enables maintaining gcc and clang builds side-by-side.
|
|
|
|
|
|
The gcc patch might not be completely correct, but at least the
toolchain completes building.
|
|
This environment variable is already widely used across our build
scripts and tooling, so serenity.sh should respect it as well.
It still uses i686 as the fallback.
|
|
This command copies the project's source tree to
/home/anon/Source/serenity in the built disk image.
This will be useful for working on serenity inside serenity :^)
|
|
|
|
|
|
This is required as our CMake config defaults to i686 if not overriden
manually via the SERENITY_ARCH argument.
|
|
|
|
|
|
|
|
|
|
This was brought up as something that would be useful by
`RealKC` on the discord, and I happened to agree that it
would be useful. Especially given the abundance of Toolchain
changes recently.
|
|
This is more portable.
|
|
|
|
This change fixes two bugs:
1) If you run `serenity.sh` outside of your serenity git clone, the
`get_top_dir()` function won't be able to auto detect the serenity
root dir and we'll error out. By allowing the script to use an
existing $SERENITY_ROOT vlaue if it exists, we can solve
this problem.
2) If tried to run a command which ends up calling `build_toolchain()`
and you were outside of the root of the project, it should just
fail. Fix this by utilizing `$SERENITY_ROOT`.
|
|
I have this symlinked into ~/bin, when looking at the help/usage
it would previously print the fully qualified path to the script
making the help very difficult to read.
|
|
|
|
|
|
|
|
Running the tests will be moved to a separate test command which can
then leverage the availability of different targets and run either unit
tests on the host or the image in QEMU in self-test mode. :^)
|
|
- Only call ensure_toolchain for non-lagom targets
- Use host addr2line, we can't expect the i686 toolchain's addr2line to
support the host's binary executable format
- Don't export SERENITY_ARCH and TOOLCHAIN_DIR, don't need them anymore
|
|
|
|
This uses tmux for a split screen setup, which makes it easy do debug
the kernel while viewing the QEMU output in the same terminal.
|
|
This script automatically manages the toolchain and cmake/ninja folders
making it easier to manage the different target architectures.
|
