cefsharp / cef-binary

NuGet repackaging of the CEF binaries provided by Chromium Embedded Framework
https://cef-builds.spotifycdn.com/index.html
Other
108 stars 87 forks source link

Add -BuildArches to specify what platforms to build for (ie "x86 arm64") #100

Closed mitchcapper closed 2 years ago

mitchcapper commented 2 years ago

Removed much of the platform specific code redundancy Fixes #98.

Most is pretty straightforward but a few specific notes:

-- Added -Wno-dev to cmake calls, this suppresses some warnings that were dumping to screen but not causing an issue for the build. The flag is only for author of the CMakeLists.txt per https://cmake.org/cmake/help/latest/manual/cmake.1.html#manual:cmake(1) I believe we are using the generator to do this and not ourselves.

-- In the current build.ps1 there is a step that # Make sure there is a 32bit and 64bit version for the specified build and that they are the same version. It still does this check but it does it as it goes so will start downloading versions and only stop once it detects there is a mismatch. Done this way to just save an extra loop and because I couldn't think of any harm coming of it.

-- The way I am building the nuspec for the runtime is a bit sloppy with hardcoded strings in the build.ps1 script. Using an actual templating engine would be better, but as this is powershell it seemed easiest to do this small replacement in this fashion.

amaitland commented 2 years ago

Sorry for the delay.

I was thinking of rewriting the script and now seems like the time, I needed to do testing anyway.

Commit https://github.com/cefsharp/cef-binary/commit/26010a5dee2031d5e2b5ac8fd2ebf47fd77c07a1 is a major overhaul. It should be compatible with your changes.

The x64, x86, arm64 arguments for -BuildArches will still work, so will win-x86, win-x64, win-arm64, just in case at some point we get around to adding the ability to package Linux/mac runtimes (#95)

In the current build.ps1 there is a step that # Make sure there is a 32bit and 64bit version for the specified build and that they are the same version. It still does this check but it does it as it goes so will start downloading versions and only stop once it detects there is a mismatch. Done this way to just save an extra loop and because I couldn't think of any harm coming of it.

Builds will now fail if unable to download the file for a given architecture. This is effectively what happened previously, just now there's a clearer message.

I've still like to do a little more refactoring here, ideally we'd check that all files can be downloaded before we start extracting them, this should be pretty straight forward now.

The way I am building the nuspec for the runtime is a bit sloppy with hardcoded strings in the build.ps1 script. Using an actual templating engine would be better, but as this is powershell it seemed easiest to do this small replacement in this fashion.

I've actually reverted this, I have some other changes planned in the near future. I've be creating a new chromiumembeddedframework.runtime.resources package so I can deprecate the cef.redist packages (#93). I've gone with the low tech option of creating the folders on disk and having empty ones in the package.

As swiftshader is being replaced by SwANGLE we'll be able to get rid of arch specific dlls. The new SwANGLE files don't need to be in a subfolder.

I need to triple check though I believe the locales aren't architecture specific, they're currently duplicated, so I'll switch to having just a single copy (assuming they all hash the same across a few versions).