[angle] Update to chromium/5414, improve build system (and future updates)

[past-due]

• Update commit to latest on stable chromium/5249 branch
• Generate angle_commit.h
• Refactor build system based on WebKit's CMake build system for libANGLE
• Add maintainer-notes.md

Describe the pull request

Update the angle port (libANGLE) to chromium/5249 (corresponding to the current Chromium Stable release).

(This follows the recommendations in the libANGLE "Choosing an ANGLE branch" guide, matching the current Chromium Stable 106.0.5249.119.)

Also, refactor the build system based on WebKit's CMake build system for libANGLE (including scripts and instructions to ease updating this port in the future).

• Which triplets are supported/not supported? Have you updated the CI baseline?

  Same triplets as existing

• Does your PR follow the maintainer guide?

  Yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  Yes, waiting to see how CI checks out

[github-actions]

You have modified or added at least one vcpkg.json where you should check the license field.

If you feel able to do so, please consider adding a "license" field to the following files:

• ports/angle/vcpkg.json

Valid values for the license field can be found in the documentation

[Neumann-A]

considering that port skia and crashpad are already invoking gn and can be used I don't see why we should still use CMake to build angle. The main thing somebody has to find out is how to get from vcpkg-get-cmake-vars to a proper toolchain with the compiler and everything setup.

[past-due]

And support community triplet quirks, and handle a bunch of chromium/standalone-specific stuff and flags, which the existing (and this revised) CMake build system do (or otherwise bypass having to worry about), etc.

In lieu of spending time trying to add support for another build system (with extremely limited port use), I figured this would be a good improvement over the status quo, based on a widely-used CMake build system for the port.

(And updating a long-outdated port, fixing numerous security issues.)

Longer-term, if someone wants to go through the effort and get a gn build setup working for windows, osx, linux, mingw, other community triplets, etc - I will be happy to test. 👍

[Neumann-A]

(And updating a long-outdated port, fixing numerous security issues.)

The reason it is outdated is because it uses a CMakeLists.txt instead of the upstream buildsystem. Just saying...

[Neumann-A]

(even though this is the wrong section to comment on)
The OUTPUT_NAME of the libraries are in conflict with glvnd on linux

[past-due]

The port currently exports libGLESv2.dll, libEGL.dll, (etc), that's what the upstream ANGLE setup builds, and that's what other projects are expecting the port to export.

(Example: SDL2)

So there's no change here (unless I'm missing something?), and any such conflict is pre-existing and expected. (ANGLE, by definition, provides an implementation of libGLESv2 and libEGL.)

[Neumann-A]

The port currently exports libGLESv2.dll, libEGL.dll, (etc), that's what the upstream ANGLE setup builds, and that's what other projects are expecting the port to export.

I am not talking about windows where those name are in conflict with mesa ;) I just accept angle as superior on windows since it redirects to D3D instead of using SWR. That being said you also want a egl.pc file on windows.

On Linux however you don't want to link the angle implementation. You want to link libglvnd which will redirect to the correct egl/glx/gles vendor implementation on a per window basis. So you need libEGL_angle.so and an ICD manifest for it in the correct folder.

I had enough problems with trying to link against it in #26693

[past-due]

The port currently exports libGLESv2.dll, libEGL.dll, (etc), that's what the upstream ANGLE setup builds, and that's what other projects are expecting the port to export.

I am not talking about windows where those name are in conflict with mesa ;) I just accept angle as superior on windows since it redirects to D3D instead of using SWR. That being said you also want a egl.pc file on windows.

On Linux however you don't want to link the angle implementation. You want to link libglvnd which will redirect to the correct egl/glx/gles vendor implementation on a per window basis. So you need libEGL_angle.so and an ICD manifest for it in the correct folder.

My understanding is that would not match the upstream build system (at least, it’s a change from the current port), but if we want to diverge then contributions are welcome.

I had enough problems with trying to link against it in #26693

I thought Qt6 no longer included ANGLE?

