0:02

Episode 360 of CPPcast

0:04

with guest Luis Caro Campos, recorded

0:07

4th of May 2023.

0:09

This episode is sponsored by JetBrains, smart

0:12

IDEs to help with C++. And

0:14

Sono, the home of clean code.

0:31

In this episode, we

0:33

talk about new C++-related compiler

0:35

releases

0:38

and some new programming languages. Then

0:43

we are joined by Luis Caro Campos. Luis

0:48

talks to us about the new version 2.0 of

0:50

Conan, the C and C++ package manager. Welcome

1:00

to Episode 360 of CPPcast,

1:02

the first podcast for C++ developers by C++ developers.

1:06

I'm your host, Timo Dummler, joined

1:08

by my co-host, Bill Nash. Bill,

1:11

how are you doing today? I'm

1:13

alright, Timo. I've been wrapping stuff up before

1:15

my next trip. I'm about

1:18

to start what I've been calling my Scandinavian

1:20

tour next week.

1:22

Although, because I'm going to be

1:24

away next week when we would normally be recording, we're

1:26

recording the week before. So by the time you hear this,

1:28

I'll have already done it. So I'm not quite

1:30

sure how that works.

1:34

If I've already seen any of you in Copenhagen

1:36

or Malmö, then thanks for coming.

1:39

So how's things up in your far corner

1:41

of the Nordic countries, Timo? So I'm

1:43

good. I have something very similar going on. I

1:45

was traveling a lot last week. I

1:47

was actually in Madrid using StudCPP.

1:49

That's the conference

1:51

organized by Carlos III University of Madrid. That

1:54

was really good.

1:55

And

1:57

literally just now I came back from Stockholm

1:59

where I...

1:59

I was giving a talk last

2:02

night about C++ and safety,

2:04

which is, was kind of a draft

2:06

slash rehearsal version of the talk. I'm going to give it

2:08

your conference, Phil. Cpp on C. Find

2:11

out all the bugs. And then

2:13

just in two days, I'm going to

2:15

be flying to Aspen,

2:18

Colorado for C++ Now. So when this

2:20

episode comes out next week, I will be there. Yeah,

2:22

sounds very busy for you as well. Yeah.

2:26

Yeah. I'm looking forward to some vacation.

2:28

I've been doing a lot of business travel lately. Right.

2:31

Right. So at the top of every episode, I'd

2:33

like to read a piece of feedback. And

2:36

this one is from an email that we received actually quite

2:38

a while ago back in January as

2:40

a response to the episode where Phil and I took

2:42

over the show. And

2:45

Robert gave us the following feedback.

2:47

Robert said that I would like to see more

2:49

attention paid to IDEs, tools and

2:51

all their aspects. Well,

2:54

thank you, Robert, for the feedback. We actually fully agree

2:56

with you.

2:57

We like to talk about tools. It so

2:59

happens that both Phil and I actually work

3:01

in the tooling space as well. So

3:03

that's why we're actually launching starting

3:06

today, a new series of episodes

3:08

about tooling. So we're

3:10

going to be talking about package

3:13

managers, IDEs, build systems

3:15

and things like that over the next few months.

3:17

I think the idea roughly is to have every

3:19

other episode be about that. And

3:22

then every episode in between to be about something

3:24

else. So that is not just about tooling.

3:26

Obviously, there's lots of other interesting topics. So

3:29

it's a little bit similar, like the mini series we did on

3:31

the so-called successor languages for

3:33

C++. So this

3:35

one is going to be about tooling. So I hope you're going to enjoy

3:37

that. Looking forward to it.

3:39

We'd like to hear your thoughts about the show.

3:41

You can always reach out to us on Twitter or

3:43

Mastodon or email us at feedback

3:45

at tppcast.com.

3:47

And joining us today is Luis.

3:49

Luis is an electronics and computer engineer

3:51

currently working as software tech lead in

3:54

the Conan team at JFrog.

3:56

He started his journey with C++ in the university doing research

3:58

in the field of software engineering.

3:59

computer vision.

4:01

Since 2015, he has been based in the UK

4:03

and has worked in the field of 3D scanning and

4:05

more recently in the field of robotics, autonomous

4:08

driving at Oxbotica before joining the

4:10

Conan team at JFrog in 2022.

4:13

Over the years, Lewis has become concerned with the problem

4:15

of enabling C++ software development at

4:17

scale, working on the tooling and processes

4:20

that enable large teams of C++ developers

4:22

to focus on writing code.

4:24

Lewis, welcome to the show. Hi,

4:26

thank you very much for having me. So

4:28

obviously we're going to be mostly talking about your work

4:31

at Conan and JFrog today, but I'm

4:33

most interested in the autonomous driving you mentioned.

4:35

What was your involvement there?

4:37

Well, actually, when I joined, and I think

4:40

it was the week that I joined,

4:43

the team was deciding on

4:45

what to do with C++ dependency manager. So

4:48

one of my colleagues had quite a

4:51

really good review of the tools available at the time.

4:54

And that day I was like, how

4:56

about Conan? How about we integrate Conan? Because I had used

4:58

it before in my previous job. So my

5:01

involvement grew from that

5:03

into sort of looking into the software infrastructure

5:06

side of things,

5:07

which is what we call the team that

5:09

handled anything to do with the build system and with

5:11

dependencies and CI and all that stuff.

5:14

Yeah, or DevOps, we often call it these days. I

5:17

know. Yeah, we've somehow we resisted to call

5:19

it DevOps for some reason.

5:21

Well done. Okay, so

5:23

Luis, we'll get more into your

5:26

bio and your work at JFrog and Conan in just a few minutes,

5:28

but we do have a couple of news articles to talk about.

5:31

So feel

5:32

free to comment on any of these. Okay.

5:34

Perfect. All right. So the first

5:36

news item for today is that GCC 13 got released.

5:41

So we had the release of Clang and LLVM 16

5:45

not too long ago. And now GCC 13 came out. They added lots

5:48

of C++ 23 language features.

5:51

Among others, they added attribute assume, which

5:53

I'm very happy about this is a feature that is

5:56

standardized. So

5:57

nice that we have a first compiler actually supporting

5:59

that.

5:59

They also added static operator

6:02

paren paren and static operator square bracket.

6:04

Lots of all the other smaller C++ 23 features. There's

6:07

a long list on the

6:09

change release notes document.

6:12

And actually another one of those that

6:14

I found particularly interesting, because

6:16

I only found out about it very, very recently, is

6:19

they implemented this

6:21

C++ 23 feature called relaxing const

6:24

expert restrictions. It's paper P2448.

6:28

And basically what this does is it

6:31

allows you not to declare a function as const expert,

6:35

even if it does like non const expert things

6:37

like, I don't know, print hello world to see out

6:39

or something like that, which is obviously not, you

6:42

know, you can't, you can't do that at compile time,

6:44

but you can still now since your C++ 23 declare

6:46

that function as const expert. And

6:48

as long as you don't try to actually call it at compile

6:51

time and you only call it at runtime,

6:53

that's now fine. And they implemented that.

6:55

And according to the GCC bug tracker, it

6:57

was actually wasn't trivial to implement,

7:00

but it gets rid of kind of annoying

7:02

errors in certain situations. And it's kind of a cool

