Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate CMake distribution in CD #251

Open
wants to merge 11 commits into
base: trunk
Choose a base branch
from

Conversation

eliemichel
Copy link
Contributor

Hello,

I am trying to make the integration of the precompiled binaries in a CMake-based project as easy and portable as possible for my WebGPU C++ guide and I came up with a solution that satisfies me:

  • Easy to integrate, with a webgpu CMake target to link like any library and that manages the pre-compiled binaries
  • Define a WEBGPU_BACKEND_WGPU to distinguish this distribution for the Dawn-based alternative that I also provide
  • Follow modern idioms of CMake
  • Works with emscripten

Currently I point my readers to my WebGPU-distribution repository but I think this is something that would be worth making available directly in the release of wgpu-native.

This PR adds to the CD process the generation of a distribution of WebGPU that can be simply copied in a CMake project and integrated with add_subdirectory(webgpu). More info to be found in distribution/REAMD.md.

This is something that I am going to also discuss with Dawn so that ideally we end up with a common way of packaging binaries for CMake. I'll be happy to discuss the details and adapt to as many use cases as possible!

Copy link
Collaborator

@almarklein almarklein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This sounds like it would be useful, but (being mostly a Python dev) I cannot judge whether this approach is good practice or something like that.

.github/workflows/cd.yml Outdated Show resolved Hide resolved
distribution/README.md Outdated Show resolved Hide resolved
Co-authored-by: Almar Klein <almar@almarklein.org>
Copy link
Collaborator

@almarklein almarklein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missed a spot :)

.github/workflows/cd.yml Outdated Show resolved Hide resolved
.github/workflows/cd.yml Outdated Show resolved Hide resolved
eliemichel and others added 2 commits April 13, 2023 22:33
Co-authored-by: Almar Klein <almar@almarklein.org>
Co-authored-by: Almar Klein <almar@almarklein.org>
@eliemichel
Copy link
Contributor Author

Oh thanks my bad!

@almarklein
Copy link
Collaborator

This is open for a while even though this is about finished. I think this needs a round of review from someone with more experience (than me) in build systems. cc @rajveermalviya

@waywardmonkeys
Copy link
Contributor

Is there something I can do to help push this along?

@waywardmonkeys
Copy link
Contributor

@rajveermalviya Any chance I can help get this wrapped up for the next release?

@rajveermalviya
Copy link
Collaborator

rajveermalviya commented Jan 21, 2024

(Apologies for missing this)

Tbh instead of this, I would prefer a setup where user can clone the repo (or github's download zip) to a directory and then import that directory via add_subdirectory.

Then the CMakeLists.txt at the root in this repo could the have an option like DOWNLOAD_PREBUILT_BINARIES, where default would be false. So, the binaries would be built from source by default & if that option is enabled then the binaries would be downloaded from Github Releases. Such a setup would also allow us to mirror cargo optional features that are currently disabled in the release packages.

But not really sure how emscripten would fit in that.

@eliemichel
Copy link
Contributor Author

I agree actually, not my topmost priority at the moment but I'll work on this eventually!

@waywardmonkeys
Copy link
Contributor

wasmtime does something similar as well. I have it on my list to try to get to this sooner rather than later.

@waywardmonkeys
Copy link
Contributor

I have a working prototype of this locally now. I'll need #359 to land and then I can start on a series of PRs that get us to (what I hope is) a good place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants