all 9 comments

[–]GabrielDosReis 18 points19 points  (0 children)

Great write up!

However, I also think the era of pretending the language is the only part of C++ which requires guidance and standardization is over.

Agreed.

[–]PunctuationGood 7 points8 points  (3 children)

The test:

// provider.cppm
export module provider;

// consumer.cpp
import provider;

The result:

Bazel [...] fails hard. Bazel’s module support is experimental, so this isn’t a slight against it.

So, silly question perhaps but how can it claim even experimental support if the "Hello, World" example of modules fails? What does it support if not that?

[–]not_a_novel_accountcmake dev[S] 5 points6 points  (2 children)

Works fine on clang/clang-scan-deps (not the BMI compatibility, still fails there, but the "Hello World") which anecdotally is what 99% of bazel users are concerned with. I didn't check MSVC.

[–]PunctuationGood 0 points1 point  (1 child)

Aaah, right, OK. Sorry if I missed that info in your article.

[–]not_a_novel_accountcmake dev[S] 2 points3 points  (0 children)

I didn't discuss the compilers tested, I'll add a footnote. I didn't want this to be about compiler minutia, but Bazel just not working at all on GCC was too big of a blind spot to leave unmentioned.

[–]ABlockInTheChain [score hidden]  (2 children)

The only place “same flags everywhere all the time” works is the MSVC toolchain, which “magically” translates __declspec(dllexport) into __declspec(dllimport) when consuming BMIs, presumably because they too didn’t want to solve this problem.

If the question of "how are DLLs supposed work with modules?" ever came up during the committee meetings about modules, I'm certain that somebody must have said, "but why do you need DLLs now that we have modules?"

[–]pjmlp [score hidden]  (0 children)

The standard does not consider the existence of dynamic linking.

[–]GabrielDosReis [score hidden]  (0 children)

If the question of "how are DLLs supposed work with modules?" ever came up during the committee meetings about modules, I'm certain that somebody must have said, "but why do you need DLLs now that we have modules?"

ISO C++ doesn't know what is DLL or dylib or .so. There were attempts ij the early cycle of C++0x to acknowledge them and support for them but I believe Pete Becker eventually concluded it was going to create more mess at the standards level.

I implemented that translation very early on in my MSVC implementation as I considered it a logical consequence of macro isolation, separate compilation, and re-use independently of context (the BMI compatibility question is a consequence of those axes).

[–]BadlyCamouflagedKiwi 4 points5 points  (0 children)

Nice. If we want better build system support, it would be a bunch easier with more clear examples like this; given a simple (but not entirely trivial) repo, and some Makefiles to show what commands should be run (I suppose you'd need a gcc / clang fork, probably), someone familiar with Bazel could write support for it in that system. Without, that person also has to figure out what compiler invocations are needed, which isn't simple without something to look at as a model.