7:05

cleanup, in my opinion. Yeah,

7:08

that one flew under my radar as well.

7:10

But I presume it's similar to what we got in C++ 20,

7:13

where you could throw exceptions as long as

7:15

you didn't actually throw the exception. Yeah,

7:17

is that similar? Well,

7:19

it does not compile then if you do end up calling,

7:22

calling the runtime functions.

7:24

Yeah, so I encountered this actually

7:27

recently when we were discussing contracts and

7:29

topic came up of like, Ooh, how do

7:31

you,

7:32

because we're still designing the feature, right? We are

7:34

aiming for C++ 26 and the question came up.

7:36

So how do we evaluate contracts

7:39

at compile time?

7:40

And then we had a discussion about this and, you know, somebody

7:42

said, Oh yeah, but then, you

7:45

know, in a const expert context, you know, you

7:47

can do this. And I was like, hang

7:49

on a minute. Like what? And

7:52

then I started digging and I found that, oh yeah,

7:54

it's a thing now since you're C++ 20 and you now actually

7:56

implemented this. So that

7:58

was, that was interesting. So they

8:00

also added a bunch of, uh, super sustainability

8:02

library features, like, um, magnetic operations

8:04

for, um, expected, uh,

8:07

like, and then, or else, like

8:09

those things, um, which we got into

8:11

the super sustenance he standard at the very last minute,

8:13

a const expert bit set, a

8:16

lot of new ranges stuff. I'm not going to list that all,

8:18

but it's a lot.

8:19

And also some super sus 20 features that were actually

8:21

not in DC yet. No, to blease that format,

8:23

which is now in GCC, which is really cool. Yay.

8:27

And they also have some like

8:28

other improvements and additions unrelated to like

8:30

the new standard, like

8:32

they improved the static analysis, they improved opening

8:34

piece of port, they improved support for like other

8:37

languages, like ADA for trying, et

8:39

cetera.

8:40

Big release. So quite a major release. Yeah.

8:42

That's, that's really cool. I think, uh,

8:44

it's going to take about a nanosecond until we

8:46

get a request to, uh, start building packages

8:48

in Conan center with Jesus at 13. So I'm looking

8:51

forward to that one.

8:52

Good luck. Good luck for that. Thanks.

8:55

And there was actually another news

8:57

item that has to do with compilers.

9:00

Actually helps Sutter, whom we had on the show, I think

9:02

was it four weeks ago, six

9:04

weeks ago, um, like

9:09

very recently, who was talking to us

9:11

about his, uh, CPP two,

9:13

uh, language and CPP front compiler

9:15

has just released a CPP front spring

9:17

update with kind of what's been happening

9:19

with CPP two and CPP front.

9:21

Uh, there's lots of exciting new features there.

9:24

So, uh, CPP two can now

9:26

do user defined types,

9:28

uh, chain comparisons, uh, lots

9:30

of other stuff. He has an initial version now

9:32

of a reflection API in there,

9:35

which is something that kind of you're very stuck on,

9:37

uh, in C plus plus one

9:39

at the moment. But C++ two is leaping ahead.

9:42

Um, he actually has 10 already 10 working

9:44

compile time meta functions.

9:47

Which are all coming from P0, seven,

9:49

zero seven, which was his meta classes proposal.

9:52

So if people are asking like, what's happening

9:54

with house meta class proposal, well, those features are

9:56

all now going into CPP two, and I guess it's the answer.

9:59

And, um, Also, his list of collaborators

10:01

for that project is actually growing really steadily,

10:04

even though he keeps saying that it's just this private

10:06

experiment and all that. But

10:07

there's definitely more people involved now, which is also kind

10:10

of cool. Don't all things start as a

10:12

private experiment? And then before

10:14

you know it, everybody's using it? Only

10:16

the successful things.

10:18

Exactly.

10:19

Yeah, I thought it was amusing that in the same release

10:21

we get classes, basically. We

10:23

also get reflection and meta classes, which

10:25

seems like quite a big jump. But

10:28

I suppose that is the point of CPP, too.

10:30

Speaking of programming languages and new

10:32

programming languages, this is not really C++

10:34

news, but it's kind of vaguely related. So I just wanted

10:37

to bring it up. So there's actually a new programming language,

10:39

which was announced for all of AI.

10:42

I guess that's kind of the tagline. It's

10:44

called Mojo. It's available at

10:46

modular.com slash Mojo.

10:48

And it's similar to Python, but fast.

10:51

That's basically the premise. And

10:53

it's not just fast, so it's not just focused

10:55

on performance in general, but it's actually aimed

10:57

at heterogeneous programming.

10:59

So it's meant to run on all kinds of different hardware

11:02

and utilizing it properly, like

11:04

CPUs, multi-core, but

11:07

also GPUs, kind of exotic accelerator

11:09

hardware and stuff like that.

11:11

And so the aim is to achieve performance

11:13

on par with C++ and CUDA,

11:16

but without the complexity and with a

11:18

front end that's kind of very

11:21

similar to Python.

11:22

So that's really exciting, I think.

11:24

Absolutely. Those

11:26

are some big promises when it comes to performance.

11:29

Yeah, yeah. Looking forward to giving

11:31

them a listen. Yeah, I think the last language that promised

11:33

something vaguely similar was Julia, which I

11:35

don't think did very well in the long run. So

11:38

hopefully they will have more success.

11:41

Yeah, you do see similar promises from time

11:43

to time, and usually it doesn't quite follow

11:46

through. But always exciting, though. So

11:48

interesting to see where it goes. Yeah, yeah. So what it is

11:50

basically, from what I understand, it's like a Python-like

11:53

front end on top of LLVM MLER,

11:56

which is like the multi-level ER.

11:59

for kind of running on different

12:02

hardware and stuff. So

12:03

yeah, let's see.

12:06

And another kind of news item

12:08

that I just wanted to mention relating to

12:10

another programming language is that it

12:12

looks like Rust got forked.

12:14

And I wasn't sure if that

12:16

was maybe a joke. Maybe it is a joke.

12:19

As you know, Phil, I'm not very good at getting jokes, but.

12:21

Well, there's a joke in there about having

12:23

a rusty fork. But. So

12:27

apparently, the Rust community has quite a lot of illegal

12:30

drama going on at the moment. And that's

12:32

kind of a result of that.

12:33

So the new Rust fork is called

12:36

Crablang or Crab, the Crab language.

12:39

And it's available at Crablang.org.

12:42

There's a GitHub page. There's

12:45

a long Reddit thread where this is being discussed.

12:49

I'm just going to cite from Crablang.org. They

12:51

say that our goal is not to fracture the community,

12:53

but rather to provide an alternative for those who share

12:56

our concerns and wish to have more freedom in using,

12:58

creating with, and promoting the language without

13:00

worrying about the litigation associated

13:02

with trademark infringement. So yeah,

13:05

sounds like some legal drama indeed.

13:07

Yeah, so I gather

13:09

like Rust does like many, many

13:11

good things. But what people really, really like

13:14

is the logo. That's

13:18

interesting. This gives them a chance to keep the same

13:20

style of logo. Absolutely. Right.

13:24

So I guess we will be observing

13:27

this drama from a safe

13:30

distance and wish them all the best.

13:35