(Reference: https://doc.qt.io/qt-6/opengl-changes-qt6.html )

[Neumann-A]

I thought Qt6 no longer included ANGLE?

It doesn't but it still links egl. And if ANGLE is installed with libEGL it will pickup ANGLE from vcpkg instead of using the system version from libglvnd.

FindEGL or FindOpenGL are stupid. They will just search by name.

[past-due]

Could someone please trigger a re-run of the x64_linux CI pass?

Looks like an unrelated failure:

Downloading vcpkg-glibc...
curl: (18) transfer closed with 3386757 bytes remaining to read

[BillyONeal]

I agree being able to use the upstream build system would be better, but IMO this is an improvement over the status quo so I'm inclined to merge it. However, I want to confirm with other maintainers.

[BillyONeal]

@ras0219-msft @JavierMatosD @markle11m @vicroms @AugP @valeriaconde @dan-shaw, and I discussed this today.

I noted that I am happy with this approach.

@ras0219-msft asked that the instructions and scripts (like maintainer-notes.md, convert-angle-to-cmake.sh) be moved outside of the port (for example, to scripts/angle/*).

We are concerned about potential licensing impact of copying this much Angle and WebKit code into vcpkg's repo and would prefer reducing that if possible. For example, running the python script and including a patch file with the edits.

Should we just try to use WebKit's fork directly?

[past-due]

@ras0219-msft asked that the instructions and scripts (like maintainer-notes.md, convert-angle-to-cmake.sh) be moved outside of the port (for example, to scripts/angle/*).

Makes sense to me.

We are concerned about potential licensing impact of copying this much Angle and WebKit code into vcpkg's repo and would prefer reducing that if possible. For example, running the python script and including a patch file with the edits.

This is partially why I did not include the gni-to-cmake.py script, but instead referenced it in the maintainer-notes.md. However, I see there's the potential for vcpkg_find_acquire_program(PYTHON3), so this could indeed seemingly be used to generate the files as part of the port.

I can look into fetching certain files from a pinned commit from the WebKit repo, and using those to generate the files under ports/angle/cmake-buildsystem/generated/*.cmake as part of the vcpkg portfile.

A few files needed to be extensively modified (or largely re-written), so I'll evaluate to see which ones offer the easiest path for reductions.

Should we just try to use WebKit's fork directly?

Two issues that come immediately to mind:

1. I believe WebKit employs a completely different process in regards to selecting the ANGLE commit / branch they are using (and also update cadence), and I think for vcpkg it makes more sense to follow the libANGLE "Choosing an ANGLE branch" guide (matching the current Chromium Stable).
2. WebKit's fork has their own additional patches applied (which have changed over the years) and isn't really intended for use outside of WebKit

So I'd lean much more towards your first proposal of reducing what needs to be in the vcpkg repo, fetching selected files, running gni-to-cmake.py as part of the port, etc. I think that'll work better and continue to limit how tightly bound it is to all of the other WebKit build system.

[JonLiu1993]

@past-due, could you please fix the conflicting files?, then we can merge this PR, thanks!

[github-actions]

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

PRs must add only one version and must not modify any published versions

When making any changes to a library, the version or port-version in vcpkg.json or CONTROL must be modified.

error: checked-in files for angle have changed but the version was not updated
version: chromium_5414
old SHA: 0b94de610273c3ac6a4a8e9aeef0d1176dce1462
new SHA: 4d21d50c6a69b88182c328b4867a27909fa34b01
Did you remember to update the version or port version?
Use --overwrite-version to bypass this check
***No files were updated***

[past-due]

@past-due, could you please fix the conflicting files?, then we can merge this PR, thanks!

@JonLiu1993: Done 👍

[molesmoke]

Looks like this now installs the headers to the wrong location? e.g.
include/headers/EGL/eglext_angle.h
should be
include/EGL/eglext_angle.h

However, it seems like the intention of an earlier commit was that the angle headers should be copied to:
include/angle/
Though I note that didn't seem to be working previously anyway...