Problems linking with dawn

[Mark Sibly]

Hi,

I've got dawn building with cmake/msvc and the samples are  running but I'm having trouble linking the various dawn libs with my own app.

I had a look at the CMakeLists.txt in the samples dir and it appears all samples have dependencies on the following libs:

dawncpp
dawn_proc
dawn_common
dawn_glfw
dawn_native
dawn_wire
dawn_utils
glfw

However, even linking with these I still get many missing symbols, esp. from tint:: and absl:: and there are indeed a bunch of tint and absl and misc third party libs in there but so far adding these hasn't worked.

I successfully built and linked with dawn about a few years ago and I don't remember the linking process being nearly as painful which makes me think maybe I'm doing it wrong! Any hints or tips?

Bye!

Mark

[Mark Sibly]

OK, the problem was of course due to the fact the above libraries recursively reference other libraries etc.

I suck at cmake, but eventually found a function someone has written to 'bundle' libraries recursively:

https://cristianadam.eu/20190501/bundling-together-static-libraries-with-cmake/

I added a dawn_static dir to dawn with a CMakeLists.txt that included the bundle_static_library function above, along with:

```

add_library(dawn_static_libs STATIC ${DAWN_PLACEHOLDER_FILE})
target_link_libraries(dawn_static_libs PUBLIC
        dawn_native
        dawn_proc)

bundle_static_library(dawn_static_libs dawn_static)

```

Finally, I added add_subdirectory(dawn_static) to the *end* of top level CMakeLists.txt, all of which adds a new target called 'bundling_target' that, when built, produces a *single* dawn_static.lib you can use with your own projects!

Note: The bundle_static_library function needs to used *after* all dependent libraries have been add_library'd.

I would really love to see something like this added to dawn!

Bye,

Mark

[Corentin Wallez]

Hey Mark,

Thanks for your patience and investigating solutions. I'm not a huge expert on CMake but my understanding is that since libraries like dawn_native list Tint and Abseil as PRIVATE things to link, even in static lib mode, they should correctly propagate dependencies and link into your application. Do the samples build on your machine? They take advantage of that so if they work, then something should be wrong in the setup of your app? +CC Dan as he knows a bit more about CMake maybe?

Corentin

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CAK32ozitO5qygoLjR8HpskmkCCySFM4B2Luc1xFe%2BjcrRmwFhA%40mail.gmail.com.

[dan sinclair]

I think a lot of the context got chopped from the message, so I'm not sure what it is you're trying to do. That said, it should be possible to use Dawn from CMake without any Dawn changes. The https://github.com/dj2/dusk repo does this, it just needed a `target_link_libraries(<target> webgpu_dawn webgpu_cpp webgpu_glfw glfw)`.

That said, Dusk isn't trying to do anything complicated, so it's hard to tell without understanding what you're attempting to do.

dan

[Mark Sibly]

> I'm not a huge expert on CMake but my understanding is that since libraries like dawn_native list Tint and Abseil as PRIVATE things to link, even in static lib mode, they should correctly propagate dependencies and link into your application.

Yes, I believe this is correct, but it means that to link my app with dawn I need to effectively add the *entire* dawn project to my app project - well, if not the entire project, at least the cmake files files (so it can see all those PRIVATE things it needs) and prebuilt libs.

I dunno, maybe it's just me getting old and cranky or something, but it seems nuts to me to have to add the entire dawn project to my own (much smaller!) project for a ton of reasons. I would really rather have a clean separation between my project and the dawn project.

So yes, I can build the samples fine, but only because they 'have access to' the dawn project. I would have similar problems if I were to try and isolate them and create a separate standalone dawn_samples project or something.

> That said, it should be possible to use Dawn from CMake without any Dawn changes.

Thanks, I will take a look at 'Dusk' to see how they've done it.

[Austin Eng]

Our GN build has a way to build WebGPU w/ Dawn as the implementation as a single complete static library. It's target `src/dawn/native:webgpu_dawn`

That gives you a single library that you can link into your application, and use the WebGPU C++ API with it.

IIUC, that's what we would want for CMake as well. I've linked to this mailing list in another report about improved CMake integration here.

[Mark Sibly]

> Our GN build has a way to build WebGPU w/ Dawn as the implementation as a single complete static library

Aha, that explains why I found it easier to build before, there didn't used to be a cmake build I think?

This makes cmake builds a lot less useful IMO, and I really think this should really be mentioned somewhere here:

https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/building.md

...including the bit about which gn target to build for a standalone static lib.

Bye,

Mark

[dan sinclair]

Is the issue that there is no install target, so we don't create an installed library and headers on the system? Otherwise, how are you using cmake such that you wound't need a copy of dawn to build your project?

dan

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CAK32ozh0L1UKe-35XumyBEi8tEzUVartCs1svDS8gp2NMjR3vw%40mail.gmail.com.

[Mark Sibly]

> Otherwise, how are you using cmake such that you wound't need a copy of dawn to build your project?

See my second post above - I basically found a clever cmake function online that recursively 'bundles' a bunch of static libs into a single static lib.

I'm not sure how cmake 'install target's work, but if they do the same thing that's probably the more elegant way to go.

Bye,

Mark

[Erin Melucci]

Hello,

We have the same problem and our workaround to the missing standalone static library is a Conan recipe with some hacks to piece it all together (building with GN isn't an option due to toolchain incompatibilities).
Having a proper CMake install target would be very helpful. 

Erin

[Corentin Wallez]

Clearly better CMake support is of interest to a lot of people! Let's find what we need to fix, Erin you're already looking to do some changes if I understand correctly, but anything that makes it easier to consume Dawn libraries is welcome. The team working on Dawn has an ok understanding of CMake but aren't experts, do you have pointers to best-practices for the type of libraries similar to Dawn? Or pointers to other complex projects with a good CMake build system integration?

Cheers,

Corentin

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/cc170dff-dfb4-4913-85e7-a2bd314e89c4n%40googlegroups.com.

[Erin Melucci]

I actually have a couple small patches ready which I'll be sending once I get the CLA sorted out.

Projects that come to mind in no particular order:
dolphin-emu has a big CMake tree and does many things, a good inspiration but perhaps not the best since it's not a library;
recent versions of KDE libraries;
maybe the most useful reference considering google oss policies and has great modularity, abseil-cpp.

It would also be nice to start using `find_package()` so that conan/vcpkg/other package manager users can drop the burden of having to sync with `depot_tools` (the two can peacefully coexist but it needs some thought because of the auto-roller you have).

Cheers,
Erin

[Jaswant Panchumarti]

Hi!

I've been experimenting with introducing a dawn native rendering backend for VTK - a scientific visualization toolkit at Kitware. VTK uses CMake as the build system and bundles up a lot of third party libraries this way. Linking with dawn from other C++ projects through the CMake find_package mode is practically impossible right now.

The important step missing in Dawn's CMake build process is that it does not export the targets. When exported correctly, other applications/libraries can simply find_package(Dawn COMPONENTS [dawn_native,....]) and acquire all those dependencies. We may be able to help improve the CMake build system. Are the Dawn folks interested?

[Austin Eng]

We would welcome any contributions to help improve the CMake build!
Please see the docs in CONTRIBUTING.md as you or your company will need to sign the Google CLA to make a contribution.