And then one thing that I just wanted to bring

13:37

up quickly, as I mentioned a couple of episodes

13:39

ago, is that my undefined behavior

13:41

survey is actually still running.

13:44

It's a little survey. It's just three questions.

13:47

One of them is actually optional.

13:49

So it's really just two that you have to answer.

13:52

It takes about two minutes.

13:53

And it's a little survey about undefined

13:55

behavior, basically what it means for you.

13:58

And it's a little experiment I'm doing. for

14:01

my talk about C++ and safety, which I'm gonna be

14:03

giving at CPP-on-C next month.

14:06

So if you do wanna help me out and have

14:09

a more representative data set for this,

14:12

then it would be very helpful if you could help

14:14

me and fill out the survey. It only takes a couple

14:16

of minutes. Tmo.audio slash survey.

14:19

And I will reveal the results at CPP-on-C.

14:23

And I'll put that link in the show notes again. All right.

14:25

And presumably if the survey

14:27

never stops running, that itself is undefined

14:29

behavior, isn't it?

14:31

Well, but not,

14:33

yeah, but like an infinite loop is

14:35

undefined behavior. So then we can assume

14:37

that the survey never happened and optimize it out

14:39

of existence. And that would be very unfortunate. So I

14:41

think I'd rather

14:42

terminate it and write some output to,

14:45

yeah.

14:45

So

14:48

don't rely on it still running. Yeah. I think

14:50

so. Right. So

14:53

yeah, that's all the news items that we have

14:55

for this week. So I guess we can

14:57

transition to our main topic for today,

14:59

which is Luis and his

15:01

work at Conan.

15:04

Hello again, Luis. Hi,

15:06

how's it going? Good, good. So

15:08

before we get to ask

15:11

you stuff, I just wanted to share a story,

15:13

if I may, about Conan. So

15:15

I haven't actually used Conan

15:17

very extensively, but it

15:20

literally saved me the one time where I

15:22

really needed it. And so, you know,

15:24

I was kind of ignoring this whole stuff for a while. It's

15:26

like, oh yeah, package manager, some weird

15:29

frog people.

15:31

I mean, I don't really need that. I just write my own make files

15:33

and I just have my own libraries and I know how

15:35

to compile them, right? So

15:37

that was going on for- I wrote a song about that. What? Yes,

15:40

you do. You do. What

15:42

could go wrong? So I was doing that for

15:44

a while.

15:45

And then, so I was

15:47

preparing this talk about atomic

15:50

shared pointer, log-free atomic shared pointer and how

15:52

to implement it.

15:53

And I was doing that for C++ now, by

15:55

the way, there is a C P conversion,

15:57

which is 60 minutes from that talk. Don't watch that.

16:00

watch the full 90 minutes, it's just no version because

16:02

it's much more detailed. So I

16:04

was preparing that talk. And what

16:06

I was trying to do is I was trying to benchmark

16:09

different implementations of BlockFi

16:10

Atomic SharePoint. So I found

16:13

three implementations open source.

16:15

Two of them were basically just here's a header file. They

16:18

weren't really

16:19

production ready. And I

16:21

found only one implementation that was actually being used in

16:23

production by Folly,

16:25

the Facebook library. So I was like, okay,

16:27

awesome. I need to like benchmark this, compare

16:29

this with the other two implementations compared to my

16:32

own implementation. It's a header

16:34

only class, right? It's like atomic chat pointers, like

16:36

a template, fantastic. So I'm just going to take this class

16:38

and

16:39

compile it and benchmark it.

16:41

And then it turned out that it was just a world of pain.

16:43

Like I couldn't

16:45

figure out because I was just doing CMake, I couldn't figure out how

16:47

to integrate Folly into any of my

16:49

stuff. I spent like a day on this.

16:52

It just wouldn't work.

16:53

I asked my friend Victor

16:56

who works at Facebook, hey, how

16:58

do I use this? And he was like, I don't know. We have

17:00

our own internal build system at Facebook. I don't know

17:02

how you do this with CMake. We don't do this over here.

17:05

I didn't find anything on the internet about

17:07

this.

17:08

Apart from a few people who were apparently struggling

17:10

as badly as I was. And then I was like, okay,

17:12

screw this. It's just a header. So I

17:14

don't need to compile the actual library. Let me just pull

17:17

out the header.

17:18

Then the header was pulling in other headers.

17:20

And then those headers were dependent

17:22

on some macros, whichever defined in yet other

17:25

headers. And some of these macros were

17:27

apparently defined by the build system, which obviously

17:29

I wasn't using. So nothing would compile.

17:31

And

17:31

I spent another day on this and it was just

17:34

really very painful. And I couldn't get anything

17:36

to run. And I had the talk coming up

17:39

the next day. So I was like, what do I do?

17:41

And then somebody said, why don't you try Conan?

17:44

And so, yeah, so

17:46

I read a quick tutorial, how to get started.

17:49

I wrote this Conan file, .txt,

17:52

which just says, I need Folly and I'm using CMake.

17:58

And then I did like pip install. and

18:00

then 10 minutes later it was working. And I

18:02

had the library and it was actually compiling and running.

18:05

And I was kind of blown away by that.

18:07

And so ever since then, I'm

18:09

kind of really curious about what you guys are doing. And

18:12

I think you're awesome. So

18:15

definitely wanted to get you on the show. So

18:17

I'm very happy

18:18

that you're here. And

18:21

yeah, so you just had a major release, didn't you?

18:24

Absolutely, yeah. So like a couple months ago, I

18:26

think it was in mid-February, we released

18:28

Conan 2.0. So full of new features

18:30

and excitement. Yeah. And

18:33

so I should also say is that I was talking to Diego

18:35

initially. I've known Diego for a while now.

18:38

And I was like, oh, Diego, yeah, of course you could

18:40

come on the show. But you have kind of already been on the

18:42

show. We wanted to

18:45

have more people, new people, a chance to speak.

18:48

So who would you recommend? And it

18:50

would be ideal to have somebody who can really talk about

18:53

Conan 2.0 and everything that's going on there. And

18:55

then he said, you need to talk to Luis. So

18:57

it's because he knows I never shut up. All

19:01

right. So for those of our listeners who

19:03

are maybe not familiar with Conan, can you give us just

19:05

a quick overview of what it is and what it does?

19:08

Absolutely, yeah. So like just as you were

19:10

telling in your story, right, you started with

19:12

I was managing my own like make files, what could

19:14

go wrong? Turns out a lot of things

19:17

can go wrong. And that story that

19:19

you just told, you'll

19:21

see variations of the same story in a lot of teams

19:23

and a lot of companies. And the

19:25

more dependencies you use or the

19:27

more variables that you have, like maybe you're

19:29

targeting like multiple platforms. Maybe it's only Linux.

19:32

Maybe you're mixing Windows again. That

19:35

tends to become like more complicated, if

19:37

not unmanageable, depending on what you're doing.

19:40

So Conan is a tool that allows you to abstract

19:43

those things away from your build system,

19:45

right?

19:46

Anything related to

19:48

building other people's code,

19:50

it will help you abstract away from your own build system

19:53

and generate something that

19:55

your own build system can consume. So like

19:57

it provides an abstraction that...

19:59

matches your own build system as well

20:02

without having to worry about the others.

