| 25 Nov 2025 |
 K900 | I don't think we really have C++ modules working | 10:55:30 |
| K900 | On any of the compilers | 10:55:37 |
| K900 | It needs some cc-wrapper fixing but nothing uses them or can agree on how to use them | 10:55:53 |
| K900 | So no one did the work | 10:56:13 |
 megmug | Ok, so it's probably an interaction with the modules? Without modules, it should work? | 10:56:38 |
| K900 | Yes | 10:56:58 |
| megmug | That would help since the project is early anyways, can go back to headers still | 10:57:01 |
| megmug | Thank you! | 10:57:16 |
| megmug | It's interesting though that it already works on linux | 10:57:26 |
| megmug | Also, it didn't fail immediately - the same module using stdio.h + printf works on macos | 10:58:55 |
 Randy Eckenrode | C++ modules support is fixed on staging. | 11:32:05 |
| Randy Eckenrode | https://github.com/NixOS/nixpkgs/pull/462747 | 11:32:44 |
| Randy Eckenrode | A change was made to fix clang foo.cpp that broke clang-scan-deps, which CMake uses for module support. | 11:33:50 |
| Randy Eckenrode | It had to be ported to the clang-tools wrapper, which would have gone to master if not for the large number of Linux rebuilds it caused. | 11:34:43 |
| megmug | Aha - could this possibly affect non-module projects as well then? Because I am still getting errors despite removing all the modules. clang-scan-deps fails to find some stuff (on macos). | 11:37:28 |
| Randy Eckenrode | If it uses clang-scan-deps, it will be broken. | 11:39:02 |
| Randy Eckenrode | Also clangd. | 11:39:10 |
| Randy Eckenrode | You may be able to work around it by setting env.NIX_CFLAGS_COMPILE to -isystem ${stdenv.cc.libcxx}. | 11:42:42 |
| Randy Eckenrode | * You may be able to work around it by setting env.NIX_CFLAGS_COMPILE to -isystem ${stdenv.cc.libcxx}/include/c++/v1. | 11:43:01 |
| Randy Eckenrode | (Path from memory, so may be off.) | 11:43:14 |
| megmug | Hm, or just build the nix-shell on a different version maybe? Is the change already on master branch? Or can i go back far enough to get a version that didn't have the problem? | 11:44:38 |
| Randy Eckenrode | It’s on staging. It won’t make it to master until mid-December probably. | 11:47:04 |
| Randy Eckenrode | If you use staging, you’ll have to do a stdenv bootstrap and build everything from source. | 11:47:43 |
| megmug | Do I understand correctly that the breaking change was merged on oct 9? Could it be circumvented by going back further than that? | 11:52:20 |
| megmug | On the other hand, building everything from source might not be that bad as long as it's automatic | 11:53:09 |
| Randy Eckenrode | That should also work. | 11:56:55 |
| Randy Eckenrode | It is. It just takes a while. | 11:57:18 |
| megmug | After waiting for hours to let the machine build the staging commit, i had to discover that my issue persisted. After getting a message from a teammate that the project didn't build for him on an ubuntu Windows-WSL VM, i got suspicious. I thought i had double-checked with nix-shell --pure that it would build on other machines. And i was even using ubuntu for the test. It turns out we were missing a dependency. After adding pkgs.clang-tools into the nix-shell packages, the issue was resolved for the teammate and also on the Mac! I learned that it can be really difficult to make things work across different OSes and architectures. Without Nix it would without a doubt be a lot more difficult, though. | 22:41:44 |
| megmug | BTW, K900 , everything seems to work now including modules. Maybe our use case is simple enough for the existing system to handle it, but at least some amount of module support (using clang) is apparantly there now. | 22:48:33 |
| 19 May 2021 |
|  @grahamc:nixos.org set the history visibility to "world_readable". | 19:22:35 |
