beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-25 17:10:23 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 7
ladybird/Meta/CMake/libweb_generators.cmake

237 lines
9.6 KiB
CMake
Raw Normal View History

Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
function (generate_css_implementation)
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
set(LIBWEB_INPUT_FOLDER "${CMAKE_CURRENT_SOURCE_DIR}")
Meta/CodeGenerators+LibWeb: Implement parsing CSS easing functions This only implements the parser bits, no functionality is implemented, and no properties are parsed because of this.
2023-07-05 22:59:36 +00:00
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
invoke_generator(
"Enums.cpp"
Lagom::GenerateCSSEnums
"${LIBWEB_INPUT_FOLDER}/CSS/Enums.json"
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
"CSS/Enums.h"
"CSS/Enums.cpp"
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
arguments -j "${LIBWEB_INPUT_FOLDER}/CSS/Enums.json"
)
LibWeb: Generate parsing code for CSS math functions
2023-07-13 13:59:31 +00:00
invoke_generator(
"MathFunctions.cpp"
Lagom::GenerateCSSMathFunctions
"${LIBWEB_INPUT_FOLDER}/CSS/MathFunctions.json"
"CSS/MathFunctions.h"
"CSS/MathFunctions.cpp"
arguments -j "${LIBWEB_INPUT_FOLDER}/CSS/MathFunctions.json"
)
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
invoke_generator(
"MediaFeatureID.cpp"
Lagom::GenerateCSSMediaFeatureID
"${LIBWEB_INPUT_FOLDER}/CSS/MediaFeatures.json"
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
"CSS/MediaFeatureID.h"
"CSS/MediaFeatureID.cpp"
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
arguments -j "${LIBWEB_INPUT_FOLDER}/CSS/MediaFeatures.json"
)
invoke_generator(
"PropertyID.cpp"
Lagom::GenerateCSSPropertyID
"${LIBWEB_INPUT_FOLDER}/CSS/Properties.json"
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
"CSS/PropertyID.h"
"CSS/PropertyID.cpp"
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
arguments -j "${LIBWEB_INPUT_FOLDER}/CSS/Properties.json"
)
LibWeb: Generate PseudoClass metadata The usual to/from-string functions, and metadata about whether the pseudo-class is a a function or not, and what type of parameter it takes.
2023-08-12 12:27:24 +00:00
invoke_generator(
"PseudoClass.cpp"
Lagom::GenerateCSSPseudoClass
"${LIBWEB_INPUT_FOLDER}/CSS/PseudoClasses.json"
"CSS/PseudoClass.h"
"CSS/PseudoClass.cpp"
arguments -j "${LIBWEB_INPUT_FOLDER}/CSS/PseudoClasses.json"
)
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
invoke_generator(
"TransformFunctions.cpp"
Lagom::GenerateCSSTransformFunctions
"${LIBWEB_INPUT_FOLDER}/CSS/TransformFunctions.json"
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
"CSS/TransformFunctions.h"
"CSS/TransformFunctions.cpp"
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
arguments -j "${LIBWEB_INPUT_FOLDER}/CSS/TransformFunctions.json"
)
invoke_generator(
LibWeb: Rename "identifier" and "ValueID" to "Keyword" where correct For a long time, we've used two terms, inconsistently: - "Identifier" is a spec term, but refers to a sequence of alphanumeric characters, which may or may not be a keyword. (Keywords are a subset of all identifiers.) - "ValueID" is entirely non-spec, and is directly called a "keyword" in the CSS specs. So to avoid confusion as much as possible, let's align with the spec terminology. I've attempted to change variable names as well, but obviously we use Keywords in a lot of places in LibWeb and so I may have missed some. One exception is that I've not renamed "valid-identifiers" in Properties.json... I'd like to combine that and the "valid-types" array together eventually, so there's no benefit to doing an extra rename now.
2024-08-14 13:06:03 +00:00
"Keyword.cpp"
Lagom::GenerateCSSKeyword
"${LIBWEB_INPUT_FOLDER}/CSS/Keywords.json"
"CSS/Keyword.h"
"CSS/Keyword.cpp"
arguments -j "${LIBWEB_INPUT_FOLDER}/CSS/Keywords.json"
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
)
Meta: Make embed_as_string_view.py produce Strings instead This is only used for CSS style sheets. One case wants it as a String, and the others don't care, but will in future also want to have the source as a String.
2024-08-22 11:42:12 +00:00
embed_as_string(
LibWeb: Use embed_as_string_view() for style sheet source generation
2023-08-23 20:17:49 +00:00
"DefaultStyleSheetSource.cpp"
"${LIBWEB_INPUT_FOLDER}/CSS/Default.css"
"CSS/DefaultStyleSheetSource.cpp"
"default_stylesheet_source"
NAMESPACE "Web::CSS"
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
)
Meta: Make embed_as_string_view.py produce Strings instead This is only used for CSS style sheets. One case wants it as a String, and the others don't care, but will in future also want to have the source as a String.
2024-08-22 11:42:12 +00:00
embed_as_string(
LibWeb: Use embed_as_string_view() for style sheet source generation
2023-08-23 20:17:49 +00:00
"QuirksModeStyleSheetSource.cpp"
"${LIBWEB_INPUT_FOLDER}/CSS/QuirksMode.css"
"CSS/QuirksModeStyleSheetSource.cpp"
"quirks_mode_stylesheet_source"
NAMESPACE "Web::CSS"
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
)
Meta: Make embed_as_string_view.py produce Strings instead This is only used for CSS style sheets. One case wants it as a String, and the others don't care, but will in future also want to have the source as a String.
2024-08-22 11:42:12 +00:00
embed_as_string(
LibWeb: Use embed_as_string_view() for style sheet source generation
2023-08-23 20:17:49 +00:00
"MathMLStyleSheetSource.cpp"
"${LIBWEB_INPUT_FOLDER}/MathML/Default.css"
"MathML/MathMLStyleSheetSource.cpp"
"mathml_stylesheet_source"
NAMESPACE "Web::CSS"
LibWeb: Add the default user agent MathML stylesheet We now apply MathML's default user agent style sheet along with other default styles. This sheet is not mixed in with the other styles in CSS/Default.css because it is a namespaced stylesheet and so has to be its own sheet.
2023-07-30 22:35:10 +00:00
)
Meta: Make embed_as_string_view.py produce Strings instead This is only used for CSS style sheets. One case wants it as a String, and the others don't care, but will in future also want to have the source as a String.
2024-08-22 11:42:12 +00:00
embed_as_string(
LibWeb: Include standard SVG user agent style sheet For now, part of this is commented-out. Our current implementations of `<mask>` and `<symbol>` rely on creating layout nodes, so they can't be `display: none`.
2023-09-23 13:23:47 +00:00
"SVGStyleSheetSource.cpp"
"${LIBWEB_INPUT_FOLDER}/SVG/Default.css"
"SVG/SVGStyleSheetSource.cpp"
"svg_stylesheet_source"
NAMESPACE "Web::CSS"
)
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
set(CSS_GENERATED_HEADERS
"CSS/Enums.h"
"CSS/Keyword.h"
"CSS/MathFunctions.h"
"CSS/MediaFeatureID.h"
"CSS/PropertyID.h"
"CSS/PseudoClass.h"
"CSS/TransformFunctions.h"
)
list(TRANSFORM CSS_GENERATED_HEADERS PREPEND "${CMAKE_CURRENT_BINARY_DIR}/")
Meta: Guard everything that installs headers with an option
2024-07-20 17:03:24 +00:00
if (ENABLE_INSTALL_HEADERS)
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
install(FILES ${CSS_GENERATED_HEADERS} DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/LibWeb/CSS")
Meta: Guard everything that installs headers with an option
2024-07-20 17:03:24 +00:00
endif()
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
list(APPEND LIBWEB_ALL_GENERATED_HEADERS ${CSS_GENERATED_HEADERS})
set(LIBWEB_ALL_GENERATED_HEADERS ${LIBWEB_ALL_GENERATED_HEADERS} PARENT_SCOPE)
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
endfunction()
Everywhere: Rename WrapperGenerator to BindingsGenerator This code generator no longer creates JS wrappers for platform objects in the old sense, instead they're JS objects internally themselves. Most of what we generate now are prototypes - which can be seen as bindings for the internal C++ methods implementing getters, setters, and methods - as well as object constructors, i.e. bindings for the internal create_with_global_object() method. Also tweak the naming of various CMake glue code existing around this.
2022-09-21 17:22:16 +00:00
function (generate_js_bindings target)
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
set(LIBWEB_INPUT_FOLDER "${CMAKE_CURRENT_SOURCE_DIR}")
Everywhere: Rename WrapperGenerator to BindingsGenerator This code generator no longer creates JS wrappers for platform objects in the old sense, instead they're JS objects internally themselves. Most of what we generate now are prototypes - which can be seen as bindings for the internal C++ methods implementing getters, setters, and methods - as well as object constructors, i.e. bindings for the internal create_with_global_object() method. Also tweak the naming of various CMake glue code existing around this.
2022-09-21 17:22:16 +00:00
function(libweb_js_bindings class)
LibWeb: Support generating IDL namespaces These are similar to prototypes and constructors in that they will now be lazily instantiated when they are first requested.
2023-03-15 14:02:04 +00:00
cmake_parse_arguments(PARSE_ARGV 1 LIBWEB_BINDINGS "NAMESPACE;ITERABLE;GLOBAL" "" "")
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
get_filename_component(basename "${class}" NAME)
LibWeb: Support generating IDL namespaces These are similar to prototypes and constructors in that they will now be lazily instantiated when they are first requested.
2023-03-15 14:02:04 +00:00
if (LIBWEB_BINDINGS_NAMESPACE)
set(BINDINGS_SOURCES
"Bindings/${basename}Namespace.h"
"Bindings/${basename}Namespace.cpp"
)
else()
set(BINDINGS_SOURCES
"Bindings/${basename}Constructor.h"
"Bindings/${basename}Constructor.cpp"
"Bindings/${basename}Prototype.h"
"Bindings/${basename}Prototype.cpp"
)
endif()
LibWeb: Add a mechanism to opt out of generating instance wrappers To enable incremental movement towards the removal of DOM object instance wrappers, this patch adds a NO_INSTANCE argument that can be passed to libweb_js_wrapper().
2022-08-06 12:51:11 +00:00
Everywhere: Rename WrapperGenerator to BindingsGenerator This code generator no longer creates JS wrappers for platform objects in the old sense, instead they're JS objects internally themselves. Most of what we generate now are prototypes - which can be seen as bindings for the internal C++ methods implementing getters, setters, and methods - as well as object constructors, i.e. bindings for the internal create_with_global_object() method. Also tweak the naming of various CMake glue code existing around this.
2022-09-21 17:22:16 +00:00
if(LIBWEB_BINDINGS_ITERABLE)
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
list(APPEND BINDINGS_SOURCES
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
"Bindings/${basename}IteratorPrototype.h"
"Bindings/${basename}IteratorPrototype.cpp"
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
)
endif()
LibWeb: Support interfaces with the [Global] extended attribute These are treated differently as the interface members are placed on the object itself, not its prototype. As the object itself still needs to be hand-written code, and we can no longer fully hide the gnarly generated code in the prototype object, these now generate a 'mixin' class that is added to the actual object through inheritance. https://webidl.spec.whatwg.org/#Global
2023-03-05 15:50:56 +00:00
if(LIBWEB_BINDINGS_GLOBAL)
list(APPEND BINDINGS_SOURCES
"Bindings/${basename}GlobalMixin.h"
"Bindings/${basename}GlobalMixin.cpp"
)
endif()
Meta+BindingsGenerator: Only invoke BindingsGenerator once per IDL file This reduces the number of tasks to schedule, and the complexity of the build system integrations for the BindingsGenerator. As a bonus, we move the "only write if changed" feature into the generator to reduce the build system load on generated files for this generator.
2023-07-28 16:52:44 +00:00
list(TRANSFORM BINDINGS_SOURCES PREPEND "${CMAKE_CURRENT_BINARY_DIR}/")
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
target_sources(${target} PRIVATE ${BINDINGS_SOURCES})
Meta+BindingsGenerator: Only invoke BindingsGenerator once per IDL file This reduces the number of tasks to schedule, and the complexity of the build system integrations for the BindingsGenerator. As a bonus, we move the "only write if changed" feature into the generator to reduce the build system load on generated files for this generator.
2023-07-28 16:52:44 +00:00
get_property(include_paths DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY INCLUDE_DIRECTORIES)
list(TRANSFORM include_paths PREPEND -i)
# Ninja expects the target name in depfiles to be relative to CMAKE_BINARY_DIR, but ${bindings_src} is
# relative to CMAKE_CURRENT_BINARY_DIR. CMake >= 3.20 can do the rewriting transparently (CMP0116).
set(depfile_prefix_arg "")
if(CMAKE_GENERATOR MATCHES "^Ninja" AND NOT POLICY CMP0116)
file(RELATIVE_PATH depfile_target ${CMAKE_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR})
set(depfile_prefix_arg "--depfile-prefix ${depfile_target}" )
endif()
add_custom_command(
OUTPUT ${BINDINGS_SOURCES}
COMMAND "$<TARGET_FILE:Lagom::BindingsGenerator>" -o "Bindings" --depfile "Bindings/${basename}.d"
${depfile_prefix_arg} "${LIBWEB_INPUT_FOLDER}/${class}.idl" "${LIBWEB_INPUT_FOLDER}"
VERBATIM
COMMENT "Generating Bindings for ${class}"
DEPENDS Lagom::BindingsGenerator
MAIN_DEPENDENCY ${class}.idl
DEPFILE ${CMAKE_CURRENT_BINARY_DIR}/Bindings/${basename}.d
)
add_custom_target(generate_${basename} DEPENDS ${BINDINGS_SOURCES})
add_dependencies(all_generated generate_${basename})
add_dependencies(${target} generate_${basename})
LibWeb: Add new code generator for creating exposed interface helpers This new code generator takes all the .idl files in LibWeb, looks for each top level interface in there with an [Exposed=Foo] attribute, and adds code to add the constructor and prototype for each of those exposed interfaces to the realm of the relevant global object we're initialzing. It will soon replace WindowObjectHelper as the way that web interfaces are added to the Window object, and will be used in the future for creating proper WorkerGlobalScope objects for dedicated and shared workers.
2022-10-08 22:58:55 +00:00
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
set(BINDINGS_HEADERS ${BINDINGS_SOURCES})
list(FILTER BINDINGS_HEADERS INCLUDE REGEX "\.h$")
Meta: Guard everything that installs headers with an option
2024-07-20 17:03:24 +00:00
if (ENABLE_INSTALL_HEADERS)
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
install(FILES ${BINDINGS_HEADERS} DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/LibWeb/Bindings")
Meta: Guard everything that installs headers with an option
2024-07-20 17:03:24 +00:00
endif()
CMake: Make sure to install generated sources and header files We weren't installing a lot of generated sources for the top level Lagom build or for LibWeb, making it impossible to use LibWeb from a find_package. ...And also Kernel/API/KeyCode.h, which is included by no less than 8 different files in Userland/Libraries. We also weren't installing any Ladybird header files.
2023-08-08 04:14:22 +00:00
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
list(APPEND LIBWEB_ALL_GENERATED_HEADERS ${BINDINGS_HEADERS})
set(LIBWEB_ALL_GENERATED_HEADERS ${LIBWEB_ALL_GENERATED_HEADERS} PARENT_SCOPE)
LibWeb: Add new code generator for creating exposed interface helpers This new code generator takes all the .idl files in LibWeb, looks for each top level interface in there with an [Exposed=Foo] attribute, and adds code to add the constructor and prototype for each of those exposed interfaces to the realm of the relevant global object we're initialzing. It will soon replace WindowObjectHelper as the way that web interfaces are added to the Window object, and will be used in the future for creating proper WorkerGlobalScope objects for dedicated and shared workers.
2022-10-08 22:58:55 +00:00
list(APPEND LIBWEB_ALL_IDL_FILES "${LIBWEB_INPUT_FOLDER}/${class}.idl")
set(LIBWEB_ALL_IDL_FILES ${LIBWEB_ALL_IDL_FILES} PARENT_SCOPE)
endfunction()
function(generate_exposed_interface_files)
LibWeb: Generate dedicated methods to create Web constructors/prototypes Currently, for each exposed interface, we generate one massive function to create every Web constructor and prototype. In an effort to lazily create these instead, this first step is to extract the creation of each of these into its own method. First, this generates a forwarding header for all IDL types. This is to allow callers to remain unchanged without forcing them to include the (very heavy) generated IDL headers. This header is included by LibWeb's forwarding header. Next, this defines a base template method on Web::Bindings::Intrinsics to create a prototype/constructor pair. Specializations of this template are now generated in a new .cpp file, IntrinsicDefinitions.cpp. The base Intrinsics class is updated to use this new method, and will continue to cache the result. Last, some WebAssembly classes are updated to use this new mechanism. They were using some ad hoc cache keys that are now in line with the generated specializations. That one massive function is still used to invoke these specializations, so they are not lazy as of this commit.
2023-01-09 22:49:06 +00:00
set(exposed_interface_sources
LibWeb: Don't generate Bindings/Forward.h This is no longer used.
2024-04-27 00:51:14 +00:00
IntrinsicDefinitions.cpp
LibWeb: Generate dedicated methods to create Web constructors/prototypes Currently, for each exposed interface, we generate one massive function to create every Web constructor and prototype. In an effort to lazily create these instead, this first step is to extract the creation of each of these into its own method. First, this generates a forwarding header for all IDL types. This is to allow callers to remain unchanged without forcing them to include the (very heavy) generated IDL headers. This header is included by LibWeb's forwarding header. Next, this defines a base template method on Web::Bindings::Intrinsics to create a prototype/constructor pair. Specializations of this template are now generated in a new .cpp file, IntrinsicDefinitions.cpp. The base Intrinsics class is updated to use this new method, and will continue to cache the result. Last, some WebAssembly classes are updated to use this new mechanism. They were using some ad hoc cache keys that are now in line with the generated specializations. That one massive function is still used to invoke these specializations, so they are not lazy as of this commit.
2023-01-09 22:49:06 +00:00
DedicatedWorkerExposedInterfaces.cpp DedicatedWorkerExposedInterfaces.h
SharedWorkerExposedInterfaces.cpp SharedWorkerExposedInterfaces.h
WindowExposedInterfaces.cpp WindowExposedInterfaces.h)
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
list(TRANSFORM exposed_interface_sources PREPEND "Bindings/")
LibWeb: Add new code generator for creating exposed interface helpers This new code generator takes all the .idl files in LibWeb, looks for each top level interface in there with an [Exposed=Foo] attribute, and adds code to add the constructor and prototype for each of those exposed interfaces to the realm of the relevant global object we're initialzing. It will soon replace WindowObjectHelper as the way that web interfaces are added to the Window object, and will be used in the future for creating proper WorkerGlobalScope objects for dedicated and shared workers.
2022-10-08 22:58:55 +00:00
add_custom_command(
OUTPUT ${exposed_interface_sources}
COMMAND "${CMAKE_COMMAND}" -E make_directory "tmp"
COMMAND $<TARGET_FILE:Lagom::GenerateWindowOrWorkerInterfaces> -o "${CMAKE_CURRENT_BINARY_DIR}/tmp" -b "${LIBWEB_INPUT_FOLDER}" ${LIBWEB_ALL_IDL_FILES}
LibWeb: Generate dedicated methods to create Web constructors/prototypes Currently, for each exposed interface, we generate one massive function to create every Web constructor and prototype. In an effort to lazily create these instead, this first step is to extract the creation of each of these into its own method. First, this generates a forwarding header for all IDL types. This is to allow callers to remain unchanged without forcing them to include the (very heavy) generated IDL headers. This header is included by LibWeb's forwarding header. Next, this defines a base template method on Web::Bindings::Intrinsics to create a prototype/constructor pair. Specializations of this template are now generated in a new .cpp file, IntrinsicDefinitions.cpp. The base Intrinsics class is updated to use this new method, and will continue to cache the result. Last, some WebAssembly classes are updated to use this new mechanism. They were using some ad hoc cache keys that are now in line with the generated specializations. That one massive function is still used to invoke these specializations, so they are not lazy as of this commit.
2023-01-09 22:49:06 +00:00
COMMAND "${CMAKE_COMMAND}" -E copy_if_different tmp/IntrinsicDefinitions.cpp "Bindings/IntrinsicDefinitions.cpp"
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
COMMAND "${CMAKE_COMMAND}" -E copy_if_different tmp/DedicatedWorkerExposedInterfaces.h "Bindings/DedicatedWorkerExposedInterfaces.h"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different tmp/DedicatedWorkerExposedInterfaces.cpp "Bindings/DedicatedWorkerExposedInterfaces.cpp"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different tmp/SharedWorkerExposedInterfaces.h "Bindings/SharedWorkerExposedInterfaces.h"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different tmp/SharedWorkerExposedInterfaces.cpp "Bindings/SharedWorkerExposedInterfaces.cpp"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different tmp/WindowExposedInterfaces.h "Bindings/WindowExposedInterfaces.h"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different tmp/WindowExposedInterfaces.cpp "Bindings/WindowExposedInterfaces.cpp"
LibWeb: Add new code generator for creating exposed interface helpers This new code generator takes all the .idl files in LibWeb, looks for each top level interface in there with an [Exposed=Foo] attribute, and adds code to add the constructor and prototype for each of those exposed interfaces to the realm of the relevant global object we're initialzing. It will soon replace WindowObjectHelper as the way that web interfaces are added to the Window object, and will be used in the future for creating proper WorkerGlobalScope objects for dedicated and shared workers.
2022-10-08 22:58:55 +00:00
COMMAND "${CMAKE_COMMAND}" -E remove_directory "${CMAKE_CURRENT_BINARY_DIR}/tmp"
VERBATIM
DEPENDS Lagom::GenerateWindowOrWorkerInterfaces ${LIBWEB_ALL_IDL_FILES}
)
target_sources(${target} PRIVATE ${exposed_interface_sources})
Lagom+CMake: Propagate dependencies for generated custom targets We have logic for serenity_generated_sources which works well for source files that are specified in GENERATED_SOURCES prior to calling serenity_lib or serenity_bin. However, code generated with invoke_generator, and the LibWeb generators do not always follow the pattern of the IDL and GML files. For the LibWeb generators, we can just add_dependencies to LibWeb at the time we declare the generate_Foo custom target. However for LibLocale, LibTimeZone, and LibUnicode, we don't have the name of the target available, so export the name in a variable to set into GENERATED_SOURCES. To make this work for Lagom, we need to make sure that lagom_lib and serenity_bin in Lagom/CMakeLists.txt call serenity_generated_sources on the target. This enables the Xcode generator on macOS hosts, at least for Lagom.
2022-10-17 05:49:52 +00:00
add_custom_target(generate_exposed_interfaces DEPENDS ${exposed_interface_sources})
add_dependencies(all_generated generate_exposed_interfaces)
add_dependencies(${target} generate_exposed_interfaces)
CMake: Make sure to install generated sources and header files We weren't installing a lot of generated sources for the top level Lagom build or for LibWeb, making it impossible to use LibWeb from a find_package. ...And also Kernel/API/KeyCode.h, which is included by no less than 8 different files in Userland/Libraries. We also weren't installing any Ladybird header files.
2023-08-08 04:14:22 +00:00
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
list(TRANSFORM exposed_interface_sources PREPEND "${CMAKE_CURRENT_BINARY_DIR}/")
set(exposed_interface_headers ${exposed_interface_sources})
list(FILTER exposed_interface_headers INCLUDE REGEX "\.h$")
Meta: Guard everything that installs headers with an option
2024-07-20 17:03:24 +00:00
if (ENABLE_INSTALL_HEADERS)
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
install(FILES ${exposed_interface_headers} DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/LibWeb/Bindings")
Meta: Guard everything that installs headers with an option
2024-07-20 17:03:24 +00:00
endif()
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
list(APPEND LIBWEB_ALL_GENERATED_HEADERS ${exposed_interface_headers})
set(LIBWEB_ALL_GENERATED_HEADERS ${LIBWEB_ALL_GENERATED_HEADERS} PARENT_SCOPE)
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
endfunction()
CMake+Userland: Use CMakeLists from Userland to build Lagom Libraries Also do this for Shell. This greatly simplifies the CMakeLists in Lagom, replacing many glob patterns with a big list of libraries. There are still a few special libraries that need some help to conform to the pattern, like LibELF and LibWebView. It also lets us remove essentially all of the Serenity or Lagom binary directory detection logic from code generators, as now both projects directories enter the generator logic from the same place.
2022-10-14 02:14:36 +00:00
include("idl_files.cmake")
LibWeb: Add new code generator for creating exposed interface helpers This new code generator takes all the .idl files in LibWeb, looks for each top level interface in there with an [Exposed=Foo] attribute, and adds code to add the constructor and prototype for each of those exposed interfaces to the realm of the relevant global object we're initialzing. It will soon replace WindowObjectHelper as the way that web interfaces are added to the Window object, and will be used in the future for creating proper WorkerGlobalScope objects for dedicated and shared workers.
2022-10-08 22:58:55 +00:00
generate_exposed_interface_files()
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
LibWeb: Generate a clang module map file, including generated headers
2024-08-07 03:58:38 +00:00
set(LIBWEB_ALL_GENERATED_HEADERS ${LIBWEB_ALL_GENERATED_HEADERS} PARENT_SCOPE)
Meta: Move LibWeb's CMake generation script to its own file This patch has no functional changes, but prepares the CMake script to be able to handle LibWeb on Lagom.
2022-04-30 10:50:51 +00:00
endfunction()
Reference in a new issue Copy permalink