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.
LibTLS still can't access many parts of the web, so let's hide this
behind a flag (with all the plumbing that entails).
Hopefully this can encourage folks to improve LibTLS's algorithm support
:^).
We don't need the extra gradle files in our sources, the Qt CMake
integration will generate suitable ones for us.
Make sure that assets is always a folder, so that we can get the proper
layout for the ladybird-assets.tar.gz and CMake doesn't create a gzip
file with the name "assets".
Fix up the AndroidPlatform file and make sure it's linked into all the
applications that need it. Also make sure to copy all the application
shared libraries into the ladybird APK so that when we make them into
proper Services, the libs are already there.
Use a list of executables to make sure that we don't miss any of the
applications used by Ladybird and its friends like WebDriver, and make
sure to install include all executables and their runtime dependencies.
Always call platform_init after there's a QApplication, because in the
installed configuration that's how we find the resources.
Try QCoreApplication::applicationDirPath() after looking in ./WebContent
for the WebContent process. In an installed configuration, ladybird and
WebContent will both be in $PREFIX/bin.
Add install rules for WebContent and its linked libraries, for if they
ever differ from ladybird's.
This setup should allow the package maintainers who are looking to
distribute ladybird on their distributions to use CMake to install
ladybird using cmake install rules rather than having to write their own
