Closed DonKichot closed 1 year ago
It was removed in https://github.com/msys2/MINGW-packages/commit/55de803278c97ac0d19253c2edefdf397cc18342 probably because there are no releases available.
@mati865: What do you mean by "no releases available"? You can also look at: https://github.com/google/angle and there clearly are new commits.
@DonKichot it was removed because I dont want to learn and create packages for GN build system
@Alexpux: That is understandable. From my perspective GN seems to favor llvm over gcc. Did you manage to compile it with gcc toolchain on Linux?
@DonKichot I dont build packages on Linux at all. MSYS2 is Windows based project
@Alexpux: I understand that. I just wanted to convert the project to CMake and gcc so it would be easier to compile via MSYS2 - I think. However, I just could not compile it on Linux successfully.
@DonKichot : you can require clang as a build requisite for a package. As long as the resulting binary works, it doesn't matter which compiler was used.
Converting the project to CMake is something that should be implemented within the upstream project. You should talk to them about it.
BTW, for MSYS2 the build tool is also indifferent. As long as you provide a working PKGBUILD and take care of maintenance, I don't think that Alexpux would object.
I maned to compile the library with the provided clang++: https://gist.github.com/DonKichot/68e7ec761fa349d9e159cc06de1f2d69 However, I could not achieve positive results with g++ 5.4 on Ubuntu 16.04: https://gist.github.com/DonKichot/e70089cf3b9f2caaf11fe1338d5b801d Any ideas why is that happening?
@DonKichot : I don't think this is the correct place for discussing build issues on an environment that is not MSYS2/Mingw-w64.
So I found a set of cmake files that work, but against mingw-w64 it'll compile to a certain point using latest angle, that's mainly because angle now requires d3d12, something that's not yet in mingw-w64. So for to include angle, you'd need an old copy, or wait for mingw-w64 to generate new d3d headers for d3d12
@ZachBacon Do you have a custom pkgbuild file to compile this package?
@ZachBacon Do you have a custom pkgbuild file to compile this package?
I do not, at the time I was just testing a dry run of the compile, and then I kinda gave up a bit and then built a new PC etc. That stuff I don't have anymore.
I found a repository to cross compile angleproject in ArchLinux here https://github.com/Martchus/PKGBUILDs/tree/master/angleproject/mingw-w64. I can not make the package in ArchLinux due to permission issue. Maybe the pkgbuild is not correct. Also the dependencies (google-cloud-sdk) are too big to be ported in msys2/mingw packages.
even more recent arch cross compile angle https://github.com/gk7huki/mingw-w64-angleproject still makes use of gyp and what not, I'm investigating a bit, but seems msys2's gyp might have some issues with tabulation and spaces that python seems to be complaining about regarding generators.
I have managed to create a PKGBUILD that build ANGLE, using https://github.com/gk7huki/mingw-w64-angleproject. The builded branch is 2 years old though.
I looked into newer ANGLE and you have to use Google's depot_tools which, on windows, will clone a lot of third-party repositories and build them before even building angle (for example: libpng, libjpeg-turbo, vulkan-headers/loaders, spirv-tools/cross, etc). Maybe it is possible to analyse the generated ninja files to create a CMakeList.txt from them such that one does not have to build all those deps.
Maybe it is possible to add .gyp files again to and modify them a little bit so that ANGLE builds.
Should I still upload my PKGBUILD ?
MinGW-w64 8.0.0 comes with d3d12.h
.
I have a personal build of GCC 10.2.0 against MinGW-w64 8.0.0 available at http://winlibs.com/
I'm also looking for a way to get angle to compile, but I just can't seem to get it configure properly with gn
. Any pointers on how it should be done?
I have gn
and ninja
as well as the http://winlibs.com/ MinGW-w64 build available from my MSYS2 shell, as well as all the prerequisites which I built from source using the same environment (including vulkan-loader).
I can give it a try, but cannot make any promise. I think the best way forward is to simply use their build system: GN. Will need to see how to make it use dependencies from the system rather than in-tree checkouts.
GN is "unstable", i.e. it can make breaking changes at any time (though they say that's a rarity in practice), so I'm not sure if it's worth having a standalone package for GN. Anyone has a preference in that regard?
It can be possible to make GN as a git package like this https://archlinux.org/packages/extra/x86_64/gn/. Separate package will always be better, IMO.
GN is "unstable", i.e. it can make breaking changes at any time (though they say that's a rarity in practice), so I'm not sure if it's worth having a standalone package for GN. Anyone has a preference in that regard?
It was previously discussed https://github.com/msys2/MINGW-packages/pull/6792. Also, recently when playing with skia I just build gn in the PKGBUILD of skia itself, since it requires a specific version of gn so that it can be built. See https://github.com/msys2/MINGW-packages/pull/10195
@lb90 (since you were gonna give it a try), I have made some recipes a few days back for this https://github.com/naveen521kk/MINGW-packages/tree/angle-new-package/mingw-w64-angleproject. Many of the patches there are for gn and chromium build (which is from the v8 package), but not exactly for angle itself. I mainly did the because @ZachBacon was discussing it Discord, and seemed I can help. I hope that helps you!
That's great. Thank you very much!
Hi guys. Thanks for trying to create a MSYS2 package for Angle. Is there any progress?
Angle package in MSYS2 will be extremely useful for other projects. For example, we can enable OpenGL support in MSYS2 windows build of QEMU with angle. Angle requirement was mentioned in the QEMU OpenGL support request issue that I linked below. https://github.com/msys2/MINGW-packages/issues/8506
Is there any proper instruction on how to use gn
under MSYS2 with GCC?
@Biswa96 Regarding the Wine D3D headers / IDLs, there's this interesting project by Microsoft: https://github.com/microsoft/DirectX-Headers. Would it make sense to update the IDLs in Wine with those?
We've come a long way since this issue was started. mingw-w64 now has many DxD IDL files. Just name those, I can try to add it.
Would it make sense to update the IDLs in Wine with those?
IMO, only official Windows SDK header files and documentation should be followed. Microsoft has a habit of creating gazillions things of same implementation until it becomes harder to understand. That repository not only contains WinSDK's dxd stuff but also has some wrappers for WSL and new agility SDK.
mingw-w64-angleproject package is available now. It was added in this commit. The package can be installed with pacman -S $MINGW_PACKAGE_PREFIX-angleproject
command. Huge thanks to raedrizqie.
Project URL:https://chromium.googlesource.com/angle/angle Is it possible to easily convert it from their GN (https://gn.googlesource.com/gn) to CMake?