Build issues in Dawn after recent update

[Jean-Colas Prunier]

Hey there,

I recently revisited Dawn after a break and updated to the latest codebase, only to encounter some new build issues. Specifically, when setting the following flags in the `args.gn` file within the `out/Official` directory:

```gn
is_official_build=true
strip_debug_info=true
symbol_level=0
```

I ran into an error about a missing Python PGO-related file:

```
D:/libraries/depot_tools/bootstrap-2@3_11_6_chromium_30_bin/python3/bin/python3.exe: can't open file 'N:\\libraries\\dawn\\tools\\update_pgo_profiles.py': [Errno 2] No such file or directory
ERROR at //build/config/compiler/pgo/BUILD.gn:113:23: Script returned non-zero exit code.
      pgo_data_path = exec_script("//tools/update_pgo_profiles.py",
                      ^----------
```

I bypassed this by commenting it out, but I'm uncertain if PGO is used for the optimized release (official) builds.

Moreover, I've been facing compilation errors via terminal commands that weren't an issue before, leading me to revert to building directly from vs2022. It's perplexing why builds succeed in vs2022 but fail in the terminal, given both should theoretically perform the same operations.

The terminal errors relate to C++20 standards, such as deprecated implicit copy assignment operators for classes with user-declared destructors:

```
../../include\dawn/platform/DawnPlatform.h(74,13): error: definition of implicit copy assignment operator for 'WaitableEvent' is deprecated because it has a user-declared destructor [-Werror,-Wdeprecated-copy-with-dtor]
   74 |     virtual ~WaitableEvent() = default;
```

Given that your builds presumably pass without issue, I'm seeking insights or recommendations on resolving these discrepancies. Are you employing C++20 for Dawn, or do you default to C++17? I've experimented with both `clang-cl` and `cl` compilers without notable differences.

Understanding that build system issues can be uniquely complex and not directly your responsibility to fix, my inquiry stems from previous success following the same setup steps, now seemingly failing. Any changes or suggestions you could provide would be greatly appreciated. Meanwhile, I have a workaround by building through vs2022, so my work isn't halted. Many thanks for any help you can offer.

[Jean-Colas Prunier]

I'll leave this post up as deleting it in the past has led to confusion. To clarify, building via vs2022 also failed, not just from the terminal – both methods encountered issues. I'm continuing to investigate the problem, but any advice or suggestions you might offer would be greatly appreciated.

[Jean-Colas Prunier]

Switching to C++17 did the trick. I modified `build/config/BUILD.gn` to ensure C++17 is used, changing both branches of the conditional to `/std:c++17` for Windows builds:

```gn
  } else if (is_win) {
    cflags_c += [ "/std:c11" ]
    cflags_cc += [ "/std:c++17" ]
  } else if (!is_nacl) {
```

It's a a hack since I couldn't figure out where to set the `use_cxx17` flag—GN and the overall build system are complex, and understanding the intricacies probably requires insider knowledge. The `use_cxx17` option isn't recognized in `args.gn`.

Now, that leaves us with two issues:

- The PGO issue.
- By default, the Ninja build appears to opt for C++20, which causes compilation failures. Forcing it to use C++17 works, but it feels like I'm hacking a build system, which is quite unsettling.

[Corentin Wallez]

is_official_build is a Chromium-specific flag that's used to crank up the optimizations and other things, including PGO. For Dawn in standalone you should use is_debug=true/false. See this page of the documentation on how to build Dawn and let us know if there improvements that could be done to help people picking up Dawn.

I'm not sure why your build defaults to using C++20 in GN. There are indeed a few places where we still use code that's valid in C++17 but deprecated in C++20.

--
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/6326d8a6-1e92-4e4a-aab1-ab0bdedd7c2dn%40googlegroups.com.

[Jean-Colas Prunier]

Thank you. I previously thought that setting is_debug=false didn't enable all optimizations, which is why I opted for is_official_build based on a configuration that worked in the past. I just noticed C++20 being set in the BUILD.gn file which is what seems to be what the current config produces.

This brings me back to a question I've raised before: Is Dawn intended for use as a standalone API? It seems like standalone use might not be fully supported or encouraged. Before we dedicate more resources to exploring this path, could we have some clarity on Dawn's intended use and support for standalone applications? Thank you.

[Corentin Wallez]

Dawn is meant to be used as a standalone API, in fact Chromium is in the process of porting all of it's page rendering (but WebGL) to Dawn as a standalone API. And there are many other uses of Dawn standalone in the wild. However, edges are still a bit rough: we are still agreeing on key aspects of webgpu.h with wgpu-rs (the Rust Mozilla equivalent of Dawn), build systems are still not super well integrated and we don't publish any precompiled artifacts.

So yes you should be able to rely on Dawn standalone, but there are rough edges that we will polish over time. Also I'm surprised you are using the GN build instead of the CMake build. Here's a CMake HelloTriangle for both native and WASM using Dawn and it's (imho) very straightforward: https://github.com/beaufortfrancois/webgpu-cross-platform-app/blob/main/CMakeLists.txt

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/b1b6c896-a4bf-4b46-beec-50ee216a6ccdn%40googlegroups.com.

[Jean-Colas Pro]

Thx Corentin,

My issue wasn't about using Dawn, but actually building the DLL in the first place. I mean, sure, I could have gone with CMake, but for some reason, we're not using it internally. Using GN with Ninja has been working fine for us so far. But, just out of curiosity, I might give CMake a shot to see if it solves the C++20 problem.

It's great to know that there are plans to support Dawn as a standalone API in the long term!

To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/CAGdfWNPW%2BVZsga1P7s1FbiEBoJZiLD6c%2Brp457GA9%2BF_1bWURQ%40mail.gmail.com.

[Jean-Colas Pro]

Ok checked and tried the examples you pointed me to

https://github.com/beaufortfrancois/webgpu-cross-platform-app/blob/main/CMakeLists.txt

It’s useful. Thanks. At least the process was really easy on Mac. I am yet to try it on Windows but I am sure it will work as easily. I will based our build process on this. I really appreciate you input on this. While I had seen you pointing someone to this link already recently, I thought the example was limited to just building against existing libs, etc.

Thanks again for your patience.

You received this message because you are subscribed to a topic in the Google Groups "Dawn Graphics" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dawn-graphics/FWwBkAr6lCE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/04D1F754-08E5-4A6D-B2AB-39337186FC9E%40jean-colas.com.