20:04

But depending on which thing you ask me, I'll give you

20:06

a different answer, but I think that's a good one based

20:09

on the story you told earlier.

20:10

Yeah, that's a good description. So I

20:12

remember when I was dealing with this horrible

20:15

pain of trying to get folly to compile, there

20:17

was one problem where folly would just

20:19

pull in this other dependency. I don't remember

20:21

which library it was, which was totally

20:24

not needed for this one class template that I was trying

20:26

to compile, but it would just pull

20:28

that in.

20:29

But then my project was using

20:31

another version of the same library, and then they were clashing,

20:34

and I was getting

20:35

super weird linker errors, and I spent literally

20:37

a day trying to figure out what's going on there.

20:40

So how do you resolve problems like that?

20:43

How does that work? That particular

20:45

problem is going to happen to basically

20:48

any package maintainer, right? Well,

20:51

especially we see that problem in Conan Center as

20:53

well, where we actually make available both the

20:55

Conan recipes and the packages for libraries

20:58

is we have to make sure that the build system

21:00

or the libraries that we're building are not pulling things in. So

21:02

we have to find if it's happening, where

21:05

it's happening, and disable that, and make sure

21:07

that they can find the version that we have

21:09

elsewhere in Conan Center precisely

21:12

to avoid these sort of

21:13

linker errors as well. So well,

21:16

the way we solve that problem is by not

21:19

doing what you described, I suppose, and basically

21:21

make sure that every dependency that

21:23

you have is actually modeled correctly as

21:26

a dependency graph. Wait, so

21:29

do you actually go ahead, take each

21:32

reasonably popular C++ library that's out there

21:35

and just figure out how is it

21:37

going to be built? How do you

21:39

build it? How is it supposed to be built?

21:42

And how do we tweak a touch that it

21:44

fits or do that

21:46

work yourself? Well,

21:48

we do have a really active

21:51

and engaged community in Conan Center to

21:53

do this as well. But yeah, absolutely. And

21:56

I'm pretty sure if anybody out there

21:58

is listening that works, let's say, on the Debian.

21:59

package maintenance or home

22:02

brew VC package, conduct, that

22:05

particular problem is the same. If you

22:07

really want to model the dependency, you're going to have to actually,

22:09

yes, go and figure out whether this is

22:11

happening or not. Fortunately for

22:14

us, a lot of projects are using like

22:16

modern build systems, either like modern CMake,

22:19

as people call it, that may be using

22:21

Mason, and they're

22:23

following better practices, I would

22:26

say, and not sort of bundle

22:28

those dependencies. I

22:29

sometimes feel like when

22:32

a library author bundles of

22:34

the dependencies in the build system, it's because they've done

22:36

what you described earlier, I have my own make files,

22:39

right? So they're thinking about their

22:41

workflow of, I'm developing this library, I'm

22:44

the end user, but the reality is they're not the end

22:46

user, right? The users of your library are the end

22:48

users, and they

22:50

may or may not be using the same dependency

22:53

in a version that may or may not be compatible with

22:55

the one you're using as well. So that's one

22:57

of the problems we sort of try to

22:59

solve, or at least

23:02

Conan gives you the tools to solve that problem, and

23:04

then the responsibilities are shifted to like

23:06

the package maintenance, so to

23:08

speak.

23:09

So we already mentioned that Conan two

23:12

is out, but what's actually new

23:14

to make this a major release?

23:17

Oh, there's a lot of things that

23:19

are new in Conan two. One of them is

23:21

the tool itself. I was just

23:23

checking earlier, we pretty much rewritten 80%

23:26

of it, I think, if

23:28

you measure by lines of code, which is arguably

23:31

not the best way to measure these things. So

23:33

over the years, and we

23:35

have to keep in mind that Conan, I think the first

23:38

preview release came in mid 2016, so

23:41

it's been over seven years now

23:44

that Conan's been out there, and

23:47

we very much try to keep it

23:49

sort of compatible, like Conan one

23:51

point X, keep it compatible,

23:53

so not bringing compatibility in any way with the way

23:56

users were using it. But

23:59

over time, it became more difficult to

24:02

release bug fixes, add new features. Just

24:05

because, you know,

24:06

software over time, these things are

24:08

difficult. So it was

24:11

re-architected, especially

24:13

the core components, which makes it a lot

24:15

more flexible, but for us as maintainers

24:18

of the tool, but also for the

24:20

users as well. So one of the new features

24:23

is extensibility,

24:25

in ways that are easier to manage, have

24:28

your own custom CLI commands, for instance.

24:30

So that's always been a really

24:33

popular request, but also

24:37

custom ways of modeling whether

24:39

binaries are compatible with other

24:41

variants of the same library,

24:43

for instance. So maybe you can say, oh,

24:46

a binary bill which is with C++ 17

24:49

is compatible with a binary bill with C++ 14,

24:52

or any rules that you may have arbitrarily

24:55

have in your own project, in your team, you can actually

24:57

express that in code away from the recipe,

25:00

which was possible in content

25:02

one, and try to keep

25:04

the logic of the recipes as

25:07

clean as possible.

25:08

That's ironic actually that it's like a breaking

25:11

change to be able to achieve greater compatibility.

25:14

Absolutely, yeah. And this is not something that we take

25:16

lightly, as I mentioned before, keeping

25:18

compatibility was always like a goal. So

25:21

bumping the major version to version

25:24

two, indeed caused some

25:26

breaking changes. So some features have gone

25:28

away.

25:29

Some features that were experimental in

25:31

content one, like a package and recipe

25:34

revisions are now fully enabled

25:36

by default.

25:38

We've been taking care, as I mentioned before,

25:40

of not having breaking

25:42

changes, but with the

25:45

new version of content, we have made

25:47

some changes that obviously break how users use

25:49

it.

25:50

We have at the very least provided

25:52

a compatible

25:53

features in content one.

25:56

So there's a subset of content one that is very

25:58

much one-one compatible with content two.

26:00

And that's the approach we have taken, for instance, in the recipes

26:02

in Conan Center. So at the moment, they are

26:04

compatible with both versions.

26:07

But

26:07

also some features have gone away. Some

26:09

features that used to be experimental are now actually

26:11

the default in Conan 2, now

26:14

that we've had a chance and users themselves

26:16

have had a chance to provide feedback

26:19

over the years as well.

26:21

So is the typical user likely to

26:23

need to make changes to migrate? Or

26:25

is it just specific users who are going to be broken?

26:28

Typically, users, yes, especially

26:30

because one of the biggest things that

26:32

we've changed are the CMake integrations.

26:35

So they're likely to have to make

26:37

changes to the recipes. What

26:39

we've seen is that they're not

26:41

very invasive changes. We do have

26:43

in the documentation, we have a migration

26:46

guide to some of the changes that

26:48

you have to make. So what we hope is that

26:50

the vast majority of users

26:53

don't have to make invasive changes

26:55

to the recipes or their workflows. But

26:57

they are going to have to make at least some changes

26:59

indeed.

27:01

And I believe there's mention of a new graph

27:03

model. Can you say anything about that?

27:06

Yes. And there's a very good talk

27:08

about this that Diego did last year

27:11

in ACCU. So I could just

27:14

give a brief summary about this. So

27:17

