beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 23:50:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Meta/CMake/utils.cmake

161 lines
7.2 KiB
CMake
Raw Normal View History

Meta: Move components CMake helpers to their own file It's hard to follow how all the functions in the utils.cmake helper file flow together, so let's move the pieces that are related to each other into specialized helpers. First up: all the ConfigureComponents related properties and functions.
2021-08-07 23:11:02 +00:00
include(${CMAKE_CURRENT_LIST_DIR}/serenity_components.cmake)
Meta: Move code generator helpers to their own CMake helper file compile_gml, compile_ipc, and generate_state_machine all use host tools to generate sources for the target build. As part of trying to organize host tools into a common area, let's move these helper rules to a common file that we can add other host tools to later. And, keep the host tool helpers separate from the CMake target helpers for apps and libraries.
2021-08-07 23:37:09 +00:00
include(${CMAKE_CURRENT_LIST_DIR}/code_generators.cmake)
Meta: Move components CMake helpers to their own file It's hard to follow how all the functions in the utils.cmake helper file flow together, so let's move the pieces that are related to each other into specialized helpers. First up: all the ConfigureComponents related properties and functions.
2021-08-07 23:11:02 +00:00
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
function(serenity_install_headers target_name)
file(GLOB_RECURSE headers RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} "*.h")
foreach(header ${headers})
get_filename_component(subdirectory ${header} DIRECTORY)
Meta: Add support for declaring components 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.
2021-06-15 13:07:25 +00:00
install(FILES ${header} DESTINATION usr/include/${target_name}/${subdirectory} OPTIONAL)
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
endforeach()
endfunction()
CMake: Simplify serenity_install_sources by inferring installation path The serenity_install_sources function now infers the path under `/usr/src/serenity` in which to install the source files according to the relative path of the source files in the repository. For example `Userland/Libraries/LibGUI/Widget.h` gets installed at `/usr/src/serenity/Userland/Libraries/LibGUI/Widget.h`. This fixes cases where the source files of libraries are not under `Userland/Libraries` (for example LibShell & LibLanguageServer).
2021-11-26 13:53:46 +00:00
function(serenity_install_sources)
string(LENGTH ${SerenityOS_SOURCE_DIR} root_source_dir_length)
string(SUBSTRING ${CMAKE_CURRENT_SOURCE_DIR} ${root_source_dir_length} -1 current_source_dir_relative)
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
file(GLOB_RECURSE sources RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} "*.h" "*.cpp")
foreach(source ${sources})
get_filename_component(subdirectory ${source} DIRECTORY)
CMake: Simplify serenity_install_sources by inferring installation path The serenity_install_sources function now infers the path under `/usr/src/serenity` in which to install the source files according to the relative path of the source files in the repository. For example `Userland/Libraries/LibGUI/Widget.h` gets installed at `/usr/src/serenity/Userland/Libraries/LibGUI/Widget.h`. This fixes cases where the source files of libraries are not under `Userland/Libraries` (for example LibShell & LibLanguageServer).
2021-11-26 13:53:46 +00:00
install(FILES ${source} DESTINATION usr/src/serenity/${current_source_dir_relative}/${subdirectory} OPTIONAL)
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
endforeach()
endfunction()
function(serenity_generated_sources target_name)
if(DEFINED GENERATED_SOURCES)
set_source_files_properties(${GENERATED_SOURCES} PROPERTIES GENERATED 1)
foreach(generated ${GENERATED_SOURCES})
get_filename_component(generated_name ${generated} NAME)
add_dependencies(${target_name} generate_${generated_name})
CMake: Add custom target to build only the generated sources This is needed so all headers and files exist on disk, so that the sonar cloud analyzer can find them when executing the compilation commands contained in compile_commands.json, without actually building. Co-authored-by: Andrew Kaster <akaster@serenityos.org>
2021-08-30 02:27:50 +00:00
add_dependencies(all_generated generate_${generated_name})
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
endforeach()
endif()
endfunction()
function(serenity_lib target_name fs_name)
serenity_install_headers(${target_name})
CMake: Simplify serenity_install_sources by inferring installation path The serenity_install_sources function now infers the path under `/usr/src/serenity` in which to install the source files according to the relative path of the source files in the repository. For example `Userland/Libraries/LibGUI/Widget.h` gets installed at `/usr/src/serenity/Userland/Libraries/LibGUI/Widget.h`. This fixes cases where the source files of libraries are not under `Userland/Libraries` (for example LibShell & LibLanguageServer).
2021-11-26 13:53:46 +00:00
serenity_install_sources()
Toolchain+LibC: Fix usage of crt files We now configure the gcc spec files to use a different crt files for static & PIE binaries. This relieves us from the need to explicitly specify the desired crt0 file in cmake scripts.
2020-12-20 20:32:10 +00:00
add_library(${target_name} SHARED ${SOURCES} ${GENERATED_SOURCES})
Meta: Add support for declaring components 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.
2021-06-15 13:07:25 +00:00
set_target_properties(${target_name} PROPERTIES EXCLUDE_FROM_ALL TRUE)
CMake: Build serenity_lib libraries with a custom SONAME This allows libraries and binaries to explicitly link against `<library>.so.serenity`, which avoids some confusion if there are other libraries with the same name, such as OpenSSL's `libcrypto`.
2021-10-31 16:38:01 +00:00
set_target_properties(${target_name} PROPERTIES VERSION "serenity")
Meta: Add support for declaring components 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.
2021-06-15 13:07:25 +00:00
install(TARGETS ${target_name} DESTINATION usr/lib OPTIONAL)
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
set_target_properties(${target_name} PROPERTIES OUTPUT_NAME ${fs_name})
serenity_generated_sources(${target_name})
endfunction()
function(serenity_libc target_name fs_name)
serenity_install_headers("")
CMake: Simplify serenity_install_sources by inferring installation path The serenity_install_sources function now infers the path under `/usr/src/serenity` in which to install the source files according to the relative path of the source files in the repository. For example `Userland/Libraries/LibGUI/Widget.h` gets installed at `/usr/src/serenity/Userland/Libraries/LibGUI/Widget.h`. This fixes cases where the source files of libraries are not under `Userland/Libraries` (for example LibShell & LibLanguageServer).
2021-11-26 13:53:46 +00:00
serenity_install_sources()
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -nostdlib -fpic")
add_library(${target_name} SHARED ${SOURCES})
install(TARGETS ${target_name} DESTINATION usr/lib)
set_target_properties(${target_name} PROPERTIES OUTPUT_NAME ${fs_name})
Meta: Resolve cyclic dependency between LibPthread and libc++ libc++ uses a Pthread condition variable in one of its initialization functions. This means that Pthread forwarding has to be set up in LibC before libc++ can be initialized. Also, because LibPthread is written in C++, (at least some) parts of the C++ standard library have to be linked against it. This is a circular dependency, which means that the order in which these two libraries' initialization functions are called is undefined. In some cases, libc++ will come first, which will then trigger an assert due to the missing Pthread forwarding. This issue isn't necessarily unique to LibPthread, as all libraries that libc++ depends on exhibit the same circular dependency issue. The reason why this issue didn't affect the GNU toolchain is that libstdc++ is always linked statically. If we were to change that, I believe that we would run into the same issue.
2021-11-08 18:06:02 +00:00
# Avoid creating a dependency cycle between system libraries and the C++ standard library. This is necessary
# to ensure that initialization functions will be called in the right order (libc++ must come after LibPthread).
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
target_link_options(${target_name} PRIVATE -static-libstdc++)
elseif (CMAKE_CXX_COMPILER_ID MATCHES "Clang$")
Toolchain+Meta: Update LLVM version to 13.0.0 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-08-13 10:11:12 +00:00
target_link_libraries(${target_name} clang_rt.builtins)
Meta: Resolve cyclic dependency between LibPthread and libc++ libc++ uses a Pthread condition variable in one of its initialization functions. This means that Pthread forwarding has to be set up in LibC before libc++ can be initialized. Also, because LibPthread is written in C++, (at least some) parts of the C++ standard library have to be linked against it. This is a circular dependency, which means that the order in which these two libraries' initialization functions are called is undefined. In some cases, libc++ will come first, which will then trigger an assert due to the missing Pthread forwarding. This issue isn't necessarily unique to LibPthread, as all libraries that libc++ depends on exhibit the same circular dependency issue. The reason why this issue didn't affect the GNU toolchain is that libstdc++ is always linked statically. If we were to change that, I believe that we would run into the same issue.
2021-11-08 18:06:02 +00:00
# FIXME: Implement -static-libstdc++ in the next toolchain update.
target_link_options(${target_name} PRIVATE -nostdlib++ -Wl,-Bstatic -lc++ -Wl,-Bdynamic)
target_link_options(${target_name} PRIVATE -Wl,--no-dependent-libraries)
Meta: Add Clang support to the CMake build scripts
2021-07-13 14:43:45 +00:00
endif()
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
target_link_directories(LibC PUBLIC ${CMAKE_CURRENT_BINARY_DIR})
serenity_generated_sources(${target_name})
endfunction()
function(serenity_libc_static target_name fs_name)
serenity_install_headers("")
Libraries: Move to Userland/Libraries/
2021-01-12 11:17:30 +00:00
serenity_install_sources("Userland/Libraries/LibC")
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
add_library(${target_name} ${SOURCES})
Meta: Add support for declaring components 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.
2021-06-15 13:07:25 +00:00
set_target_properties(${target_name} PROPERTIES EXCLUDE_FROM_ALL TRUE)
install(TARGETS ${target_name} ARCHIVE DESTINATION usr/lib OPTIONAL)
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
set_target_properties(${target_name} PROPERTIES OUTPUT_NAME ${fs_name})
target_link_directories(${target_name} PUBLIC ${CMAKE_CURRENT_BINARY_DIR})
serenity_generated_sources(${target_name})
endfunction()
function(serenity_bin target_name)
CMake: Also install the source files of userland programs Previously, we only copied the source files of libraries to `/usr/src/serenity`. We now also install the source files of userland programs.
2021-11-26 13:53:46 +00:00
serenity_install_sources()
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
add_executable(${target_name} ${SOURCES})
Meta: Add support for declaring components 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.
2021-06-15 13:07:25 +00:00
set_target_properties(${target_name} PROPERTIES EXCLUDE_FROM_ALL TRUE)
install(TARGETS ${target_name} RUNTIME DESTINATION bin OPTIONAL)
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
serenity_generated_sources(${target_name})
endfunction()
AK+Userland: Move AK/TestSuite.h into LibTest and rework Tests' CMake As many macros as possible are moved to Macros.h, while the macros to create a test case are moved to TestCase.h. TestCase is now the only user-facing header for creating a test case. TestSuite and its helpers have moved into a .cpp file. Instead of requiring a TEST_MAIN macro to be instantiated into the test file, a TestMain.cpp file is provided instead that will be linked against each test. This has the side effect that, if we wanted to have test cases split across multiple files, it's as simple as adding them all to the same executable. The test main should be portable to kernel mode as well, so if there's a set of tests that should be run in self-test mode in kernel space, we can accomodate that. A new serenity_test CMake function streamlines adding a new test with arguments for the test source file, subdirectory under /usr/Tests to install the test application and an optional list of libraries to link against the test application. To accomodate future test where the provided TestMain.cpp is not suitable (e.g. test-js), a CUSTOM_MAIN parameter can be passed to the function to not link against the boilerplate main function.
2021-04-25 05:53:23 +00:00
function(serenity_test test_src sub_dir)
Meta: Prefer SerenityOS_SOURCE_DIR to CMAKE_SOURCE_DIR By using SerenityOS_SOURCE_DIR we can make custom targets and commands agnostic to the actual location of the root CMakeLists directory. All we care about is the root of the SerenityOS project.
2021-08-08 00:32:49 +00:00
cmake_parse_arguments(PARSE_ARGV 2 SERENITY_TEST "MAIN_ALREADY_DEFINED" "CUSTOM_MAIN" "LIBS")
AK+Userland: Move AK/TestSuite.h into LibTest and rework Tests' CMake As many macros as possible are moved to Macros.h, while the macros to create a test case are moved to TestCase.h. TestCase is now the only user-facing header for creating a test case. TestSuite and its helpers have moved into a .cpp file. Instead of requiring a TEST_MAIN macro to be instantiated into the test file, a TestMain.cpp file is provided instead that will be linked against each test. This has the side effect that, if we wanted to have test cases split across multiple files, it's as simple as adding them all to the same executable. The test main should be portable to kernel mode as well, so if there's a set of tests that should be run in self-test mode in kernel space, we can accomodate that. A new serenity_test CMake function streamlines adding a new test with arguments for the test source file, subdirectory under /usr/Tests to install the test application and an optional list of libraries to link against the test application. To accomodate future test where the provided TestMain.cpp is not suitable (e.g. test-js), a CUSTOM_MAIN parameter can be passed to the function to not link against the boilerplate main function.
2021-04-25 05:53:23 +00:00
set(TEST_SOURCES ${test_src})
LibJS+LibTest: Move out the test-js test runner into LibTest
2021-05-18 14:15:12 +00:00
if ("${SERENITY_TEST_CUSTOM_MAIN}" STREQUAL "")
Meta/LibTest: Build object libraries for test main files By using the power of object libraries and $<TARGET_OBJECTS> we can make sure to only build TestMain.cpp and JavaScriptTestRunnerMain.cpp once. Previously we built these cpp files into object files once for every single test executable. This change reduces the number of total compile jobs in a Serenity target build by around 100.
2021-07-27 06:19:08 +00:00
set(SERENITY_TEST_CUSTOM_MAIN "$<TARGET_OBJECTS:LibTestMain>")
LibJS+LibTest: Move out the test-js test runner into LibTest
2021-05-18 14:15:12 +00:00
endif()
if (NOT ${SERENITY_TEST_MAIN_ALREADY_DEFINED})
list(PREPEND TEST_SOURCES "${SERENITY_TEST_CUSTOM_MAIN}")
AK+Userland: Move AK/TestSuite.h into LibTest and rework Tests' CMake As many macros as possible are moved to Macros.h, while the macros to create a test case are moved to TestCase.h. TestCase is now the only user-facing header for creating a test case. TestSuite and its helpers have moved into a .cpp file. Instead of requiring a TEST_MAIN macro to be instantiated into the test file, a TestMain.cpp file is provided instead that will be linked against each test. This has the side effect that, if we wanted to have test cases split across multiple files, it's as simple as adding them all to the same executable. The test main should be portable to kernel mode as well, so if there's a set of tests that should be run in self-test mode in kernel space, we can accomodate that. A new serenity_test CMake function streamlines adding a new test with arguments for the test source file, subdirectory under /usr/Tests to install the test application and an optional list of libraries to link against the test application. To accomodate future test where the provided TestMain.cpp is not suitable (e.g. test-js), a CUSTOM_MAIN parameter can be passed to the function to not link against the boilerplate main function.
2021-04-25 05:53:23 +00:00
endif()
get_filename_component(test_name ${test_src} NAME_WE)
add_executable(${test_name} ${TEST_SOURCES})
Meta: Add support for declaring components 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.
2021-06-15 13:07:25 +00:00
add_dependencies(ComponentTests ${test_name})
set_target_properties(${test_name} PROPERTIES EXCLUDE_FROM_ALL TRUE)
AK+Userland: Move AK/TestSuite.h into LibTest and rework Tests' CMake As many macros as possible are moved to Macros.h, while the macros to create a test case are moved to TestCase.h. TestCase is now the only user-facing header for creating a test case. TestSuite and its helpers have moved into a .cpp file. Instead of requiring a TEST_MAIN macro to be instantiated into the test file, a TestMain.cpp file is provided instead that will be linked against each test. This has the side effect that, if we wanted to have test cases split across multiple files, it's as simple as adding them all to the same executable. The test main should be portable to kernel mode as well, so if there's a set of tests that should be run in self-test mode in kernel space, we can accomodate that. A new serenity_test CMake function streamlines adding a new test with arguments for the test source file, subdirectory under /usr/Tests to install the test application and an optional list of libraries to link against the test application. To accomodate future test where the provided TestMain.cpp is not suitable (e.g. test-js), a CUSTOM_MAIN parameter can be passed to the function to not link against the boilerplate main function.
2021-04-25 05:53:23 +00:00
target_link_libraries(${test_name} LibTest LibCore)
foreach(lib ${SERENITY_TEST_LIBS})
target_link_libraries(${test_name} ${lib})
endforeach()
Meta: Add support for declaring components 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.
2021-06-15 13:07:25 +00:00
install(TARGETS ${test_name} RUNTIME DESTINATION usr/Tests/${sub_dir} OPTIONAL)
AK+Userland: Move AK/TestSuite.h into LibTest and rework Tests' CMake As many macros as possible are moved to Macros.h, while the macros to create a test case are moved to TestCase.h. TestCase is now the only user-facing header for creating a test case. TestSuite and its helpers have moved into a .cpp file. Instead of requiring a TEST_MAIN macro to be instantiated into the test file, a TestMain.cpp file is provided instead that will be linked against each test. This has the side effect that, if we wanted to have test cases split across multiple files, it's as simple as adding them all to the same executable. The test main should be portable to kernel mode as well, so if there's a set of tests that should be run in self-test mode in kernel space, we can accomodate that. A new serenity_test CMake function streamlines adding a new test with arguments for the test source file, subdirectory under /usr/Tests to install the test application and an optional list of libraries to link against the test application. To accomodate future test where the provided TestMain.cpp is not suitable (e.g. test-js), a CUSTOM_MAIN parameter can be passed to the function to not link against the boilerplate main function.
2021-04-25 05:53:23 +00:00
endfunction()
LibJS+LibTest: Move out the test-js test runner into LibTest
2021-05-18 14:15:12 +00:00
function(serenity_testjs_test test_src sub_dir)
Meta: Prefer SerenityOS_SOURCE_DIR to CMAKE_SOURCE_DIR By using SerenityOS_SOURCE_DIR we can make custom targets and commands agnostic to the actual location of the root CMakeLists directory. All we care about is the root of the SerenityOS project.
2021-08-08 00:32:49 +00:00
cmake_parse_arguments(PARSE_ARGV 2 SERENITY_TEST "" "CUSTOM_MAIN" "LIBS")
LibJS+LibTest: Move out the test-js test runner into LibTest
2021-05-18 14:15:12 +00:00
if ("${SERENITY_TEST_CUSTOM_MAIN}" STREQUAL "")
Meta/LibTest: Build object libraries for test main files By using the power of object libraries and $<TARGET_OBJECTS> we can make sure to only build TestMain.cpp and JavaScriptTestRunnerMain.cpp once. Previously we built these cpp files into object files once for every single test executable. This change reduces the number of total compile jobs in a Serenity target build by around 100.
2021-07-27 06:19:08 +00:00
set(SERENITY_TEST_CUSTOM_MAIN "$<TARGET_OBJECTS:JavaScriptTestRunnerMain>")
LibJS+LibTest: Move out the test-js test runner into LibTest
2021-05-18 14:15:12 +00:00
endif()
list(APPEND SERENITY_TEST_LIBS LibJS LibCore)
serenity_test(${test_src} ${sub_dir}
CUSTOM_MAIN "${SERENITY_TEST_CUSTOM_MAIN}"
LIBS ${SERENITY_TEST_LIBS})
endfunction()
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
function(serenity_app target_name)
Meta: Prefer SerenityOS_SOURCE_DIR to CMAKE_SOURCE_DIR By using SerenityOS_SOURCE_DIR we can make custom targets and commands agnostic to the actual location of the root CMakeLists directory. All we care about is the root of the SerenityOS project.
2021-08-08 00:32:49 +00:00
cmake_parse_arguments(PARSE_ARGV 1 SERENITY_APP "" "ICON" "")
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
serenity_bin("${target_name}")
Meta: Prefer SerenityOS_SOURCE_DIR to CMAKE_SOURCE_DIR By using SerenityOS_SOURCE_DIR we can make custom targets and commands agnostic to the actual location of the root CMakeLists directory. All we care about is the root of the SerenityOS project.
2021-08-08 00:32:49 +00:00
set(small_icon "${SerenityOS_SOURCE_DIR}/Base/res/icons/16x16/${SERENITY_APP_ICON}.png")
set(medium_icon "${SerenityOS_SOURCE_DIR}/Base/res/icons/32x32/${SERENITY_APP_ICON}.png")
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
if (EXISTS "${small_icon}")
embed_resource("${target_name}" serenity_icon_s "${small_icon}")
CMake: Warn when a serenity app is missing small or medium icons
2021-01-01 23:44:39 +00:00
else()
CMake: Fix message levels for error conditions during configuration Make messages which should be fatal, actually fail the build. - FATAL is not a valid mode keyword. The full list is available in the docs: https://cmake.org/cmake/help/v3.19/command/message.html - SEND_ERROR doesn't immediately stop processing, FATAL_ERROR does. We should immediately stop if the Toolchain is not present. - The app icon size validation was just a WARNING that is easy to overlook. We should promote it to a FATAL_ERROR so that people will not overlook the issue when adding a new application. We can only make the small icon message FATAL_ERROR, as there is currently one violation of the medium app icon validation.
2021-05-13 11:15:35 +00:00
message(FATAL_ERROR "Missing small app icon: ${small_icon}")
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
endif()
CMake: Warn when a serenity app is missing small or medium icons
2021-01-01 23:44:39 +00:00
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
if (EXISTS "${medium_icon}")
embed_resource("${target_name}" serenity_icon_m "${medium_icon}")
CMake: Warn when a serenity app is missing small or medium icons
2021-01-01 23:44:39 +00:00
else()
Meta: Add allow-list for icon size detection in CMake The only icons we are currently warning about are designed and rendered as small icons intentionally, as their only use is in desktop applets, and thus are exempt to this rule. This reduces build spam back down to a minimum. I should have just done this in the first place, back in #4729
2021-04-20 04:26:09 +00:00
# These icons are designed small only for use in applets, and thus are exempt.
list(APPEND allowed_missing_medium_icons "audio-volume-high")
list(APPEND allowed_missing_medium_icons "edit-copy")
if (NOT ${SERENITY_APP_ICON} IN_LIST allowed_missing_medium_icons)
CMake: Make missing medium icon a FATAL_ERROR Now that all of the medium icons pass this check, we can make it FATAL_ERROR to stop any new violations from being checked in.
2021-05-13 21:33:12 +00:00
message(FATAL_ERROR "Missing medium app icon: ${medium_icon}")
Meta: Add allow-list for icon size detection in CMake The only icons we are currently warning about are designed and rendered as small icons intentionally, as their only use is in desktop applets, and thus are exempt to this rule. This reduces build spam back down to a minimum. I should have just done this in the first place, back in #4729
2021-04-20 04:26:09 +00:00
endif()
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
endif()
endfunction()
function(embed_resource target section file)
get_filename_component(asm_file "${file}" NAME)
set(asm_file "${CMAKE_CURRENT_BINARY_DIR}/${target}-${section}.s")
get_filename_component(input_file "${file}" ABSOLUTE)
Build: Expose symbols SECTION_start and SECTION_size for embedded resources. Resources embedded by the embed_resource() function will now also expose a SECTION_start and SECTION_size symbol so the embedded resource can be found by an application without having to parse its own ELF image which is not something applications can currently do from userspace.
2020-12-29 12:38:14 +00:00
file(SIZE "${input_file}" file_size)
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
add_custom_command(
OUTPUT "${asm_file}"
Meta: Prefer SerenityOS_SOURCE_DIR to CMAKE_SOURCE_DIR By using SerenityOS_SOURCE_DIR we can make custom targets and commands agnostic to the actual location of the root CMakeLists directory. All we care about is the root of the SerenityOS project.
2021-08-08 00:32:49 +00:00
COMMAND "${SerenityOS_SOURCE_DIR}/Meta/generate-embedded-resource-assembly.sh" "${asm_file}" "${section}" "${input_file}" "${file_size}"
DEPENDS "${input_file}" "${SerenityOS_SOURCE_DIR}/Meta/generate-embedded-resource-assembly.sh"
CMake: Decouple cmake utility functions from top-level CMakeLists.txt Problem: - These utility functions are only used in `AK`, but are being defined in the top-level. This clutters the top-level. Solution: - Move the utility functions to `Meta/CMake/utils.cmake` and include where needed. - Also, move `all_the_debug_macros.cmake` into `Meta/CMake` directory to consolidate the location of `*.cmake` script files.
2020-12-23 17:07:22 +00:00
COMMENT "Generating ${asm_file}"
)
target_sources("${target}" PRIVATE "${asm_file}")
endfunction()
Meta: Add helper CMake function to link directly against LibUnicodeData Rather than each CMakeLists.txt needing to import unicode_data.cmake and check if Unicode data generation is enabled, add a helper method to do this.
2021-12-29 17:55:23 +00:00
function(link_with_unicode_data target)
Meta: Redefine link_with_unicode_data to not include unicode_data.cmake This is to prevent an import cycle in a subsequent commit.
2021-12-30 13:47:38 +00:00
if (ENABLE_UNICODE_DATABASE_DOWNLOAD)
Meta: Add helper CMake function to link directly against LibUnicodeData Rather than each CMakeLists.txt needing to import unicode_data.cmake and check if Unicode data generation is enabled, add a helper method to do this.
2021-12-29 17:55:23 +00:00
target_link_libraries("${target}" LibUnicodeData)
endif()
endfunction()
Reference in a new issue Copy permalink