Episode Transcript
Transcripts are displayed as originally observed. Some content, including advertisements may have changed.
Use Ctrl + F to search
0:02
Episode 362 of CPPcast
0:04
with guest Daniel Ruozo, recorded
0:07
7th of June 2023. This
0:10
episode is sponsored by JetBrains, smart
0:12
ADEs to help with C++. And
0:14
Sonar, the home of clean code.
0:32
In this episode, we talk about some new blog
0:34
posts and a new C++ user interface library.
0:42
Then we are joined by Daniel Ruozo. Daniel
0:48
talks to us about his work on C++ modules. Welcome
1:01
to episode 362 of CPPcast, the
1:04
first podcast for C++ developers by C++ developers. I'm
1:08
your host, Timo Dummler, joined by
1:10
my co-host, Phil Nash. Phil, how
1:12
are you doing today?
1:13
I'm alright, Timo. How are you? I'm
1:15
not too bad. I should say, if
1:17
my audio sounds a little bit different
1:20
or less good than usual, it's because
1:22
I'm traveling, I don't have my usual mic set up with
1:24
me. I'm currently in Thessaloniki
1:27
in Greece visiting a friend. Next
1:29
week, I'm traveling from here to Varna in
1:31
Bulgaria, which is where we're going to have the committee meeting. It's
1:34
actually not very far from here at all.
1:37
And then, yeah, head back home to Finland after that.
1:40
How are you, Phil? Are you also still traveling? Or how's
1:43
it going? Well, after my trip to Norway a
1:45
couple of weeks ago, which concluded my Scandinavian
1:47
tour, I'm actually done with traveling. I've released a couple
1:49
of months now,
1:50
although I did have a holiday in August.
1:52
But apart from that and C++ on C
1:55
in a couple of weeks, which is only an hour
1:57
or so drive, but I will be staying away from home. that
2:00
I'm going to be looking forward to reminding myself what
2:02
home looks like.
2:03
All right, so at the top of every episode, I'd like
2:05
to read a piece of feedback. This time we
2:07
have a tweet by Rene Ferdinand de Rerum-Morrell
2:09
who commented on our Conan2Zero
2:12
episode that was, I believe, two episodes
2:14
ago
2:14
with Luis Carlos Campos. And
2:16
Rene said, good interview, love
2:19
the ecosystem IS mentions, smiley
2:21
face. So Rene, I'm very
2:23
happy you like the episode and actually I'm sure that
2:25
the ecosystem IS will be mentioned again today
2:28
because we are continuing our
2:30
mini series on C++ tooling, which we
2:32
started in that Conan episode. Before
2:35
we get to that, I just want to briefly mention
2:37
also that apparently there's been a bit of confusion
2:39
with the last CPP class episode,
2:41
the one with Anthony Peacock where some
2:44
people initially only saw a six minute long
2:46
audio file instead of the full episode. Phil,
2:49
can you explain what was going on there? Angle
2:52
brackets, Si, yes. For
2:57
all the issues that were all resolved, this is
2:59
a new one actually. Because I was traveling and
3:01
we had recorded the week before, but
3:04
I uploaded the episode from
3:06
the airport in Oslo
3:08
and I thought it would have gone through fine, but
3:10
apparently there was I think a processing glitch
3:13
on the host. So initially it only went
3:15
out as a six minute episode. So of course when I landed,
3:18
I corrected it, uploaded the full episode,
3:20
thought
3:20
it was all fine. Then I started getting
3:22
reports that yeah, there's only a six minute episode. And
3:25
it's another one of these things where every podcast
3:28
host or podcast, you know, redistributor,
3:31
they have their own way of caching things and clearing
3:33
things.
3:34
Some cases you just have to redownload. In
3:36
other cases I had to re-upload
3:39
or give it a new GUID.
3:40
But eventually Spotify was the the holdout
3:43
where the only way I could get Spotify to
3:45
not serve up a cached version that was only six minutes
3:47
long was to change the file name
3:50
that it was coming from. So I did that and then
3:52
it was seen to be fine. Except
3:54
that for me, and I don't know if anybody else has seen this,
3:56
I've not heard anybody else report it, I'm
3:58
not getting past episodes. showing up in my
4:00
podcast player. And every time I remove them,
4:02
it just gives me another batch. So I don't know if anybody
4:04
else has seen that. Hopefully it's just me, because
4:07
I can't see why it would be related. But if you have
4:09
seen that, do let me know. I'm not sure
4:11
there's much we can do about it at this point, but
4:13
I will investigate further. Other
4:16
than that, hopefully we're back on track. Well,
4:20
thanks, Phil. And we'd like to hear your thoughts about
4:22
the show. You can always reach out to us on Twitter
4:24
or Mastodon, or email us at feedback at
4:26
ppcast.com. Joining
4:28
us today is Daniel Ruoso. Daniel
4:31
has been working for over 20 years, working
4:33
in and around build systems and package management. He
4:36
introduced the package management system at Bloomberg
4:38
that is used today for over 10,000 C++ projects. In
4:42
the last five years, Daniel focused on static
4:44
analysis, automated refactoring, and
4:47
building consensus on engineering practice.
4:49
In the last few years, he collaborated with
4:51
the ISO C++ tooling study group to
4:53
help figure out C++ modules. Daniel,
4:56
welcome to the show.
4:57
Thank you for having me. It's a pleasure to be here for
4:59
the second time. Many of the
5:01
things on your bio we're actually going to
5:03
talk about a bit more when we get into the interview, but
5:06
the one thing that I picked up on that stood out
5:08
to me,
5:09
because I work at Sonar, do static
5:11
analysis tools, that mentioned a static analysis
5:13
got my attention. So is that something that
5:15
you are or have been doing in-house
5:17
at Bloomberg, or is it just using existing
5:19
tools?
5:20
Both. So we have
5:22
a team that is called
5:24
the STAR team, Static Analysis and
5:27
Automated Refactoring. I thought it's a nice
5:29
acronym.
5:30
And the
5:33
role that we have is to introduce
5:35
static analysis, both for
5:37
off-the-shelf tools, and we use
5:39
like Clang-Tidy and related tools.
5:42
We also use CodeQL, which
5:45
is the GitHub advanced security, and
5:47
Fortify, and a bunch of other tools. We
5:50
happen to also have some Sonar, but we're
5:52
not actually driving the Sonar analyzer
5:55
a lot. It's actually something
5:57
that we have to investigate how much overlap
5:59
there is.
5:59
with the other tools we do. But
6:02
we also have a
6:05
very dedicated effort to
6:07
building custom tools for specific
6:09
purposes. So we
6:12
have, for instance, feature
6:15
enablement library. And
6:18
so we have a custom tool that will go in,
6:21
like retire the code that's behind the
6:23
switch after the switch has been fully
6:25
rolled out and do that automatically
6:28
for the users when the
6:30
switch is set. And
6:33
also a bunch of other refactorings that we do,
6:37
mostly using Clang tools.
6:40
Yeah, a lot of interest in those custom
6:42
rules and custom refactorings at the moment.
6:44
I think we probably need better tooling to
6:47
support that, but Clang tooling is pretty
6:49
good.
6:49
Yeah, that was actually the subject
6:52
of a talk I gave back in 2019 and C++ Now. So
6:56
if anyone is interested, there is
6:58
more details. The talk is about the Clang
7:01
meta tool library that we developed
7:03
at Bloomberg. It is open source and github.com
7:06
slash Bloomberg slash Clang meta tool.
7:08
That's essentially
7:10
makes it very easy to build a small
7:12
standalone tool. And the workflow
7:14
is usually you're gonna build that small tool,
7:16
run it across your code base, be done with it
7:19
and throw it away.
7:20
Nice, we'll put a link to that in the show notes. Thanks.
7:23
All right, Daniel, we'll get more into your work in just a few minutes,
7:25
but we have a couple of news articles to talk about.
7:28
So feel free to comment on any of those, okay?
7:30
So the first one, I already kind of mentioned it briefly.
7:33
Next week is the committee meeting in Varna, Bulgaria.
7:35
So I'm very much looking forward to that. It's
7:37
gonna be our first post C++23 meeting where
7:40
we can start voting
7:42
new things into C++26.
7:45
So that's gonna be very exciting. And
7:47
yeah, I expect there's gonna be lots
7:49
of trip reports afterwards so you can see
7:52
what happened there if you haven't
7:54
had the opportunity to be there yourself. Yeah,
7:56
and I think Varna was also the one that was canceled during the
7:59
pandemic. be cancelled I seem to remember.
8:01
Yes, well there are quite a few that were cancelled
8:03
during the pandemic but that was I think the first
8:05
one that would have been
8:07
summer 2020. Yes, and then it has
8:11
been postponed multiple times and I'm very very happy
8:13
that you finally get to get to go there.
8:16
I actually have been to Tuvana myself
8:18
a few years ago on a
8:20
completely unrelated vacation trip.
8:23
So it's a really nice place. I'm very
8:25
much looking forward to being back there. I'm
8:27
jealous. I'll see you there. See you there.
8:29
Yeah. Then we have a couple of blog
8:31
posts that caught my attention this week. First
8:34
one was by my my code Christophik
8:36
and it's actually part of his series,
8:38
Modern C++ in-depth.
8:41
And the blog post is called, Is
8:43
String View Worth It? And I found that
8:45
really interesting because
8:46
it was kind of from the perspective of a large financial
8:49
data company that started using C++. Like
8:51
before the string was actually available
8:53
on the standard library.
8:55
So they developed their own string class. I'm
8:57
sure thousands of companies out
8:59
there have actually worked at one of those myself.
9:02
Music tech company that had their own string
9:05
like way before string was a thing and
9:07
obviously with different semantics.
9:10
So that's quite a common scenario I think especially
9:12
for bigger companies that have been around for longer. Yeah.
9:14
And so the article actually says well string
9:17
view can be helpful as a kind of
9:19
lingua franca. If you want to move away from char pointers
9:22
as the lingua franca you have this kind
9:24
of situation. And then it gives it really nice
9:26
overview of when and how you actually should use
9:28
the string view and when you really shouldn't.
9:31
And I thought that was a really nice overview.
9:33
It was kind of really discusses the typical
9:35
pitfalls you get with the string view. It
9:37
has reference semantics. So like a real reference
9:39
that can dangle. But
9:41
actually it's even worse than normal references.
9:44
But like if you're playing construct
9:46
and you assign a temporary object to it,
9:49
then that's going to extend the lifetime of the temporary object.
9:51
But string view doesn't actually do that.
9:54
So it's even easier to end up with kind of dangling
9:56
string views. And
9:58
yeah I thought that.
12:00
because conceptually in the C++
12:02
abstract machine, pointers are not just
12:05
integers, right? They have
12:07
an address, but they also have a provenance. And
12:10
so that kind of makes this approach
12:12
not work at all. And you have to think about this quite
12:15
differently. And while on modern platforms,
12:18
typically you have a flat memory model, but in the end it's
12:21
again, just an address, at
12:23
least at runtime. But
12:26
Raymond actually gives an example of an older architecture
12:28
like the 8026 processor where
12:30
that is actually not the case. And pointers
12:33
indeed are not just addresses, but they have like different
12:35
parts that mean different things
12:37
where kind of you need this concept in
12:39
a C++ abstract machine or provenance to actually
12:41
work with that kind of. So I thought
12:45
that was really cool and fascinating. Yeah,
12:47
it was a real trip down memory lane for me.
12:50
I did start out working with near and far
12:52
pointers on the 286
12:53
back in the day.
12:55
And I'd sort of forgotten what it liked to work with that.
12:57
But yeah, the idea that
13:00
a near pointer is
13:02
sort of within
13:03
a single 16 bit integer
13:05
jump from where you are now. You can actually
13:07
address that more quickly than something that was further away
13:09
where it needed like the two segments.
13:12
So yeah, these things did exist.
13:14
I think it's actually in the
13:17
very near future, we're starting to
13:19
go to a place where we're gonna have more exotic
13:22
architectures that we interface with as
13:24
like GPU code gets
13:27
more common and other
13:29
specialized chips. If you think
13:31
about how the RISC-V architecture is
13:33
being designed where there's all these extensions.
13:37
So I think we're actually gonna be on a point
13:39
where these kinds of subtleties
13:41
in the abstract machine are gonna become
13:44
more relevant. The
13:46
one thing that the post made me think
13:48
about was a joke that we have internally with
13:51
some coworkers that we really should
13:53
build like a troll OS
13:56
where everything that's in the standard is implemented
13:59
just like that. the ladder and then everything else
14:01
is just randomized. That's
14:03
a great idea. I actually thought about that too at some point.
14:06
You can have
14:07
11-bit bytes and all kinds of
14:09
weird stuff and the size of int
14:11
can be equal to the size of char and
14:14
all kinds of evil things. That
14:16
could be fun. I'm curious how many
14:19
library test suites would
14:22
fall apart if you do that. Let's
14:25
do it. Right. One
14:28
more thing that I want to mention is I
14:31
saw this initially on Reddit.
14:33
There was a post about a new C++ user
14:35
interface library called NUI.
14:38
There was a discussion on Reddit, but there's also GitHub
14:41
and there's also a dedicated website. That's
14:44
a new GUI library that is permissively licensed.
14:46
It has a Boost license and it lets you write
14:48
a UI in C++.
14:51
It's not cute or anything like that because
14:53
it then turns that UI into a WebView.
14:55
It's a bit more like Electron
14:58
or something like that, but you actually write the UI in
15:00
C++. My
15:02
understanding is that the C++ you write for UI
15:04
gets compiled to WebAssembly and
15:07
then rendered by WebView in a finished app.
15:10
It does use modern C++. It has quite
15:12
a few interesting features.
15:14
The author says that it still needs some
15:16
polish and features, but it's already fully usable
15:18
and documented. That currently
15:20
only Linux and Windows are supported,
15:23
but the author is hoping for a
15:25
contribution for Mac in the future. I
15:27
thought that was an interesting
15:31
approach. I'm curious
15:33
what you think about that.
15:34
I think interesting is doing a lot of work
15:37
there. Now, I will confess I haven't
15:39
actually read the article, so maybe some of this is
15:41
explained there. I
15:43
wonder what the use case for this would be
15:45
because obviously there are plenty of WebView-based
15:48
frameworks that are more JavaScript-based or
15:50
TypeScript-based.
15:51
It seems like a better fit for that sort of thing.
15:54
Of course, you're trying to
15:55
bundle in a big C++ library. That's
15:58
the only reason I can think of it. I just
16:01
think there are probably still better ways to interoperate.
16:03
But maybe there's a good use case for
16:06
it.
16:06
It also struck me as amusing
16:08
that
16:09
one reason that you would want to do this more
16:11
web-based is
16:12
for maximum cross-platform capabilities,
16:15
but it's not available in all platforms yet. Right.
16:18
Yeah, so I was actually wondering
16:21
the same thing, like what's the use case for this? Because
16:23
from what I've
16:25
seen, I would approach it the other way around, that
16:28
you often don't want to write the Go in C++, because
16:31
it's not necessarily a language that lends itself to
16:34
that. I've used Qt
16:36
and JUICE and other frameworks, and it's typically quite
16:38
painful to write a Go in C++ compared
16:41
to some
16:42
declarative approach or JavaScript
16:44
or something like that.
16:46
Particularly because as integration
16:49
with Web Asman becomes a thing, if you
16:51
have a specific part of your
16:53
UI that has a heavy computation
16:56
step,
16:56
then
16:59
you can still write that heavy computation
17:01
step in C++ and call that from
17:03
the JavaScript UI code.
17:05
Yeah. Yeah, but what I found interesting is that
17:08
in the Reddit discussion, there were lots of very
17:11
positive comments, like, oh, this is amazing, this
17:13
is great. So apparently,
17:16
there seems to be
17:18
a use case for this kind of stuff. Oh,
17:20
technically, I'm sure it is amazing. It
17:22
does sound like a very interesting
17:24
problem to be solved. I'm just not
17:26
sure. I will
17:29
claim defensive ignorance on writing
17:31
Goes. It's been
17:34
at least 20 years since I did one.
17:37
Very once. Not my area at
17:39
all. Yeah,
17:41
and it seems like if you are
17:43
writing a Go in C++, then you kind of
17:46
want it to be a native Goe rather than a Goe. But
17:49
again, maybe there is a use case here that I'm
17:52
missing. All
17:53
right, so that kind of concludes
17:55
the news articles, but I do
17:57
actually have two things on my own behalf that I...
20:00
slice of the C++ universe. So
20:03
I think the way that the industry
20:05
worked when I started,
20:08
which was like 1998, 1999, we still have very few division
20:10
of labor classes. Like
20:18
we were all playing like all the roles
20:20
all the time. And
20:23
I ended up being the
20:25
person that started putting
20:28
together like the package management. At
20:30
the time, it was not mostly C++. It
20:33
was mostly a
20:35
pearl shop.
20:36
But it still has to build
20:39
packages and create deployable
20:41
artifacts and create like a CI
20:43
CD framework of some sort.
20:46
And I ended up being the person
20:48
that solved that problem.
20:51
And that's kind of the decision
20:53
that starts pushing you in a direction
20:55
in your career. Regardless
20:58
of how much you want it or not. It's not
21:00
that I didn't want, but it's kind of like a self-guiding
21:04
process where
21:05
the more you start looking at that problem, the
21:07
more the problem becomes more complex
21:10
and the more you have to spend on it. Then
21:14
after this initial context,
21:17
I built a little automation. At the
21:19
time, we were using CVS and we were
21:21
using Debian. And so I had a little
21:23
automation that would watch the CVS repo
21:25
and whatever you changed the package, it would
21:28
rebuild the Debian package and ship
21:31
to the repo that would then get installed in
21:33
production machines.
21:34
And that actually was how I ended up
21:37
becoming a Debian developer myself
21:40
around 2004. And
21:43
that just pushed me all the way
21:45
through. I got involved into
21:49
trying to bootstrap new architectures.
21:52
I was at some point trying to build
21:54
a Debian based
21:56
on UC libc to
21:58
run in really small...
21:59
devices.
22:01
But that didn't go anywhere.
22:03
But that was a huge
22:05
introduction to the whole world of toolchains.
22:08
And then I was just lost to the world
22:10
and that was my life.
22:13
So
22:14
you said that you work at Bloomberg, but you're also on the
22:16
C++ Standards Committee.
22:19
And if you draw a Venn diagram of well-known
22:21
C++ people at Bloomberg
22:23
and people on the C++ Committee, there's quite
22:25
a big overlap.
22:26
But what is it you do
22:29
both at Bloomberg and on the committee
22:31
and is there a relation between the two?
22:33
There is. So I joined Bloomberg
22:36
in February 2011, so 12
22:38
years ago at this point.
22:42
And one of the very few,
22:44
well, not the very first, but
22:46
one of the first projects I worked with was
22:49
actually, again, introducing automation to
22:51
getting package management and builds
22:54
and ironically,
22:58
not ironically, but funnily enough, also
23:00
based on the Debian packaging system. So I
23:02
was back to 1999,
23:05
building the same thing at Bloomberg,
23:07
but now with sandboxing and a bunch
23:09
of other things and supporting C++.
23:11
And it was
23:12
only around 2019
23:18
that
23:19
I started to be more
23:21
interested in the C++
23:24
Standard Committee work
23:26
because I was honestly scared
23:29
of the direction of modules
23:32
because they seemed somewhat
23:34
incompatible with the way that we built
23:37
code. So in
23:40
the early experiences,
23:42
a lot of the discussions that happened in
23:45
the context of defining how modules are going
23:47
to work were heavily influenced by organizations
23:50
with what I call like heavily regulated
23:52
build systems or mono repos.
23:56
And the requirements of those organizations
23:58
are profoundly different. friend than
24:01
the requirements of organizations like Bloomberg,
24:03
where we have an open-ended package-based
24:06
build system where you don't
24:10
see the source of the other package. You just
24:12
see files on disk that
24:14
were produced by the build process. And
24:17
that's the only interface you have.
24:19
And the different projects could
24:22
be using entirely different build systems.
24:24
And in our case, sometimes they do. It's often
24:26
that they do.
24:28
So
24:30
it was clear to me that we had a huge gap
24:33
to get to a point where we could
24:35
have a cons project and a CMake
24:37
project
24:39
in the C++ ecosystem with modules
24:41
and everything worked.
24:44
And that's what pushed me into
24:46
the work in
24:47
the C++ standard committee
24:51
and later what pushed
24:53
Bloomberg to start funding
24:55
it where to work on
24:58
the implementation of modules to drive
25:00
a vision where our
25:03
universe at Bloomberg actually could work
25:05
with modules. In a way, our
25:08
biggest fear at the time is that we would have a
25:10
big fork of the C++ ecosystem,
25:13
where you would have some parts of
25:15
the ecosystem that could use modules and
25:17
some parts of the ecosystem that couldn't. And
25:20
now either you are in these
25:22
companies that have this huge monorepos and
25:24
module work for them or
25:26
you're not. And then there's a bunch of open
25:28
source libraries that you can't use. So
25:31
that was our biggest fear. Right.
25:34
So let's talk about modules. We
25:36
can get into the specific
25:38
problems maybe in a
25:40
second. But let me zoom out
25:43
and ask a very general question
25:45
that I think quite a lot of people are asking
25:47
themselves these days. So
25:50
we have modules in the standards in C++ 20. So
25:52
it's been three years now. They're
25:54
still not widely used in the
25:56
C++ community. If you
25:58
go and get like. or whatever
26:00
library it might even be using
26:02
very modern C++, but it's going to be a header or
26:05
it's going to be header and source
26:06
or something. It's not going to
26:08
be a module, right? And so you
26:11
don't really see modules really
26:14
being widely used in the C++ community. And
26:16
I'm just curious why that is? Like what's
26:19
the actual challenge there? And did
26:21
we as a committee get them wrong? Like what
26:24
do you think is kind of the main issue
26:26
there? Like why do we not see them
26:28
in the wild? So
26:30
I want to focus on named
26:32
modules first because named modules
26:35
are something a lot easier to talk
26:37
about than we can get into
26:40
importable headers or header units later. But
26:43
can you maybe quickly for our
26:45
listeners can you say what named modules
26:47
are? Yeah, so
26:49
named modules are what you see, what
26:52
you would expect to say import std.
26:56
So you say std without angle brackets,
26:58
without quotes, you're there is this
27:00
new namespace of
27:03
like module lookup.
27:04
So this is an entirely new
27:07
avenue of how things are named in C++
27:09
because C++ doesn't have enough types of
27:12
namespaces.
27:13
And the
27:14
idea is, and
27:17
the main distinction between a named module and a
27:19
header unit is the import
27:22
statement cannot affect
27:25
the state of the preprocessor. But
27:28
all the entities that were exported
27:31
from that module are
27:33
now reachable to
27:35
the translation unit that did the import.
27:38
What does that mean in practice? Right,
27:40
so if I have a file that's like module
27:42
blah, and then export this, export
27:44
that, and then in another file, I say, import
27:47
blah, then that's what you're talking about.
27:49
That's what name modules are. Yeah,
27:51
and, and so what
27:54
the reason why they're called named modules is
27:56
because the compiler has this new
27:58
namespace, which is
27:59
like the module name lookup.
28:02
And then you can tell the compiler for
28:05
module blah, you
28:07
can take the pre-built module
28:09
interface from this location. And
28:14
the distinction from that
28:16
to importable headers or header units
28:19
is primarily that,
28:22
one, you don't have this new namespace. When
28:25
you say import angle
28:28
bracket IO stream, you're
28:31
essentially doing the same, you're
28:34
supposedly doing the same lookup as
28:37
you would do with the include statement.
28:41
But we don't really have
28:43
a concept of identity of headers. Oh,
28:46
is that also why you can't standardize pragma
28:49
once, even though everybody's using it? Yeah,
28:53
that is exactly the reason. Once
28:56
what? We
28:58
barely acknowledge in the standard that the things
29:00
are in files. How can we even
29:02
define that they're the same file?
29:04
What is a file? And
29:07
so that's the first challenge. So if
29:10
I have to give the compiler the pre-built
29:14
module interface
29:18
or the built module interface, we use the acronym
29:20
BMI all the time,
29:22
saying this header
29:25
unit is in this location. What
29:28
is it to tell that this is going to be
29:30
coming from the same source that
29:33
is what the compiler would have seen if
29:35
it was doing an include? There's
29:39
nothing to say this. And for the user, I
29:41
think this is going to be very challenging. And
29:44
the second part is the
29:47
compiler is allowed to
29:50
replace any pound include
29:53
by the equivalent import transparently,
29:58
which means that. The
30:01
way that a particular piece of code is
30:04
understood by the compiler
30:06
can be drastically different
30:09
if you allow the compiler to do the source
30:11
inclusion or if now
30:14
you're saying take this BMI instead.
30:17
So that's the main difference and I think
30:20
we kind of stepped ahead a bit on
30:22
the discussion, but
30:23
that's the main thing that's the
30:26
biggest challenge for header units
30:28
and there's
30:30
a lot of additional problems
30:32
in the tooling space that come
30:34
because of it. Right,
30:37
so let's rewind maybe and start with
30:39
the name modules. So you say that
30:41
those are actually a lot more straightforward,
30:45
but those are also not really
30:47
widely adopted yet. So
30:52
the main thing is there
30:54
is a gigantic
30:57
shift that happens when
31:00
it comes to the adoption of C++ modules
31:03
in the tooling ecosystem. We
31:06
like to use this term called, this
31:08
term embarrassingly parallel when
31:11
we talk about C++ build systems because
31:14
up to
31:17
modules, the order
31:19
at which you translated individual
31:22
units was irrelevant.
31:26
There were no dependencies across
31:28
translation units. There were dependencies
31:31
from translation units to source
31:33
files that were included. The
31:37
traditional way that this is implemented is
31:41
you have the
31:43
first translation
31:47
generate a dependency file
31:50
that gets read by the build system when it's
31:52
available and that tells
31:54
the build system when
31:56
an incremental build of that translation
31:59
unit is necessary.
32:01
So this is how C and
32:03
C++
32:05
build systems have worked forever.
32:07
Now, when we get
32:09
to modules, we have
32:12
a significant change
32:15
in which not only
32:17
the order of translation
32:20
units is now relevant, but
32:23
we have a new type of relationship
32:26
between translation units. So
32:28
before we had only one kind of
32:30
translation unit relationship, which
32:33
was linkage.
32:34
So we only had EBI relationship
32:36
between different translation units.
32:38
Either you built your
32:41
objects coherently and everything should
32:43
work, or you built your objects incoherently
32:45
and you're going to have an ODR violation,
32:48
which hopefully fails at link time,
32:50
but most likely will just sag fault in production.
32:55
With built module interfaces,
32:57
you have this new import relationship
33:00
where in order to translate this
33:03
particular unit, you need to
33:05
have translated the module being
33:07
imported beforehand. Right?
33:10
So now you need the build system to topologically
33:12
sort all the translation
33:15
units in order to
33:18
build them in the right order, because
33:20
otherwise they just can't build it, which is fail
33:22
saying, hey, I
33:25
can't find this module.
33:30
I can't compile this translation unit. Yeah.
33:32
But isn't this like the whole point of modules? Like in
33:35
pre-modules, you can do like hash
33:37
include vector in like
33:40
your 2000 different source files,
33:42
and then you're going to be parsing and compiling
33:44
header vector 2000 times. Right? And
33:47
then you throw it all out again when you link. And so you just
33:49
don't want to spend all of those resources on recompiling
33:51
the same stuff over and over again. You want to
33:54
compile it once and then we use it. So
33:56
this whole, this relationship, that's kind of the whole point, right?
33:58
That's what you want. Yeah. And
34:01
conceptually, it's all great. It's just for
34:05
this to work,
34:07
there is a lot of steps in
34:10
converging how build systems work. For
34:13
instance, how
34:16
do we know the order in
34:18
which the translations have to happen? Which
34:21
means that now we need a dependency
34:24
scanning step before
34:26
the build even starts, because the build
34:29
needs to know what modules are where
34:31
and which modules depend on what modules.
34:34
And so there has been a long
34:37
process of figuring out,
34:40
so now we have this extra dependency
34:43
scanning. What is the output of this dependency scanning?
34:45
Great, so now we have a common
34:48
output format for the dependency scanning.
34:51
Now let's figure out how there
34:54
is, it was a paper that
34:56
Kitware wrote back in 2020, I think,
35:00
that essentially describes
35:03
the output format for the dependency
35:05
scanning that will say, this source
35:07
file provides
35:10
this named module and requires
35:12
this other named modules. Oh, is it
35:14
this JSON format that I
35:17
think CMake now supports? I
35:19
think the three major compilers
35:21
are supposed to support it now, I
35:23
guess. GCC is almost
35:25
there, I think. There is
35:28
a patch that Kitware is
35:32
pushing upstream on this.
35:34
But the reality is
35:36
it's only
35:38
last year that
35:40
we got all the compilers, or at least
35:42
a MSPC and Clang and a patch GCC
35:45
to produce this format.
35:48
And this doesn't even
35:50
work with
35:54
header units on GCC.
35:56
Because, and we'll
35:58
go back to header units.
35:59
I'm very aggravated about header
36:02
units. So let's say I named modules
36:04
for now. Now
36:07
that we converged on the dependency
36:09
scanning step, and then we had a second problem,
36:12
which is, so
36:14
CMake generates a build system in Ninja,
36:17
but Ninja didn't support
36:20
dynamically adding dependency nodes
36:25
between translation units, between
36:28
like build nodes, right?
36:30
You couldn't add dependency
36:32
edges between nodes dynamically
36:34
as part of the build.
36:36
And it turns out that Kitware
36:39
had a fork of Ninja since a long time ago,
36:41
because that was required for Fortune modules,
36:44
because C++ modules is heavily
36:46
inspired by Fortune modules. And
36:49
it was only when it became
36:52
clear that this was a requirement for C++, that
36:54
Ninja upstream finally accepted
36:56
the patch. And so CMake could generate
36:58
a Ninja, like a Ninja that worked upstream
37:02
to support building
37:04
modules in the right order.
37:07
And so it has just been
37:09
this very long
37:11
process of getting the tools in place.
37:14
And even if
37:16
we are confident that
37:18
with the work that Bloomberg
37:20
is helping fund with Kitware,
37:23
that by the end of this year, if
37:25
you have a CMake project and you
37:28
want to use modules
37:30
internally to that project,
37:32
it's going to be like a viable solution.
37:35
Or if you have like a multi-project, like integrated
37:37
CMake build where everything is in the same
37:39
CMake project, kind of like sub-module style,
37:42
that
37:42
this is likely
37:44
going to work. Or even with
37:47
export files, as long as you're careful
37:49
about making the flags
37:52
close enough.
37:54
Because here comes the other challenge of modules,
37:57
which is the
37:58
implementation
37:59
of the built module interface and
38:02
how that gets imported
38:04
actually had its roots
38:07
in precompiled headers,
38:11
which means that this
38:13
new interface, this new relationship
38:15
of like the importing translation unit is
38:19
actually driven from the
38:21
performance of the import statement
38:24
rather than the interoperability
38:27
of the tooling. What
38:30
does that mean? What I
38:32
mean is while different
38:36
objects produced by
38:39
different compilers, as
38:41
long as they use the same standard library
38:44
in API compatible ways, can
38:46
be linked together.
38:48
If you have a BMI that
38:50
was produced by Clang
38:53
14, and you want to import it from GCC,
38:55
it's just not going to work at all.
38:59
It's even worse. If
39:02
you have a BMI produced by Clang 14, and you
39:04
want to import in
39:06
a translation unit that you're using
39:08
Clang 15, that's not going to work. Because
39:11
the import process is actually
39:13
doing like randomized like mem
39:16
map, mem copy kind of
39:18
things to make the import really,
39:21
really fast. But
39:23
it gets even worse, because
39:25
specific flags, even if you're using exactly
39:27
the same compiler, will change
39:30
the way that the abstract syntax tree is constructed,
39:33
which means that the BMI is not going to
39:35
be useful. So let's say
39:37
you have a library that was built with
39:40
standard C++ 20. And then you have your
39:42
translation unit building with C++ 2023,
39:45
the
39:46
BMI is not going to be usable.
39:50
And so that's the second challenge that we have
39:52
been working through. And we kind
39:54
of have a consensus
39:56
of the idea that
39:58
the compiler needs to add
39:59
advertise kind
40:02
of like an opaque hash
40:04
token describing
40:06
what is the compatibility of this BMI.
40:10
And then you can ask the compiler
40:12
doing the import, what is the compatibility
40:14
of its BMIs. And
40:16
essentially, in
40:19
a way, you kind of have to build
40:21
in the most pessimistic way possible,
40:25
as if every translation unit doing
40:27
an import needs its own build
40:29
of every module that it needs transitively.
40:33
And then just hope that the deduplication
40:36
across those translation units is
40:38
actually going to get you a better performance.
40:41
Because if we don't do that, what
40:44
ends up happening is your
40:46
build system starts working, and then suddenly
40:49
you just get a compilation failure saying,
40:52
you chose the wrong flags, that's
40:54
too bad. Sounds fun. But
40:57
again, we're almost there.
40:59
Does all of this imply that we actually got it wrong
41:02
when we
41:03
standardized modules in the first place?
41:05
I don't think we got it wrong.
41:07
I think
41:10
the main thing is
41:13
a lot of
41:15
the challenges would have
41:17
been significantly easier
41:19
if we
41:20
had done packaging before modules.
41:23
Because
41:24
a lot of the things that we spent
41:26
a year talking about in
41:28
SG15 was, how do I
41:32
ship a pre-built library with modules?
41:37
How does that look like? What are the files on
41:39
this? How can CMake
41:43
import a library that
41:44
has modules that were
41:46
built in scons? And
41:50
we have been slowly working
41:53
through it, and we have a general mental
41:55
model of how that should work. And
41:57
now it's a simple matter of programming to
41:59
get seen.
41:59
make to actually implement all of that.
42:02
But I don't
42:04
think it was,
42:06
from a language perspective,
42:09
I think modules are fine. Named
42:11
modules are fine. I
42:13
think it's just there was a general
42:17
underestimating
42:19
of the impact
42:20
that it would have in the tooling
42:23
space.
42:24
And for that reason,
42:26
the effort
42:29
required to make it work is significantly
42:32
higher than
42:33
most people expect.
42:36
GCC has had the module
42:38
support
42:39
since GCC 10, I think.
42:41
But
42:42
the tooling to make it usable
42:45
is just not there yet.
42:47
Well, I know you want to get on to talk about
42:49
importable headers
42:51
and heading units. But before
42:53
we do that, it's a good time to take a little
42:55
break.
42:56
And while we're talking about the sorry status C++,
42:59
it's a great time to talk
43:02
about Sonar, the home of CleanCode,
43:04
a sponsor for this episode. So
43:06
SonarLint is a free plugin for your IDE.
43:09
It helps to find and fix bugs and security
43:11
issues from the moment you start writing code.
43:14
You can also add SonarCube or SonarCloud to
43:16
extend your CI CD pipeline.
43:18
And it will enable your whole team to deliver clean code
43:20
consistently and efficiently on
43:23
every check-in or pull request. SonarCloud
43:25
is completely free for open source projects
43:28
and integrates with all of the cloud DevOps platforms.
43:32
All right, Daniel. So let's talk about importable
43:34
headers. So you recently
43:37
wrote a paper, P2898, saying
43:39
that importable headers are not universally
43:41
implementable.
43:43
And you also had a talk at C++ now a few
43:45
weeks ago, which was a great talk, by the way,
43:47
about the challenges of implementing
43:49
header units. First of all, apologies
43:52
if that's a stupid question, but are importable
43:55
headers and header units the same thing?
43:58
It's not a stupid question. all, like naming
44:01
things is really hard.
44:03
But it's essentially talking about
44:06
similar things just on different levels
44:08
of abstraction. When the standard
44:10
talk about importable headers, it's
44:13
talking about the
44:15
header in the abstract from the perspective
44:17
of how the
44:20
compiler should
44:23
think about the semantics
44:25
of the importation process. And
44:27
when we talk about header units, we're talking about
44:30
how the build system needs to think about
44:32
it in terms of the fact that
44:34
there is now one more node in the build
44:36
graph to produce that header as
44:39
a translation unit. And that's what we call a header
44:41
unit.
44:42
So it's
44:44
a very similar thing just talking about them
44:46
in different layers of abstraction, because
44:49
the header unit is the translation of an importable
44:52
header. All right. All right. And
44:54
so when you say they're not universally implementable,
44:57
like what does that mean? And how bad is it?
45:00
And can you fix it? So
45:02
let me
45:05
start by talking about what universal
45:07
means.
45:10
And this goes back to the conversation about
45:13
how the conversation about modules
45:15
in the beginning was very focused
45:17
on specific environments that, again,
45:19
what I call the highly regulated
45:22
environments.
45:23
And the main difference is that
45:25
those environments tend to have very
45:28
elaborate and powerful build systems,
45:31
where adding new nodes
45:33
to the build graph during
45:36
the build itself is a normal
45:38
thing to do.
45:39
But when we consider the C++ ecosystem
45:42
as a whole, then
45:45
we have to consider that POSIX
45:47
make is a part of the C++
45:50
ecosystem. Right.
45:52
And while it is
45:54
possible to get named modules to
45:57
work in POSIX make and it's
46:00
definitely not going to be the case that you're going to be
46:02
manually editing those make files, like
46:05
that part is gone.
46:07
But from the perspective of
46:09
the tooling ecosystem, it's
46:12
still possible to write for
46:15
CMake, for instance, to
46:17
generate POSIX make files
46:21
that will be able to build a
46:23
system using named modules. And
46:26
the reason for that is that you have
46:28
the dependency scanning process
46:32
happens before everything else. And
46:34
that's a requirement in all cases. But
46:39
as I was talking before, in the
46:42
case of named modules, the
46:45
import statement is not allowed
46:47
to affect the state
46:49
of the preprocessor at the time of the import,
46:53
which means that you can look at a translation
46:55
unit in isolation,
46:58
and you're going to find all the edges
47:00
that this translation unit has in terms
47:02
of dependencies. And it doesn't
47:05
matter that they're dangling at the time
47:07
of the dependency scan, because
47:09
you can do the dependency scan in
47:12
an embarrassingly parallel step.
47:15
And then collate all
47:17
that data into a coherent build graph
47:19
and it works. The
47:21
import with importable headers,
47:23
on the other hand, the import statement,
47:27
or the transparent rewriting
47:29
of a pound include into an import by the compiler,
47:32
which is allowed by the standard, is
47:36
allowed to influence the state of the preprocessor.
47:39
What does that mean? It means that
47:42
if we are
47:44
doing a header import,
47:47
and we are saying
47:49
that the translation of the header unit happens
47:52
independently from this translation
47:54
unit, it means that
47:57
I can't just pretend
47:59
that the source inclusion is equivalent
48:02
to the import. Because
48:04
if I have something in my preprocessor
48:07
state that would result in that
48:09
header being interpreted in a different
48:11
way, then if it was
48:14
being imported to standalone, I
48:16
will end up with an incoherent build. The
48:21
end result of that thought process is
48:25
that the list of header units
48:28
become a dependency of
48:31
the dependency scanning process itself.
48:36
So we need to know all the list
48:38
of all importable headers before
48:41
we read any file. But
48:45
it gets worse than that. Because
48:47
as we translate the header unit independently,
48:51
that header unit needs its own
48:53
compiler flags. And the compiler
48:56
flags of the header unit are not necessarily
48:58
the same as the compiler flag
49:00
of the translation unit doing the import.
49:03
In fact, this is very
49:05
much a desired outcome. One
49:07
of the things that we want is to be able to isolate
49:10
the preprocessor flags such that everyone
49:12
sees IOStream the same way.
49:17
On the other hand, that
49:19
means that I need to know what are
49:21
the compiler flags for
49:24
IOStream before I do
49:26
the dependency scanning, and
49:28
that the dependency scanning now needs to
49:30
emulate what the import
49:32
process will do. What does that
49:35
emulation looks like is the
49:38
preprocessor stops at
49:40
the point of the import, starts
49:42
a new preprocessor context informed
49:45
by the compile command of the
49:47
header unit that's going to be translated later,
49:50
processes that header unit,
49:53
gets this in the final state
49:55
of the preprocessor at that point, and
49:57
merges it back into. the
50:00
original preprocessor state. So
50:03
that's what's necessary to correctly
50:05
do the dependency scanning with header
50:07
units. The
50:10
end result of that is that the list
50:12
of all header units and all
50:15
the arguments through all
50:17
the header units
50:19
is now a dependency
50:21
of the dependency scanning process itself. Consequently,
50:25
any change through
50:29
any one of those things, through the list
50:31
of header units, either adding a new header unit
50:33
or removing a header unit,
50:35
or the changes to the arguments
50:38
of how those header units are translated,
50:40
effectively invalidates the entire
50:42
bill.
50:44
Because with POSIX Make, if a
50:46
target gets invalidated,
50:49
it's over. The bill
50:51
plan goes all the way through. A
50:55
workaround for that is
50:57
that in the case of Ninja, for instance,
50:59
you can use the Restat option on
51:02
that target and say, OK,
51:04
if the dependency scanning ran and
51:07
the output of the dependency scanning is the same,
51:10
just don't essentially
51:12
write through an intermediary file
51:16
and then have the final file depend
51:18
on the intermediate file with
51:20
the Restat option, but only
51:22
copy it over if the contents are
51:24
different.
51:25
And then Ninja can stop
51:27
the invalidation after that.
51:30
Or in the case of SCONS, where
51:32
you have checksum-based invalidations,
51:36
so if the dependency scanning produces the same
51:39
checksum, again, the invalidation
51:42
stops.
51:43
But in the case of POSIX Make, that's not
51:45
how it works. The moment
51:47
that you invalidate a rule,
51:50
all downstream rules are automatically
51:52
invalidated. So what
51:55
does that mean? It can mean two things. It can
51:58
mean one. that
52:01
module header units should
52:04
not be used because
52:07
it's unusable in environments
52:10
where C++ is used today. Or
52:13
it means that we're declaring,
52:17
like Michael Scott style, that
52:21
Canoe, POSIX make is no longer
52:25
a valid part of the C++ ecosystem.
52:28
And it may
52:31
be that we get to that point, but
52:34
my main concern has been that
52:37
we have been driving this conversation
52:40
in a very implicit way as saying
52:43
like, oh, the standard requires this, therefore
52:45
the standard is right. Therefore it
52:47
doesn't matter what the cost is.
52:49
And the thing that I want us to
52:51
be explicit about is
52:53
if we're saying that we wanna commit the
52:55
true width in the standard, then
52:58
we're explicitly saying, fine, like
53:01
we're explicitly choosing to say,
53:03
POSIX make is no longer a valid C++
53:06
build system driver. I
53:10
personally think it's weird for us to make that choice,
53:12
but I'm not gonna hold everyone back
53:15
if that's where the consensus is going.
53:18
This definitely brings to mind that quote, and I
53:20
used it in a talk just recently.
53:23
No plan survives first contact with the enemy.
53:26
I think that's definitely what we're seeing with modules is spending
53:29
years
53:29
specifying it.
53:31
And then when we actually try to use it,
53:33
then we hit all these rafts of
53:36
unexpected consequences I think that we're still
53:38
working through. So I
53:39
wanna thank you for your part in
53:42
trying to make sense of all this
53:43
and even do something about it. Thank
53:46
you for recognizing the
53:48
pain so far. We
53:51
definitely need to get somewhere with it.
53:54
I actually wanna switch gears a little bit because we
53:57
didn't have a lot of time left and there's
53:59
another bit.
53:59
that we want to get into.
54:01
So just taking a step back and
54:03
talking about SG15, the tolling
54:05
study group, because you're
54:08
quite a central member of that group.
54:10
Can you talk about the group and what they do?
54:13
So the main thing,
54:15
it's
54:17
a bit of a weird thing and
54:19
it has been weird for a while, but I think we're now finding
54:22
a different way of framing it
54:24
because I remember
54:26
in CPPCon 2021, there
54:30
was a panel with the like
54:33
members, like chairs of the standard committee.
54:36
And there
54:38
were quite a few questions. I asked a
54:40
similar question of if WG21
54:43
doesn't think that like ecosystem
54:47
is something that they should be interested
54:50
in as like, not as individuals,
54:53
but for WG21 to be
54:56
interested in the ecosystem and as a whole
54:58
and not just
54:59
the semantics of the language itself.
55:02
And at the time there was a
55:05
surprising yet very clarifying
55:07
answer that there was a sentiment
55:10
that this is out of scope for WG21. That
55:13
WG21 was meant to work on like
55:16
the language itself
55:18
and that the ecosystem was not part of the scope.
55:20
Since then,
55:23
there have been number of conversations
55:25
with various people and
55:27
in Kona last year,
55:29
October, I think, Kona
55:33
Hawaii was the meeting
55:36
where the idea of
55:39
ecosystem IS came
55:42
around. And I think
55:45
there has been a substantive
55:47
shift on how like
55:50
the WG21 chairs
55:52
think about this problem and
55:54
there is a consensus
55:56
building
55:57
that driving the ecosystem as
55:59
a whole. whole, not just the semantics of the
56:01
language itself, is and
56:04
should be part of the WG21 scope.
56:07
And it was one of the most expressive,
56:10
like positive votes in the
56:13
room in Kona, where
56:15
there was this realization that, yes,
56:19
we need to work to consolidate how
56:21
the ecosystem is driving because the
56:24
amount of divergence we have and
56:27
most of the time unnecessary divergence
56:30
is hurting the ecosystem a lot. So
56:34
what is the scope of this ecosystem
56:36
IS? For example, the
56:39
JSON file that we mentioned earlier
56:41
that describes the dependencies of the modules, is that
56:43
something that would be standardized in there? And
56:46
what else could be part of this new standard?
56:49
So the basic framework where this
56:51
was presented is a
56:54
framework of interoperability. So
56:57
we're not trying to specify what
57:00
is the standard build system for C++. What
57:04
is standardizing management? We're not standardizing C, basically. Right.
57:07
That's not the goal. Like we are profoundly
57:09
aware that this would not only fail
57:13
catastrophically to actually
57:17
be standardized, it would actually
57:19
be profoundly damaging to the
57:21
ecosystem to commit to a single build
57:23
system. But
57:26
what is important is that is
57:28
for us to be able to say, hey, I
57:30
have a CMake project, you have a Scons
57:33
project, maybe we should be able
57:35
to share code. Right. Like
57:37
I should be able to ship you a library and
57:39
you should be able to import
57:42
my library into your build system. Right.
57:45
Like that's not if you
57:48
I think we have a bit of like a Stockholm
57:50
syndrome thing with the C++ ecosystem
57:54
where we just accept that this is how things
57:56
are. But if you explain
57:59
this to anyone.
57:59
that hasn't been in this ecosystem
58:02
for long,
58:03
they will look at us like we're crazy. And it's like,
58:06
how is this still a problem in
58:08
your ecosystem? Every
58:10
other ecosystem has dissolved. Yes,
58:12
I've experienced this where people that were actually new
58:15
to C++, they were like, OK, so I need this library.
58:18
How do I use it?
58:21
Which command do I need to type to download
58:23
and install this library and
58:26
link against it and everything? And then you have
58:28
to go and say, well, that's
58:30
not really a thing. You have to actually get
58:33
the source. And then it depends on the build system,
58:35
how you compile it. And then
58:38
you get into this mess. And as you say, everybody
58:40
looks at this and says, this is crazy. How
58:43
can you get any work done if this is how
58:45
your ecosystem works?
58:47
If you come from Rust
58:49
or Python or anything like that.
58:52
But the reality is that a lot of the
58:54
C++ shops, they
58:56
have solved this problem internally.
58:59
We have a package management
59:02
ecosystem with more than 10,000 C++ projects.
59:06
And if you're at Bloomberg as
59:08
a C++ developer writing a library, you
59:10
know exactly what you have to do.
59:12
And if you're consuming someone else's library, you know
59:14
exactly what you have to do. Same
59:17
thing is true for Google. At Google, they have
59:19
their Blaze build system.
59:22
And if you want to consume a library, you
59:24
would know exactly what you're going to do. And
59:27
if you want to ship a library, you also
59:29
know exactly what you're going to do. And
59:31
it's also not entirely broken
59:33
in some ecosystems, like GNU
59:36
Linux distributions. If you commit
59:38
to
59:39
a specific Linux distribution,
59:41
you actually have a fairly
59:44
reasonable way to specify
59:46
things. Like you know how you depend on the library.
59:49
You know how you
59:50
ship a library. And if you commit to that
59:52
ecosystem, it kind of works.
59:55
And we now also have things like VC
59:57
package. And as we discussed a few episodes ago.
1:00:00
we have Conan. Yeah, and
1:00:02
those are starting
1:00:05
to create specialized ecosystems
1:00:07
where people have been
1:00:10
able to reduce this
1:00:12
kind of divergence. But we
1:00:15
are now at this, again, I talked
1:00:17
before about bifurcating the ecosystem.
1:00:21
And we're kind of this in this point
1:00:23
where, well, I'm in
1:00:25
Conan, but this
1:00:27
library I need doesn't have a Conan file.
1:00:31
So maybe I can't use that library.
1:00:34
Or I need to become a Conan expert to
1:00:37
be able to figure out how to package
1:00:39
a third-party library that
1:00:42
I barely know how it builds. So
1:00:45
it seems like that hasn't actually solved the problem, which
1:00:47
bumps it one level up, right?
1:00:50
It just makes it more affordable to the
1:00:53
people where it was completely unaffordable before
1:00:56
without actually solving the problem. So
1:00:58
what we're doing is essentially finding a bunch
1:01:00
of local maxima. And
1:01:03
some local maxima have a lot of investment.
1:01:05
Bloomberg has a lot
1:01:08
of people working in the packaging system
1:01:11
on the build orchestration, on making
1:01:13
sure everything is coherent, making sure all
1:01:16
of that.
1:01:16
And then you have small organizations
1:01:19
that can't afford that.
1:01:20
And so they will find whatever is the local
1:01:22
maxima that works for them.
1:01:25
But I think
1:01:29
the thing that we're hoping for is
1:01:31
that we can break through that local
1:01:36
maxima via interoperability.
1:01:39
So let's imagine a world
1:01:42
where a build, a C++ project,
1:01:46
describes in an automatable
1:01:49
way the steps for its build,
1:01:52
which dependencies it has. How
1:01:54
do you look up dependencies? So
1:01:57
we don't need everyone to converge on the same package.
1:02:00
manager, we don't need everyone to converge on the
1:02:02
same build system. We
1:02:03
just need to find which languages
1:02:05
we're missing to
1:02:07
allow this interoperability
1:02:10
to happen today. And so that's what
1:02:12
you're going to put into this or what you're, what you're
1:02:14
aiming to put into this ecosystem international
1:02:17
standard that's being developed.
1:02:19
That is the goal. Yeah. It's just build
1:02:22
interoperability. Like one of
1:02:24
the first things that is being discussed and,
1:02:27
uh, to be fair, like I've, I'm
1:02:30
still focusing mostly on modules. I'm not
1:02:33
like really testing a lot of effort in
1:02:35
that right now, but one of the first
1:02:37
things that is being discussed is an introspection
1:02:41
mechanism where you can ask where
1:02:43
you like your tool chain or your. Cooling
1:02:46
environment. What are
1:02:48
the capabilities of your tooling environment
1:02:51
in regards to the specified
1:02:54
interoperability languages?
1:02:57
Because then see make can go and say like, oh, this package manager
1:02:59
supports
1:03:01
this format I can go and ask for what libraries are
1:03:03
installed in the system. And what modules
1:03:05
come with those libraries in an interoperable
1:03:07
way.
1:03:13
So
1:03:13
we might finally get something richer than the compilation database. Yeah.
1:03:17
Uh, the compilation, it's a very good example. It's something
1:03:20
that has been profoundly profoundly useful,
1:03:22
but everyone that seriously
1:03:25
interacts with it knows
1:03:27
just how painful it is to try and like extract
1:03:30
semantics out of the compile commands.
1:03:33
Uh,
1:03:34
like in the case of Bloomberg, we have
1:03:36
legacy environments and we run clean tooling
1:03:39
on the legacy environment. So
1:03:41
we have a bunch of code that just, Oh,
1:03:43
I recognize the semantics
1:03:45
of this particular compiler.
1:03:49
Let me rewrite this compilation command
1:03:51
into like a clean, like a clean equivalent
1:03:54
of whatever this compiler was doing.
1:03:56
So we need to like raise the semantics
1:03:59
from. dash capital Y into
1:04:02
more structured data. Like what
1:04:05
do we mean by this for
1:04:07
the compiler to be doing? Well,
1:04:10
we are running long again.
1:04:12
We didn't really get to ask you any more personal
1:04:14
questions. So just very, very quickly,
1:04:16
if you could say one other thing that we haven't
1:04:18
talked about so far in the world of C++ that you
1:04:21
find interesting or exciting, what would it be?
1:04:24
Oh, I know I've
1:04:26
been so sucked into like the tooling world
1:04:29
that I
1:04:32
don't even know. Well,
1:04:34
to be fair, you're actually working on some pretty interesting,
1:04:36
exciting stuff there.
1:04:38
So we'll give you a pass on that one.
1:04:41
But anything else that you do wanna tell us
1:04:43
though?
1:04:44
Anything you wanna let our listeners know before
1:04:46
we wrap up?
1:04:49
Just if you're a
1:04:51
person that is like tooling inclined,
1:04:55
we do have a lot of work
1:04:57
to get to the tooling ecosystem
1:05:02
international specification. So
1:05:05
this is all work. It will take
1:05:07
effort. And we
1:05:10
need people to actually come in and
1:05:12
chip in on figuring stuff
1:05:14
out. There's a lot of stuff to be figured out.
1:05:17
And if people don't come in to
1:05:19
join the effort, it's just gonna take longer.
1:05:22
And hopefully we're gonna be motivated five
1:05:24
years from now. So if
1:05:26
you're tooling inclined, please pretty
1:05:28
much get involved in the committee
1:05:30
work to help us get there.
1:05:34
Well, there's a call to action.
1:05:36
Thanks for that. And thank you so much for being
1:05:38
a guest on the show today and telling us all about
1:05:40
the current state of modules and
1:05:42
build systems and
1:05:43
international ecosystem standard.
1:05:46
Thank you for having me. It's a pleasure. So how
1:05:48
can people reach you if they want to talk
1:05:50
to you about this stuff? So
1:05:53
my email
1:05:56
is druoso at Bloomberg.net or
1:05:59
my personal. email daniel.ruozo.com.
1:06:04
I am on Twitter, but I don't
1:06:06
really use Twitter. I'm there just
1:06:08
because Twitter was annoying me enough
1:06:11
with not having an account that I eventually created
1:06:13
one. So it's daniel.ruozo there
1:06:15
if you want to DM me. But yeah,
1:06:18
and I also try to follow the SG15 mailing
1:06:21
list. So if you want to discuss something tooling
1:06:23
based, maybe maybe just go straight there.
1:06:26
All right. Well, thank you so much, Daniel, for joining
1:06:28
us today. And for this fascinating discussion, I found
1:06:30
that very, very informative. Thank
1:06:33
you for having me. Thanks so much for
1:06:35
listening in as we chat about C++. We'd love to
1:06:38
hear what you think of the podcast. Please
1:06:40
let us know if we're discussing the stuff you're interested
1:06:42
in. Or if you have a suggestion for
1:06:44
a guest or topic, we'd love to hear about that
1:06:46
too. You can email all your thoughts to
1:06:49
feedback at cppcast.com. We'd
1:06:51
also appreciate it if you can follow CPP Cast
1:06:53
on Twitter or Mastodon. You can
1:06:55
also
1:06:56
follow me and Phil individually on Twitter
1:06:58
or Mastodon. All those links, as well
1:07:00
as the show notes can be found on the podcast
1:07:02
website at cppcast.com.
1:07:06
The theme music for this episode was provided by
1:07:09
podcastthemes.com
Podchaser is the ultimate destination for podcast data, search, and discovery. Learn More