summaryrefslogtreecommitdiff
path: root/Toolchain/CMake
AgeCommit message (Collapse)Author
2022-07-13Meta+Ports: Automatically generate a meson cross file that we can useTim Schumacher
2022-06-29Toolchain: Update Platform files to match those in upstream cmakeAndrew Kaster
Serenity support was merged into the CMake master branch for the 3.25.0 milestone (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6837) Remove some settings that are now redundant from the Toolchain files.
2022-05-02Toolchain: Enable LLVM Profile instrumentationAndrew Kaster
Add a patch to let llvm's InstrProfiling modules know serenity supports all the Unix-y features required to make -fprofile-instr-generate and -fcoverage-mapping work properly on target.
2022-04-25Toolchain: Explicitly install llvm-config and FileCheckAndrew Kaster
Also disable the "toolchain only build" to ensure we install llvm headers for when we want to build host tools that link against llvm.
2022-04-23Toolchain+Ports: Update LLVM to 14.0.1Daniel Bertalan
Besides a version bump, the following changes have been made to our toolchain infrastructure: - LLVM/Clang is now built with -march=native if the host compiler supports it. An exception to this is CI, as the toolchain cache is shared among many different machines there. - The LLVM tarball is not re-extracted if the hash of the applied patches doesn't differ. - The patches have been split up into atomic chunks. - Port-specific patches have been integrated into the main patches, which will aid in the work towards self-hosting. - <sysroot>/usr/local/lib is now appended to the linker's search path by default. - --pack-dyn-relocs=relr is appended to the linker command line by default, meaning ports take advantage of RELR relocations without any patches or additional compiler flags. The formatting of LLVM port's package.sh has been bothering me, so I also indented the arguments to the CMake invocation.
2022-02-19Toolchain: Set CMAKE_NM for Clang and GNU toolchain filesAndrew Kaster
Make sure that we set CMAKE_NM, it's possible that some version of CMake could choose a host nm binary instead of the ones we just built. It's unlikely that host nm will understand our .dyn.relr segments unless it's from binutils 2.38 or higher, so it might complain.
2022-01-12Toolchain: Enable std::filesystem support in libc++Daniel Bertalan
Now that the last missing function (`fchmodat(2)`) has been added to LibC, libc++ compiles successfully with std::filesystem support enabled.
2022-01-10Toolchain: Don't use GNU objcopy in the LLVM toolchainDaniel Bertalan
Our build of LLVM's objcopy now supports the single missing feature (--update-section) that previously forced us to use the one from GNU Binutils. This means that there is no reason anymore to build Binutils alongside LLVM's tools.
2022-01-04Toolchain: Add support for Clang on MacOSJean-Paul Balabanian
This commit adds Darwin as a possible host for building the toolchain with Clang.
2022-01-03Toolchain: Add CMAKE_PLATFORM_USES_PATH_WHEN_NO_SONAME to PlatformAndrew Kaster
This property tells CMake that if a library is missing a SONAME field, the link editor(s) we use will insert the full path to the library into the binary. This is the behaivor of GNU ld compatible linkers, so let's avoid that possiblity by telling CMake that it really doesn't want to let the linker embed the full path to the lib. This is especially important when cross-compiling things for ports and such, as the full path to the lib will have absolutely nothing to do with the runtime path
2022-01-03Toolchain: Use Platform/SerenityOS.cmake in LLVM toolchain buildAndrew Kaster
By setting CMAKE_MODULE_PATH in the LLVM initial cache scripts, we can make the "SerenityOS" CMAKE_SYSTEM_NAME usable in the builds of compiler-rt, libunwind, libcxxabi and libcxx. This simplifies some toolchain patches and brings the cross-compiler patches closer to the Port's patches, and closer to something upstreamable.
2021-11-28Toolchain/Clang: Fix CMake using utilities from the LLVM portDaniel Bertalan
If we have the LLVM port installed, CMake might pick up some of the tools installed as part of it (`llvm-ar`, `llvm-strip`, etc.) instead of the ones belonging to the host toolchain. These, of course, can't be run on the host platform, so builds would eventually fail. This made it impossible to rebuild the LLVM toolchain. We now set these variables explicitly when compiling the LLVM runtime libraries in order to avoid this issue.
2021-11-14Toolchain: Enable clang-tools-extra for LLVMAndrew Kaster
If we want to use clang-tidy on the codebase, we'll need to build clang-tidy from an LLVM that has been patched and built with Serenity cross-compilation support.
2021-11-07CMake: Assume working compiler instead of using static linkingTim Schumacher
We were previously using TRY_COMPILE_TARGET_TYPE to bypass the compiler check at the beginning of the CMake build, since we don't have LibC available and therefore can't link at that point. However, this breaks a lot of assumptions in try_compile when it comes to library checks. While this was the main idea behind our usage of the flag, it also has some really nasty side effects when software wants to find out what library a symbol is in. Instead, just manually tell CMake that our compiler works as intended and keep the target type setting at its default.
2021-10-31Toolchain: Use dynamic paths for cross-compile CMake toolchainsTim Schumacher
`CMAKE_INSTALL_PREFIX` is supposed to be the in-system installation path. The sysroot path on the host doesn't belong there, since other applications will duplicate that path when applying their respective sysroot.
2021-10-17Toolchain+Meta: Update LLVM version to 13.0.0Daniel Bertalan
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.
2021-09-15Meta+Toolchain: Rename CMAKE_CXXFILT to SERENITY_CXXFILTAndrew Kaster
The "CMAKE_<foo>" variable namespace is reserved, and CXXFILT is not currently a variable known to upstream CMake.
2021-09-15Meta: Switch to a SuperBuild that splits host and target buildsAndrew Kaster
Replace the old logic where we would start with a host build, and swap all the CMake compiler and target variables underneath it to trick CMake into building for Serenity after we configured and built the Lagom code generators. The SuperBuild creates two ExternalProjects, one for Lagom and one for Serenity. The Serenity project depends on the install stage for the Lagom build. The SuperBuild also generates a CMakeToolchain file for the Serenity build to use that replaces the old toolchain file that was only used for Ports. To ensure that code generators are rebuilt when core libraries such as AK and LibCore are modified, developers will need to direct their manual `ninja` invocations to the SuperBuild's binary directory instead of the Serenity binary directory. This commit includes warning coalescing and option style cleanup for the affected CMakeLists in the Kernel, top level, and runtime support libraries. A large part of the cleanup is replacing USE_CLANG_TOOLCHAIN with the proper CMAKE_CXX_COMPILER_ID variable, which will no longer be confused by a host clang compiler.
2021-06-03Toolchain: Use gcc's arHediadyoin1
the vanilla versions might not handle all things, that gcc can do; For example is lto not really supported by the vanilla versions source: https://gcc.gnu.org/wiki/LinkTimeOptimizationFAQ
2021-06-02Toolchain: Set CMAKE_AR to the right executableOleg Kosenkov
2021-04-25Toolchain: Update cmake platform definitionGunnar Beutner
This fixes building cmake and other ports which use cmake to detect whether we have -ldl.
2021-04-20Everywhere: Replace SERENITY_ROOT with SERENITY_SOURCE_DIRPanagiotis Vasilopoulos
2021-04-18Toolchain: Enable -fexceptions and build a separate libstdc++ for the kernelGunnar Beutner
This enables building usermode programs with exception handling. It also builds a libstdc++ without exception support for the kernel. This is necessary because the libstdc++ that gets built is different when exceptions are enabled. Using the same library binary would require extensive stubs for exception-related functionality in the kernel.
2021-04-17Toolchain: Fix cmake definition for CMAKE_DL_LIBSGunnar Beutner
We don't have libdl (yet) so update the CMAKE_DL_LIBRARY definition to match.
2021-04-16Ports: Make sure ports are installed into /usr/localGunnar Beutner
2021-04-16Toolchain+Ports: Move the CMake toolchain file into a subdirectoryGunnar Beutner
2021-04-16Toolchain: Add platform definition for CMakeGunnar Beutner
This also ensures that pkg-config finds packages in /usr/local and changes the install prefix to /usr/local.