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

200 lines
8.5 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)
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()
function(serenity_install_sources target_name)
file(GLOB_RECURSE sources RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} "*.h" "*.cpp")
foreach(source ${sources})
get_filename_component(subdirectory ${source} 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 ${source} DESTINATION usr/src/serenity/${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()
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})
endforeach()
endif()
endfunction()
function(serenity_lib target_name fs_name)
serenity_install_headers(${target_name})
Libraries: Move to Userland/Libraries/
2021-01-12 11:17:30 +00:00
serenity_install_sources("Userland/Libraries/${target_name}")
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)
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_shared_lib target_name fs_name)
serenity_install_headers(${target_name})
Libraries: Move to Userland/Libraries/
2021-01-12 11:17:30 +00:00
serenity_install_sources("Userland/Libraries/${target_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
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)
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("")
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
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: Add Clang support to the CMake build scripts
2021-07-13 14:43:45 +00:00
if (USE_CLANG_TOOLCHAIN)
target_link_libraries(${target_name} clang_rt.builtins-${SERENITY_CLANG_ARCH})
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)
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)
LibJS+LibTest: Move out the test-js test runner into LibTest
2021-05-18 14:15:12 +00:00
cmake_parse_arguments(SERENITY_TEST "MAIN_ALREADY_DEFINED" "CUSTOM_MAIN" "LIBS" ${ARGN})
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)
cmake_parse_arguments(SERENITY_TEST "" "CUSTOM_MAIN" "LIBS" ${ARGN})
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)
cmake_parse_arguments(SERENITY_APP "" "ICON" "" ${ARGN})
serenity_bin("${target_name}")
set(small_icon "${CMAKE_SOURCE_DIR}/Base/res/icons/16x16/${SERENITY_APP_ICON}.png")
set(medium_icon "${CMAKE_SOURCE_DIR}/Base/res/icons/32x32/${SERENITY_APP_ICON}.png")
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(compile_gml source output string_name)
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${source})
add_custom_command(
OUTPUT ${output}
COMMAND ${write_if_different} ${output} ${CMAKE_SOURCE_DIR}/Meta/text-to-cpp-string.sh ${string_name} ${source}
VERBATIM
DEPENDS ${CMAKE_SOURCE_DIR}/Meta/text-to-cpp-string.sh
MAIN_DEPENDENCY ${source}
)
get_filename_component(output_name ${output} NAME)
add_custom_target(generate_${output_name} DEPENDS ${output})
endfunction()
function(compile_ipc source output)
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${source})
add_custom_command(
OUTPUT ${output}
Services: Move to Userland/Services/
2021-01-12 11:23:01 +00:00
COMMAND ${write_if_different} ${output} ${CMAKE_BINARY_DIR}/Userland/DevTools/IPCCompiler/IPCCompiler ${source}
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
VERBATIM
DEPENDS IPCCompiler
MAIN_DEPENDENCY ${source}
)
get_filename_component(output_name ${output} NAME)
add_custom_target(generate_${output_name} DEPENDS ${output})
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}"
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
COMMAND "${CMAKE_SOURCE_DIR}/Meta/generate-embedded-resource-assembly.sh" "${asm_file}" "${section}" "${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
DEPENDS "${input_file}" "${CMAKE_SOURCE_DIR}/Meta/generate-embedded-resource-assembly.sh"
COMMENT "Generating ${asm_file}"
)
target_sources("${target}" PRIVATE "${asm_file}")
endfunction()
LibVT: Implement new ANSI escape sequence parser This commit replaces the former, hand-written parser with a new one that can be generated automatically according to a state change diagram. The new `EscapeSequenceParser` class provides a more ergonomic interface to dealing with escape sequences. This interface has been inspired by Alacritty's [vte library](https://github.com/alacritty/vte/). I tried to avoid changing the application logic inside the `Terminal` class. While this code has not been thoroughly tested, I can't find regressions in the basic command line utilities or `vttest`. `Terminal` now displays nicer debug messages when it encounters an unknown escape sequence. Defensive programming and bounds checks have been added where we access parameters, and as a result, we can now endure 4-5 seconds of `cat /dev/urandom`. :D We generate EscapeSequenceStateMachine.h when building the in-kernel LibVT, and we assume that the file is already in place when the userland library is being built. This will probably cause problems later on, but I can't find a way to do it nicely.
2021-05-08 18:37:43 +00:00
function(generate_state_machine source header)
Meta: Make generate_state_machine() generate a proper target And use GENERATED_SOURCES (or add_dependencies) to make LibVT depend on that target. Fixes a FIXME.
2021-05-20 09:44:23 +00:00
get_filename_component(header_name ${header} NAME)
set(target_name "generate_${header_name}")
# Note: This function is called twice with the same header, once in the kernel
# and once in Userland/LibVT, this check makes sure that only one target
# is generated for that header.
if(NOT TARGET ${target_name})
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${source})
StateMachineGenerator: Put output into the CMake build directory Don't pollute the source directory with generated code.
2021-05-20 16:10:59 +00:00
set(output ${CMAKE_CURRENT_BINARY_DIR}/${header})
Meta: Make generate_state_machine() generate a proper target And use GENERATED_SOURCES (or add_dependencies) to make LibVT depend on that target. Fixes a FIXME.
2021-05-20 09:44:23 +00:00
add_custom_command(
OUTPUT ${output}
COMMAND ${write_if_different} ${output} ${CMAKE_BINARY_DIR}/Userland/DevTools/StateMachineGenerator/StateMachineGenerator ${source}
VERBATIM
DEPENDS StateMachineGenerator
MAIN_DEPENDENCY ${source}
)
add_custom_target(${target_name} DEPENDS ${output})
endif()
LibVT: Implement new ANSI escape sequence parser This commit replaces the former, hand-written parser with a new one that can be generated automatically according to a state change diagram. The new `EscapeSequenceParser` class provides a more ergonomic interface to dealing with escape sequences. This interface has been inspired by Alacritty's [vte library](https://github.com/alacritty/vte/). I tried to avoid changing the application logic inside the `Terminal` class. While this code has not been thoroughly tested, I can't find regressions in the basic command line utilities or `vttest`. `Terminal` now displays nicer debug messages when it encounters an unknown escape sequence. Defensive programming and bounds checks have been added where we access parameters, and as a result, we can now endure 4-5 seconds of `cat /dev/urandom`. :D We generate EscapeSequenceStateMachine.h when building the in-kernel LibVT, and we assume that the file is already in place when the userland library is being built. This will probably cause problems later on, but I can't find a way to do it nicely.
2021-05-08 18:37:43 +00:00
endfunction()
Reference in a new issue Copy permalink