we've seen over the years, users

27:19

have been using Conan at scale. So

27:22

we have teams that maybe have five

27:24

to 10 dependencies. We have teams that have

27:26

maybe 90, 100, something like that. And

27:28

then we have teams that use Conan

27:30

for both external libraries, like open

27:33

source libraries, and their own libraries and workflows.

27:35

So one of the things that becomes

27:38

challenging, well, there's two aspects

27:40

of this. It's like, obviously, how to propagate the flags

27:43

down to the compiler and the linker where they are needed,

27:45

but also the logic of what do you rebuild

27:48

when something changes. When you have a complicated

27:50

dependency graph,

27:51

and you have it at that scale,

27:53

there comes a point where you cannot afford

27:56

to rebuild everything. And

27:58

that's where the new graph model.

27:59

comes in is that

28:01

by having awareness of whether

28:03

a package, and we have this new package type attribute

28:06

in the recipes, you can specify what is something is

28:08

an application, a

28:10

shared library, a static library,

28:12

a header-only library, by having that knowledge

28:15

in the recipes themselves, Conan can

28:17

make better guesses about what needs to

28:19

be rebuilt based on

28:21

changes somewhere in the dependency graph.

28:24

Right. Within a local build

28:26

system, one of the big challenges is when one

28:29

build step produces artifacts

28:31

that dictate what the next build step

28:33

is going to be, and so you can't

28:35

always sort of look ahead. Do

28:37

you have that problem at the Conan scale?

28:39

Absolutely. Yeah. So, and the

28:41

graph, again, helps in

28:43

the systems as well. So, kind of configure when

28:46

you have multiple Conan recipes from which you need

28:48

to create binary packages, Conan can

28:51

give you the right build order in which they need

28:54

to be built, and base exactly on this additional

28:57

information. Absolutely. So, now it

28:59

models the intricacies of C and C++ libraries,

29:02

and where

29:05

shared libraries behave and propagate different

29:08

than static libraries, for instance. And

29:10

now it gives you better tools of sort of

29:12

either avoiding things like

29:14

symbols. I think you mentioned

29:16

this team earlier, having symbols in

29:19

multiple places are incompatible with each other and

29:21

things like that. Right.

29:23

Yeah. So, it's a lot of work. You're doing an heavy half.

29:25

Thanks for that. Thank

29:27

you. The release notes also mentioned that you have

29:29

a new public Python API. So,

29:31

what's that about? Like, why would, when would I use,

29:34

when would I use the Python API to interact

29:37

with Conan?

29:38

Absolutely. So, we do have a new

29:40

public Python API that we didn't have before. So, unfortunately,

29:44

what you notice over the years is that people

29:46

actually use your private API, and

29:49

then that one can break, and people

29:51

are not very happy about that. So, now,

29:53

now we have a public Python API.

29:56

One of the workflows that

29:58

goes beyond like doing a local

30:01

build. So you have your own project

30:03

and you want to call Conan install to bring the binaries

30:05

for new dependencies, as we do

30:08

with continuous integration.

30:09

So in continuous integration, developers

30:12

are very likely to have a script

30:14

that drives this. So maybe the one script

30:17

that's already written in Python and they want

30:19

to interact with Conan to drive the build.

30:21

And maybe you need to call Conan

30:24

to tell you what the build order is and

30:26

orchestrate

30:27

your CI to build those things in the

30:29

right order, maybe in parallel as well if you

30:32

can make that connection. Then

30:34

you maybe want to upload those

30:36

binaries to your Conan remote as well. So

30:39

in Python, you can actually do this programmatically.

30:41

We also have in Conan 2, all

30:44

the commands now have a uniform

30:46

output as well. So we have JSON output. So

30:48

optionally, you don't have to use the Python API if

30:51

you can

30:52

work with JSON output.

30:54

You parse

30:55

it and then you take the inputs you want. But

30:58

to be honest, we'll discover, apart

31:01

from the things that we are aware of, we'll discover what people

31:03

actually come up with, which is going to be really interesting

31:05

for sure.

31:06

Cool. So hang on. Conan is written in

31:08

Python, isn't it? Absolutely, yeah. It's

31:10

written in Python. Ah, that's cool. So

31:13

it's another C++ tool that's actually not written in

31:16

C++. Seems like there's quite a few of them around.

31:19

So I think EDG and GCC

31:21

are written in C. And then obviously,

31:23

like C line is written in Java

31:26

and Kotlin. So I think there's probably more of

31:28

these tools that are not written in

31:30

C++.

31:31

I know. And this is something that we

31:33

hear from time to time, where some

31:35

developers really want all of their tooling

31:38

to be written in C++ so that they

31:40

can bootstrap it from scratch

31:42

or something like that, which I suppose it's

31:45

reasonable in some scenarios.

31:47

But I always ask, are people

31:49

really willing, maybe they are actually, CMake

31:51

from source and get

31:54

in and all these other things that they may need?

31:56

So as far as I'm concerned,

31:58

Conan is just an executor.

34:00

public libraries that we make available

34:02

in Conan Center. So it has

34:05

a really well-defined structure. So we're using

34:07

custom commands to actually automate

34:09

or simplify some of the tasks. It's quite

34:12

exciting to be honest. We really, really like the

34:14

custom commands feature. It comes up

34:16

a lot whenever we talk to developers

34:18

who have not switched with Conan too yet, and

34:20

then describe workflows, and we say, hey,

34:23

you can implement your custom commands. It's probably going to be

34:25

not as many lines as you think it's going to be and it's going to

34:28

make your life a lot easier

34:30

as well.

34:31

On the CMake integration side of things,

34:33

and I think

34:35

users will remember

34:37

the early days of Conan where you had to

34:40

include a file that was generated by

34:42

Conan and then targeting libraries

34:44

against some specific Conan underscore

34:47

package targets, if I remember correctly.

34:50

One of the most requested features is to not

34:52

do that. People,

34:53

at least that we see, they don't

34:56

want to make modifications to

34:58

the CMake lists as scripts in

35:00

order to be able to consume dependencies

35:03

from Conan. That's also

35:05

been improved as well, and now you have the option

35:07

of generating the toolchain file that

35:09

if you pass it to CMake

35:11

when you first configure,

35:13

then CMake will be able to resolve the fine

35:15

package calls to the

35:17

dependencies that you have, and also generate

35:19

the targets with the same names that you were

35:21

expecting rather than some arbitrary Conan ones

35:23

as well.

35:24

That's actually been

35:27

used at scale in Conan Center as well, so we know it

35:29

works quite well. Cool.

35:31

If I have a C++ library

35:34

that's on GitHub, how do I

35:37

get it onto Conan Central? How do

35:39

I make it easy for people to get

35:41

my library via Conan?

35:43

Absolutely. Well, you have two

35:45

options. You can raise an issue with

35:47

us in Conan Center index GitHub

35:49

repository. Say, hey, I need

35:52

some help on making this available, or

35:54

if you want, you're more than welcome

35:56

to open a pull request with

35:58

the recipe itself.

35:59

that it will run on our continuous integration

36:02

service built for as many platforms

36:05

as we support.

36:06

And then our community

36:08

reviewers and our team members

36:10

in the content team will make every effort

36:12

to make sure it gets in. That's

36:14

