tcbrindle / flux

A C++20 library for sequence-orientated programming
https://tristanbrindle.com/flux/
Boost Software License 1.0
472 stars 29 forks source link

Build Failure with MSVC 17.6.4 and CMake 3.27 #102

Closed DeveloperPaul123 closed 1 year ago

DeveloperPaul123 commented 1 year ago

I'm trying to build the flux library tests and benchmarks and am running into some issues with the precompiled headers. When I try to build test-libflux, I get the following output error message:

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.36.32532\modules\std.ixx(147,1): Error C1010 fatal : unexpected end of file while looking for precompiled header. Did you forget to add '#include "D:/Repositories/flux/build/test/CMakeFiles/test-libflux.dir/Debug/cmake_pch.hxx"' to your source?

But based on the documentation my understanding is that you don't need to explicitly include the pre-compiled header. Am I doing something wrong?

tcbrindle commented 1 year ago

Hi, thanks for the bug report.

It appears that when using MSBuild with the latest Visual Studio on a C++20 project, the build system now performs extra steps of scanning for module dependencies and recompiling the std.ixx and std.compat.ixx modules for each and every executable target. It look like this doesn't interact well with the way we use precompiled headers (even though I'm pretty sure we use the exact formulation recommended by the CMake docs), and so things are breaking.

(Even if the precompiled header stuff did work, this is still a really bad change -- it seems that MSBuild now wants to recompile the std.ixx module for every single executable target, and we have a lot of those in the docs/ directory! This slows things down to such an extent that it makes the already-slow MSBuild-based compilation pretty intolerable.)

Ideally, we'll find some way to disable the new module-scanning behaviour (as we're not using modules yet), and/or CMake and MSBuild will start working nicely together again when it comes to PCHs. I'll need to look into exactly what's going on though, and see if any bugs have already been reported.

In the mean time, I'd strongly recommend using the Ninja generator instead, which seems to be unaffected by the changes and will make a clean build several times faster (seconds instead of minutes for me).

If you can't use Ninja and are stuck with MSBuild, then as a short-term workaround you can disable PCH generation by commenting out (or deleting) the following lines in test/CMakeLists.txt:

https://github.com/tcbrindle/flux/blob/87b50c52b74123442e981ff1394119af9db7cf84/test/CMakeLists.txt#L90-L92

This seems to get things working again, at least for me.

tcbrindle commented 1 year ago

After a bit of searching it appears to be this Visual Studio bug. Apparently the C1010 error has been fixed in the latest preview, so hopefully things will start working again in due course.

There's also this CMake bug report

DeveloperPaul123 commented 1 year ago

Thanks for the thorough response. I can confirm that Ninja + MSVC build tools works just fine. However, Ninja with Clang 16 on windows is still failing for me. I see there was a previous PR for Clang 16 support. Was this LLVM support or clang-cl ?

tcbrindle commented 1 year ago

Clang 16 with libc++ is tested on MacOS as part of our CI, and I also test Clang 16 with libstdc++ on Linux from time to time (though I really should make that part of the CI process too).

I have to admit I haven't tried Clang on Windows. Could you file a separate issue with the build failures you're seeing, so I can see if I can get it working?

DeveloperPaul123 commented 1 year ago

Sounds good, I filed a separate issue for clang

tcbrindle commented 1 year ago

This looks to have been fixed in VS 17.7, please let me know you still have problems

DeveloperPaul123 commented 1 year ago

I can confirm that this is indeed fixed in VS 17.7 and most things build, but now I'm getting static_assert<> compile errors. I may file a new issue for this

tcbrindle commented 1 year ago

Yes, please do :)