So, you want to use C++ Modules ...cross platform - Daniela Engert - Meeting C++ 2023
Vložit
- čas přidán 5. 01. 2024
- So, you want to use C++ Modules ...cross platform - Daniela Engert - Meeting C++ 2023
Slides: slides.meetingcpp.com
Survey: survey.meetingcpp.com
If you are interested in the topic of C++ Modules you are probably aware of the fact that the implementation of modules in the three major compilers is progressing at very different speeds: msvc is mature enough to be used with modules almost everywhere, but both clang and gcc are coming along at their own pace. The same is true with build systems that support C++ Modules. MSBuild handles all kinds of module types, but most people are waiting for modules support in CMake to even consider start using them. So, let's dive into the cross-platform modules world and see what you can do today, how you can create modules with CMake, and what kind of experience you can expect.
This is not an introduction into C++ Modules, there are a couple of talks and other material available for people to learn from and familiarize themselves with the fundamental ideas. The talk will focus on the practical aspects of cross-platform support, using common tools.
We will look at Modules in general, at compilers, at build systems, and at the overall experience while visiting real code and building an application. - Věda a technologie
Fantastic, Insightful presentation on C++ modules with a review of the tooling landscape. Thanks Daniela Engert for helping the C++ community get onboard the C++ module(s) vision 😇
czcams.com/video/iMNML689qlU/video.html: the thing about modules is that there is one file only to declare and implement a module - the export keyword brings things to the user of a module. There is no module interface unit like the header file was. The drawback is that compilation is now a partially two-pass thing: first all modules need to be compiled unless they are there already as binaries and then all relying stuff is compiled. Makefile won't cut it any longer, CMake has support for it since recently (Version 3.28). And your toolchains need to be able to do dependency scans (e.g. Apple's clang 15 does not support that).
Huh. Yes we can still use separate interface and implementation files.
The only reason we scan for dependencies before starting compiling is that compiler implementers wanted to seize the opportunity to improve build time by modularizing precompilation. Think of BMIs has PCHs made modular (this is what clang did a decade ago before standardization).
manual compilation is the only option for some people and devices.
It seems like its easier to set up crosslinking with rust than modules in c++
Rust doesn't have 3 implementations. And its still early days for module implementations in C++ sadly.
It is quite easy with cargo-zig build.
@@MeetingCPPDoes rust need 3 implementations? Like, is it actually good?
Its the reality for C++ and especially for modules. Rust should have an ISO Standard too.
@@MeetingCPP I'm not paying 230 euro to get a copy of a PDF, and neither is 99.999% of people doing work with C++. The fact that ISO thing exists is inconsequential due to that fact. I'm happy to see gccrs making progress though.
About 7 minutes of hour "dont use it directly, never, its impossible, use build system", ofcourse, we are C++ programmers, we never need to use compiler directly and never understand what it does, as usualy (NO)
Modules are really big fail, just compare simple C model with
.cpp file + include path => .obj
[...obj] => result
And C++20
.cpp + include path + ??? what really, may be .cppm or .cpp or something like => .obj || .bmi
*rly no one understands what happen next, somehow with several invokes of compiler many .bmi used to create many .obj files and then linked into result*
I dont see a reason for header units, private module fragments, parts of header etc, why it is not simple 'okay, now we have module TU'
.cpp with export module it in + include path + .bmi path => .bmi
.cpp + include path + .bmi path => .obj
[...obj] => result
Also modules forces compiler to check all code for modules before to build dependency graph, its actually slows compilation (interesting behavior with preprocessor...)
Also there are problem: all C++ compilers work only with one file at once, so let we already have module maps etc, compiler compiles .cpp file, it need to know about modules. And i have 1000 instances of compiler each works with its .cpp file + ... loads all .bmi into memory??? I think its possible to optimize (on OS level with read-only files for example), but there are problem, isn't it?
First of all, C++ compilers use the C build model, so anything you say about building C++ is true for C as well.
Second, yes, tooling is awful, and I cannot for the life of me understand why toolchains in 2024 do not support aggregation of source files into one compilation unit. The same is true for C, though.
So the demands of developers need to be made clear: improve the build tools. By a lot. But that's not a fault of the language.
The BMIs don't need to be loaded entirely into memory thankfully. It contains indexes and parts are loaded lazily. That's why they decided to put the whole standard lib in just one big module for example.
But, yes, I think build systems and compilers should me more tightly coupled to avoid starting a compiler driver process for each translation unit.
clang has gotten worse and worse over the years and GCC is completely deprecated for me. I mainly use MSVC these days. Compile times are 1/3 of clang... why wait 30 seconds for clang when msvc can compile in 4 seconds?
The total opposite for me!
We officially only support Unix systems for deployment and running msvc on unix is atrociously not supported officially, which I find ridiculous considering how little is the need for a compiler to interact with the OS.
Building any sizable project with msvc on windows is slower by a factor of ten than clang or gcc on linux. It's even a hundred times slower for many open source libraries which of course all come from the unix world and whose build systems rely on fast process creation and file access. On windows, everything has to run behind a unix emulation layer. The build process has to download and build these tools. Cry when openssl has to use nasm while linux has gas as part of binutils.
Cross-compiling from linux to windows is blazingly fast, but it's impossible to guarantee msvc runtime ABI compatibility, so this excludes any proprietary dependency.
MSBuild+msvc has a long standing bug where they aren't able to properly control the number of parallel jobs, so it puts any machine to its knees, by firing too many compilations in parallel. Disable compiler-level multithreading and it gets even slower though.
MSVC is slow at generating debug information in PDB files. They tried to workaround it by firing up a RPC server process, which turns out to NOT support parallel builds of unrelated branches in CI servers. There's an unofficial/uncertain workaround hard to setup, so in our CI we just don't allow more than one windows build at a time on the same machine.
To add to the ridicule, msvc doesn't support more than 260 chars in filepaths which break many build processes, like, hard showstoppers, involving extremely ugly workarounds.
As far as I recall, that platform has always been a pain to support. They have made us loose millions in decades.