cool. So how many GitHub stars do I need

36:16

for that? Ha ha ha.

36:19

Not many, actually. We do have some

36:22

checks before allowing

36:25

people to contribute. So

36:27

we will flag things like just created accounts

36:30

or something like that. So you do need to have some activity,

36:32

but not even many.

36:34

Should be fine. All

36:36

right. OK, well,

36:38

we do have some more questions about package

36:40

and dependency management in general. But we're

36:42

going to come back to that after a quick

36:45

sponsor break, which is going to focus more on

36:47

the code, actually,

36:48

because this episode is sponsored again by SONA,

36:51

Home of Clean Code.

36:53

And SONA lint is a free plugin

36:55

for your IDE, which helps you to find

36:57

and fix bugs and security issues from

37:00

the moment you start writing code.

37:02

You can also add SONA Cube or SONA

37:04

Cloud to extend your CI CD

37:06

pipeline and enable your whole team

37:09

to deliver clean code consistently

37:11

and efficiently on every check-in or pull

37:13

request.

37:14

SONA Cloud is completely free for open source

37:16

projects and integrates with all of

37:18

the main Cloud DevOps platforms.

37:22

All right. OK, back to Luis. So

37:24

we talked a lot about Conan

37:27

and Conan 2.0 and how it all works and why

37:29

it's great. I want to kind of

37:31

zoom out a little bit and talk about the

37:34

C++ community in general and kind of the ecosystem.

37:38

So I guess kind of an open-ended

37:41

question. What do you think are currently the biggest

37:43

challenges in this area of package

37:46

management and dependency management, kind

37:48

of more widely? Oh, that's

37:51

a very interesting question, because I

37:53

could talk about this for hours if

37:56

you ask me. I'll try

37:58

to be brief on this.

37:59

on this topic. So I would say

38:02

one of the biggest challenges, and I think we need

38:04

to remind ourselves that C++

38:06

has been around for nearly 40 years now,

38:08

right? If I'm not mistaken.

38:10

There are no standard

38:12

ways to interface with

38:14

the build system.

38:15

There's no standard way to interface with a compiler

38:18

other than the source code itself, but the command

38:20

line flags, every compiler implementation

38:22

is free to do whatever

38:25

they want. So that lack of standardization

38:28

sort of the passing of time means

38:31

that there are many solutions to

38:33

very similar but not quite the same problem.

38:35

And that diversity

38:38

of things out there make it really

38:40

difficult

38:41

to solve the problem in a way that

38:43

people like. What

38:45

we see, especially from the current

38:47

side is that we get uses

38:49

requesting features that are one thing

38:52

and other uses requesting exactly the opposite.

38:54

So it's really difficult to actually

38:57

satisfy the use cases or

39:00

not even that, it's probably easy to satisfy the use

39:02

cases if you just hack everything, right?

39:04

But it's hard to do it with

39:07

the right level of destruction in a way that you can maintain

39:09

over time. And I personally think that

39:11

that's one of the strengths of Conan is that

39:13

it's allowing that

39:15

diversity to exist while

39:18

the C++ ecosystem continues to

39:21

evolve. I think also something to keep

39:23

in mind is that modern CMake, which

39:26

a lot of projects seem to be converging on

39:28

hasn't been around for that long. And

39:31

now we're going to be adding modules into

39:33

the mix. So I

39:35

think it's safe to say the C++ is going to continue

39:37

to evolve,

39:39

but I think we need to

39:41

start paying attention into trying to, I wouldn't

39:44

might say standardize but like maybe have

39:46

a better conventions

39:48

for how to interact with a build system

39:51

maybe from the command line point of view, to

39:53

a compiler

39:55

or even agree on what's a library.

39:57

Depending on who you ask, you get very.

39:59

different questions about what libraries. Well, if

40:02

I put my committee member hat on, there

40:04

was no such thing as a library.

40:06

Exactly.

40:09

Exactly. So it's difficult because

40:11

a developer will expect, maybe

40:14

they will expect some developers, well, some developers won't.

40:18

And obstruction, right? You're in CMake. You do

40:20

target link libraries, my program,

40:23

or my library against something else.

40:25

What is that something else?

40:27

At the low level, something else is just flags

40:29

that get passed to the compiler, to the linker, maybe

40:32

to the runtime linker to find Azure

40:34

libraries.

40:35

But you don't want to be concerned about that.

40:37

I've had developers in my

40:39

previous team say, I don't care about

40:41

this. No, it's like, it should be in a way that I don't have

40:44

to dig through the flags that are passed

40:46

because of some other library. And that's true.

40:49

So

40:50

where do you put the responsibility?

40:52

I think the responsibility is indeed in

40:54

the package management side of things. But then

40:57

the package management side of things needs to

40:59

be able to retrieve the information from somewhere.

41:02

And there are no ways for the library

41:04

authors to express this information

41:06

in a way that is also

41:08

standard or compatible across

41:11

multiple systems as well. So at

41:13

the moment, I think we're in a situation where

41:16

the package repository

41:18

maintainers are doing a lot

41:20

of the lab work, keeping the

41:22

ecosystem sane. And it's happened for

41:24

decades, actually. Like, the Linux distros have been

41:27

doing it

41:27

for a long time with, obviously,

41:29

some

41:30

limitations. Those package managers only

41:32

work either only for Linux or only for specific

41:35

distros and don't work for Mac OS

41:37

or Windows or the systems.

41:39

But now we're seeing different things.

41:41

But still, what I see is that there's a lot of

41:43

work in maintaining or curating

41:47

the package recipes or the packages

41:49

themselves. So if we make

41:52

more efforts in standardizing some

41:54

of those things, I think a lot of the pressure

41:57

of repository maintainers

41:59

will be reread.

41:59

we're relieved as well, and maybe things become

42:02

a lot easier to do. So

42:05

somewhere in your answer, you actually

42:07

mentioned something that is a very good segue into

42:09

my next question. You mentioned modules. So

42:13

we got modules since it was last 20. They were

42:15

supposed to solve lots of problems. But three

42:17

years later, I don't really see them being used

42:20

in mainstream C++ development.

42:23

I know that the CMake team has

42:25

done a lot of

42:27

effort to try and make it work. There's

42:29

a few talks here and there where people who went through heroic

42:32

efforts modularized their libraries. But

42:34

it's not that

42:36

it's really a thing that's used more widely.

42:40

I wonder if that has

42:43

something to do with the

42:45

impact that modules have just

42:47

on what you have to do if you have

42:50

a build system, if you're a package manager, if you have

42:52

any of this plumbing around actually building code.

42:55

That just makes it so much harder.

42:57

So how do modules impact you

43:00

as somebody who works

43:03

on a package manager? Or where do

43:05

you see the problems more widely?

43:08

Absolutely. From what I remember,

43:10

using a module had

43:12

an imposter requirement that

43:15

your compiler on your end needs to be able

43:17

to invoke the compiler to, I think,

43:20

create the module object, well, the

43:22

equivalent of the object, if I'm not mistaken.

43:25

As I mentioned before, because there's no interface

43:27

to the compiler,

43:29

that's imposing your challenge. Where's

43:31

the responsibility? Is there a responsibility

43:33

to the build system? You

43:35

could argue the responsibility is in the compiler itself

