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