43:37

if it can actually work out. Because I think

43:40

in order to resolve those imports, it's going

43:42

to have to locate some files and

43:44

also compile them in order to be

43:47

able to produce code.

43:50

So I think the answer is

43:52

that we still obviously need

43:55

to see these working without

43:57

build systems being involved, if I'm honest.

43:59

level, how does it work and the

44:02

implementations, and then some building on top

44:04

of that. So I think CMake now is

44:06

making a lot of effort in integrating modules as well.

44:09

So I think that will be

44:11

very good for us, especially from the

44:13

package management side of things, to get visibility

44:15

on and see, okay, what do we need to change about

44:18

our model

44:18

to fit the new world of C++ modules?

44:22

I don't, to be honest, I

44:24

don't know yet, because what's a bit exciting

44:27

about following modules

44:29

is that there were things that

44:31

were unforeseen in a way,

44:32

that are now coming to the surface when

44:34

things are being implemented,

44:36

and they're not easy to solve. Again, part of

44:38

the same problem of there's no standard

44:40

way to invoke a compiler or interact

44:43

with the build system. And now,

44:45

modules is forcing that a little bit, which

44:47

I think is a good thing. But it depends

44:49

on what solutions we end up coming up with,

44:51

to be honest. All right. So if you, if

44:53

I have like my own open

44:56

source C++ library, you think it's probably a bit

44:58

too early to put a lot of effort into modularizing

45:00

it. If you haven't, you want

45:02

to say go ahead. If you don't

45:04

today, then we're probably going to be

45:06

using modules in like 2030, right? We

45:09

should like, I'd say go for it. That's optimistic.

45:14

I suppose you may want to, and

45:16

this is a trade off, right? You may want to

45:19

also allow your users to use your

45:22

library without modules.

45:23

So that duplicates the efforts. It's definitely

45:25

a trade off, but I'm always more like

45:28

if it's, if it's

45:30

being approved in a standard,

45:33

and it's the compiler has support, I

45:35

will use it done, you know, be

45:38

the change that you want to see.

45:40

Yeah, that's a good attitude. I like that.

45:42

I'm going to go and play with modules later today.

45:47

So you mentioned a couple of times that we need

45:49

more standardization on

45:52

some of these tolling aspects, but the problem is, of course,

45:56

the standard doesn't talk about any

45:58

of those things.

45:59

can't by design.

46:01

But I know a few years ago, we just set

46:03

up the Tallings study group. Forget

46:06

which SG it is now.

46:08

I think.

46:09

Yeah, yeah, I think that's the one.

46:12

One of the

46:14

tasks they had early on was

46:16

to produce an ecosystem report and I know some work

46:18

went into that.

46:20

And I think,

46:21

I remember rightly, it sort of fizzled out a bit just

46:23

pre-pandemic. And I haven't kept track

46:25

to see whether that's been picked up again yet. Do I really

46:28

know if

46:28

anything's moved forward on that?

46:31

I think there's a movement

46:34

on that front. And there is a proposal

46:37

indeed to have a proper standard

46:39

for ecosystem related things.

46:42

But things move slowly. And I actually

46:44

have to update myself on this.

46:47

But absolutely, I think when we went

46:49

in CPPCON last year,

46:52

there's definitely whispers of finally

46:56

moving along with this. And I have seen that

46:58

I think one of those documents about ecosystem and

47:01

looking at that, I say, okay, these

47:03

are the right levels of extraction.

47:06

So what do we do next? And

47:09

one of the things that, and again, even if you

47:11

have a really good standard

47:15

that ticks all the boxes, then next challenge

47:17

is the community actually

47:20

implementing it.

47:22

And we still have

47:24

lots of libraries that we see that use auto

47:26

tools, for instance. And those

47:30

things have not changed that much

47:32

in many, many, many years.

47:34

So it does beg the question is like, how

47:36

far can you get

47:38

when there's like decades

47:40

of legacy in the C++ community?

47:43

And I suppose I don't know, I tried to remain

47:45

optimistic. So like, as I was able to see, but

47:47

we have to try, right? So I can actually

47:50

add maybe a little bit more to this. So at the last

47:52

couple of committee meetings, I actually

47:55

dipped into the SG15

47:57

meetings and because I was just kind of curious

47:59

what's going on. So right

48:01

now they're aiming to write

48:03

not just an ecosystem

48:06

technical report, but actually come up with

48:08

an ecosystem international standard.

48:11

So it's kind of still early

48:13

days, but there is like a

48:14

paper that's kind of setting out

48:17

the goals and what they're trying to do. It's P2656.

48:19

You're going

48:21

to add the link to the show notes.

48:23

And they're kind of starting with a

48:26

bit

48:27

more modest goals. They're not saying we're going to standardize

48:30

the whole kind

48:31

of package management, build system, everything.

48:34

But they're saying, okay, let's standardize like a

48:36

minimum set of like recognized file extensions,

48:38

right? Because like one problem is that, for

48:41

example, especially with modules, like I don't

48:43

think compilers agree on like what

48:45

the file endings are for like binary

48:47

module interfaces and C++ files

48:50

and C++ module, like header units and whatever. So

48:54

let's standardize that. Let's standardize

48:56

some inter-operation between build system and

48:59

package manager. So I guess that's going to be relevant

49:01

for you at some point. So not standardize

49:03

the interface to the actual build system or the

49:05

package manager, but like just some kind of

49:08

meta

49:10

language or something.

49:14

It can be as simple as JSON

49:16

or something

49:17

like with which the build

49:20

system and the package manager can talk to each other.

49:23

And let's standardize a

49:25

portable diagnostics format. That's I think

49:27

the other thing that you're looking into.

49:29

And yeah, so it's I think

49:32

relatively early days. Last time I was

49:34

in one of their meetings, I didn't actually understand

49:36

what was going on. They were talking about

49:39

different compiler flags on Visual Studio

49:41

and GCC for like four hours

49:43

and how like this introduces

49:45

like really subtle problems

49:48

that somehow related to modules. And I just really

49:50

couldn't follow it, to be honest. But

49:53

I think they were just like very deep and like very particular

49:55

rabbit hole at the time. But like, yeah,

49:57

this this paper, that's.

50:00

That's happening, that's work that's going on. So

50:02

I'm actually really curious. I think that sounds

50:04

like a good first step forward.

50:06

Absolutely. I think I'm

50:09

very interested in exactly the

50:11

bit that you described, which is

50:13

the interface between the build system

50:15

and the package manager.

50:16

It doesn't have to be the world. We don't

50:19

need to standardize everything.

50:20

But even just that, from

50:23

the consumer side of things, we

50:25

do have really good

50:27

solutions to some extent. If you're using

50:29

CMake and the library you're consuming

50:31

uses CMake as well, and it generates a CMake config

50:33

file, then you're good.

50:35

But what if it doesn't? What if it's using something

50:37

else?

50:38

What if it's using the

50:40

package config files?

50:42

And how you do

50:44

that in multiple systems?

50:47

Linux, Mac OS, Windows, when things may be installed

50:49

in different places, and you may want to work with different

50:51

versions of the same library across

50:53

maybe different projects, or even

50:56

in the same project in multiple branches using different

50:58

versions. It's

51:00

those things that I'm more interested

51:02

in to see

51:04

progress, to be honest, because that's going to solve a lot

51:06

of the

51:07

maintenance burden that at the moment falls into

51:09

the package repository maintenance. So

51:13

I think it's fair to say there's a lot of challenges ahead.

51:15

Oh, absolutely, yeah. In summary. We'll

51:17

keep us busy.

51:19

Before we round out the discussion

51:22

on package management and Conan,

51:24

I've actually saved the most important

51:26

question for last.

51:28

And that's why is it called Conan?

51:31

Oh, do you know what? I

51:33

don't remember. I think it's

51:35

a play on Conan the

51:38

Barbarian. So this

51:40

is Conan the Librarian.

51:44

I

51:44

was surprised to have a few people actually get that one. Yeah,

51:47

I remember there was a t-shirt at some point that

51:50

you were giving away for a while with like kind

51:52

of a giant humanoid frog dressed

51:54

up like Conan the

51:57

Barbarian with a sword and everything.

51:59

I still see a lot of people

52:01

running around with those at conferences. It's a shame I

52:03

never got one of those. So if

52:05

you ever have a new edition of those

52:07

t-shirts, then I would be interested in having

52:09

one because I think it's awesome. I'll see if we can find

52:12

the one you described. We might have some some

52:14

leftover. Because obviously I'm a big fan of Conan the Barbarian.

52:17

Yeah, I think I've got that t-shirt.

52:19

I know, it's a good one, right?

52:23

Yeah,

52:24

right. So I

52:26

guess I have one more question for you, Luis, which

52:29

is, apart from all of the stuff, like

52:32

dependency managers, package managers, is there anything

52:34

else in C++ that you think is really exciting?

52:38

Yes, when I

52:40

started using C++, which is about 2010, if I'm not mistaken,

52:47

it's a lot easier now to

52:49

use new versions of compilers,

52:52

use new C++ standards, standard

52:55

versions. So there's like a K in it, so every few years

52:57

there's a new release. That used to be a nightmare.

53:00

And if I'm allowed to use that word,

53:03

you companies would take

53:05

years to move from one version of a compiler

53:08

to another, to move

53:10

between versions of the C++ standard.

53:13

I think

53:14

now it's a lot easier. And it's not

53:17

just one thing that's contributed to this. It's everything,

53:19

right? There's a better cadence in the

53:22

standards being released. The community

53:24

is really

53:26

good at using the new features, providing

53:28

feedback. I think there's a good process there when it comes

53:30

to the standard itself. But the compilers as

53:32

well, I like the sort of the

53:35

healthy competition between GCC, Clang, and

53:37

Visual Studio as well.

53:39

And the package managers being part

53:41

of ecosystem and CMake having continued

53:44

evolving, to be honest. And a lot of library

53:46

authors choose CMake for that. So I think it's a lot

53:49

easier to use C++ these days,

53:51

if I'm honest. So what's exciting

53:53

is that that means that it's a lot easier

53:55

to use the new features. And

53:58

I think we all love this. I mean... I obviously,

54:01

as you mentioned before, Conan has written in Python now, so

54:03

I'm not directly writing C++ code myself,

54:06

but it's

54:07

like I said, I think if

54:09

developers, and whether they're in an

54:12

enterprise environment or open source, if

54:14

they want to use the new C++ features, it's

54:16

a lot easier to do that, and

54:18

there's a lot less sort of effort

54:21

involved in that.

54:22

But to me, that's exciting. Just like

54:24

the C++ today is basically a different language

54:26

than if you look at the code that people are writing today, it's

54:29

just

54:29

completely different than it was 10 years ago.

54:32

Yeah, with C++11, there's

54:35

been a big influx of new C++

54:37

developers who never really had to

54:40

deal with C++ before C++11.

54:42

And it's not always obvious that

54:45

because there was effectively no standard

54:47

between C++98 and C++11, there was O3, but

54:50

that wasn't really a big change. So

54:54

for 13 years, the

54:56

standard didn't change effectively.

54:59

And people got used to that stability, and that became

55:01

almost like defining characteristic of the language, both

55:03

good and bad. And then that would change

55:05

overnight, and it's become completely different.

55:09

It's a very different world. Yeah, interesting

55:11

because I'm one of those people you just mentioned who joined.

55:14

I kind of after all this, I

55:16

started writing C++ in 2010, if

55:19

I remember correctly, but

55:20

before that, I was just writing like C and Fortran.

55:24

And so I started in 2010 at that point, like

55:26

C++11 was kind of already around, it was called

55:28

C++OX, but

55:31

like GCC already had the flags, C,

55:33

P, U, X, and it already had a lot of features.

55:35

So I kind of immediately started learning C++11,

55:39

and I never really actually had to write

55:41

C++98 code like ever. So

55:45

it's kind of interesting to hear that this, it's been

55:47

a thing. Or

55:51

it was a thing. There

55:53

was a very brief window where it was called

55:55

C++1X. Right, right, right.

55:58

Oh yeah, that's true.

55:59

Yeah. Yeah. That's kind of around the time when I

56:02

started using it, I think. All right. OK,

56:05

so Luis, anything else you want to tell us before

56:07

we let you go?

56:09

Not really, no. So obviously,

56:12

everybody's welcome to try out

56:14

Conan 2.0. And we're very open to

56:16

feedback, issues on GitHub. You

56:18

can reach out to us on Slack

56:21

and on multiple channels. So by all means,

56:24

Conan is made by a very small team in

56:27

Madrid.

56:28

And we're very happy to be a part of the community

56:30

as well. But we wouldn't be able to do it without all

56:32

the feedback we get from our users. So

56:35

a big thanks to everybody using Conan and

56:38

opening issues and helping us make

56:40

it better for other users as well. And

56:42

a massive thanks to our open source

56:44

contributors as well, both in Conan and Conan's head.

56:48

Well, thank you so much for coming on and

56:50

telling us all about

56:51

Conan and Conan 2.0 and

56:53

all of the issues around it. So thank

56:55

you for having me.

56:58

Is there any way that people can

57:00

reach you if they want to find out more?

57:02

Absolutely, yeah. So for Conan, you

57:04

can check out our Twitter account, which I think it's

57:07

Conan underscore IO.

57:09

And I'm jcar87 on GitHub.

57:13

And I'm Julius

57:15

on CppLang Slack,

57:18

I think, and many, many places

57:21

as well. So we'll put those in the show

57:23

notes as well. So perfect. No worries. So yeah,

57:25

thank you. All right. Thank you so much, Louis, for

57:27

being our guest today. Thank you. Thanks

57:30

so much for listening in as we chat about C++. We'd

57:33

love to hear what you think of the podcast. Please

57:35

let us know if we're discussing the stuff you're interested

57:38

in. Or if you have a suggestion for

57:40

a guest or topic, we'd love to hear about that

57:42

too. You can email all your thoughts to

57:44

feedback at CppCast.com. We'd

57:47

also appreciate it if you can follow CppCast

57:49

on Twitter or Mastodon. You can

57:51

also follow me and Phil individually on

57:53

Twitter or Mastodon. All those links, as

57:55

well as the show notes, can be found on the podcast

57:58

website at CppCast.com.

57:59

The

58:02

theme music for this episode was provided by podcastthemes.com