CppCast - Professional CMake

Episode Date: September 5, 2019

Rob and Jason are joined by Craig Scott. They first discuss a recent blog post from PVS-Studio analyzing some bugs in CMake. Then Craig talks about how he got involved in CMake development, and his e-book 'Professional CMake: A Practical Guide.' News CMake: the Case when the Project's Quality is Unforgivable PVS Studio The Last Line Effect Serenity: Graphical x86 operating system written entirely in C++ Talks and Speakers of Meeting C++ 2019 are online Links "Professional CMake: A Practical Guide" CppCon: Deep CMake for Library Authors Publishing Effective Modern C++, Part 1 Sponsors Enter #cppcast in the Message field and get a month-license instead of 7-day license PVS-Studio PVS-Studio Twitter JetBrains

Episode 213 of CppCast with guest Craig Scott recorded August 26, 2019. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio static analysis tool. And by JetBrains, makers of smart IDEs to simplify your challenging tasks and automate the routine ones. Exclusively for CppCast, JetBrains is offering a 25% discount for a yearly individual license, new or update, on the C++ tool of your choice, C-Line, ReSharper C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at www.jetbrains.com. CppCast is also sponsored by CppCon,

the annual week-long face-to-face gathering for the entire C++ community. Come join us in Aurora, Colorado, September 15th to 20th. In this episode, we talk about bugs in CMake. Then we talk to Craig Scott. Craig talks to us about his contributions to CMake and his book, Professional CMake, A Practical Guide. Welcome to episode 213 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving. Joined by my co-host, Jason Turner. Jason, how's it going today?

I'm all right, Rob. How are you doing? I'm doing okay. Kids are feeling better. Back to school today. So, yeah. That's not bad then last only a couple of days huh yeah yeah it could have been worse they just had a very boring weekend

before going back to school oh wow it happens yeah how are things going never uh good i mean yesterday it's like the uh city decided or the weather decided it's going to make its last hurrah for 99 degrees whatever let's see what is that like 38 or whatever and no something like that in celsius whatever um i think that's about right uh but then today it's going to be like cool and it looks like the weather is going to be great for cbp con in a couple of weeks so it should should be nice sunny days and not crazy hot any day. Nice. How's your conference prep going? I think I'm ready for TechTown. And I am almost ready for CBPCon.

Okay. I should mention, I think we mentioned a few weeks ago that everyone going to CBPCon should get some stickers from us. We also ordered some shirts so look for jason and i and we will hopefully have some shirts to give away at cppcon and we bought both men's and women's shirts this year for the first time yes i was gonna say so if you prefer women's style yeah make sure you ask us i mean we didn't buy very many of them no we did buy more men's shirts, but yeah, we got some of both. Yeah. Okay. Well, at Top Verde, I'd sort of like to read a piece of feedback.

This week, we got an email from Ben saying, I love the podcast. It helps me stay up to date. I would love to hear interviews with people involved in Intel's TBB, Concurrency Library, which is Thread Building Blocks, and the OpenVDB Spatial Data Structure Library. So those both sound like good suggestions. I can concurrency library which is thread building blocks and the OpenVDB spatial data structure library

so those both sound like good suggestions I can look into whether we can find someone interested in talking about either of those topics I looked at OpenVDB a little bit and it looks like it's mostly like for creating particle effects like cloud and waters

and you know dust effects that are used in like movies like animated movies yeah that looks like fun yeah yeah so we'll see if we can get someone uh interested in talking about those on the show sometime yeah yeah well we'd love to hear your thoughts about the show you can always reach out to us on facebook twitter or email us at feedback at cpcast.com and don't forget forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Craig Scott. Craig is a CMake co-maintainer and author of the book Professional CMake, A Practical Guide.

He has been developing cross-platform C++ software since 2001, targeting most major platforms and working on large-scale frameworks, scientific algorithm development, Qt or Qt GUI applications, back-end services, and embedded devices. He's been fortunate enough to work in a range of settings, including government research, consumer electronics, mid-size enterprise, and a startup. He derives on reasonable levels of satisfaction from automating software build and CI processes, making them more efficient, more robust, and easier for developers to use. Craig, welcome to the show. Hello. That's a bit of a mouthful.

I find the dates fascinating to me because I also began doing cross-platform C++ development in 2001, and you really just don't find that many people who have spent a career in the cross-platform kind of world. Yeah, especially from that long ago. I think it's just the number of platforms that are around then compared to now, it's so different as well in some ways. So, yeah, a bit scary. I don't necessarily want to admit to some of the things I was working on back then, but that's life.

Deck Alpha, anybody? What was that, sorry? Deck Alpha, anybody? Oh, no, yeah, I never worked on a deck. Yeah, didn't miss a whole lot. Okay, well, Craig, we've got a couple news articles to discuss. Feel free to comment on any of these, and we'll start talking more about your work with CMake and everything else, okay?

Sure. Okay, speaking of CMake, this first article is from PVS Studio, and it's CMake, the case when the project's quality is unforgivable, which I'm sure was not a great headline for the CMake team to read. But PVS Studio did manage to find quite a few bugs in the CMake source code. There's several that we could talk about. I mean, this first one, I was surprised that they have a test for but it's um a misspelled uh macro name so you know the min gw 32 macro with double underscores on either side and at one point um there's a check for it in the cmake code where it only had one trailing underscore instead of two and uh yeah that's some interesting ones in that set Part of the tricky one with this is that CMake vendors

A few different third-party dependencies as well And so it's picking up not just CMake issues But also some of these other ones as well But the ones that did pick up were quite interesting From the point of view of CMake CMake has a lot of testing that happens nightly different compilers, different platforms and they need to

compile clean with no warning so it was actually quite surprising to see these different things being picked up so this is PVS Studio picking up stuff that the compiler themselves aren't even warning about so that was quite interesting. Have you already looked to address some of

these warnings i mean i know the blog post is is pretty recent just like uh yeah just a little over a week so yeah they've actually been pretty well um looked into i think there's already been one of the upstream projects there's already um pull request in for that the ones that are actually in cmake itself um they've already been addressed. I'm not sure if it's been merged yet, but it's at least going through nightly testing. So there's actually a few people interested in these sort of static analysis, code analysis type tools. So when something like this comes along, it gets a bit of interest and people really like to have a look at what's going on. So yeah, it's kind of cool and gets addressed pretty fast. I always find these articles from the pbs studio team interesting seriously like and some of them like put potential resource

leaks ones in here like i have to read it like three times and be like oh i see if it returns out here and doesn't pass the value down to this line oh okay yeah potential resource leak i'm impressed that the tool finds these things. In that particular case, I think that was the only spurious one that it actually came up with. The one that I identify as a resource leak, it's actually handled differently, but the code's been updated to no longer treat with that.

But the rest of the warnings, as far as I'm aware, yeah, they actually were genuine ones. So that's a pretty good hit rate. Yeah. Yeah, one of these other ones I was impressed by was the uninitialized pointer being used where you're getting a copy constructor and instead of initializing the string

with the string from the copy constructor, you're actually initializing it with itself, which is a pretty nasty bug. Yeah, I think there was another one in there as well. Like we had one block of code in an if condition, and then the code that followed it was effectively the same code. It's just the way that the code had evolved. And it's not something that a compiler would warn you about.

But it picked up that and identified that, hey, this is doing basically the same thing. So that's pretty cool. Yeah. Yeah. Any other, like, specific items either of you wanted to look at? I just like the concept of how did the code get like that? When you see the thing that it points out, you look at it,

and it's like, yeah, kind of, it's pretty barefaced in some cases, but I think just because of the way the code evolves, a little bit from one person, maybe five years later, another person chips in a little bit. No one really sees the whole entirety of it you know not specifically this article but there is one referenced as a related article down at the bottom of the page called the last line effect and it's from 2014 which is before we started paying attention to the pbs studio blog i think rob and this one is a really fascinating look that like it over and over

and over and over again if you have examples of like um a copy and like code that was clearly written by copy and pasting because it's doing the same thing with just a couple of different variables or whatever like four times in a row there's like a 40 chance that the or not yeah something like that it's like a really high chance that the mistake will be in the last copy paste, not in one of the ones in the middle. And like he runs through the numbers and you're like, what, what? Oh, wow. That's amazing. Amazing and scary.

Yeah. Well, I don't know. Like you're like, yeah, yeah, yeah, yeah, yeah. Okay. I'm done now. And just like forget to check the last line or something, I don't know. Like, you're like, yeah, yeah, yeah, yeah, yeah. Okay, I'm done now. And just, like, forget to check the last line or something. I don't know. Yeah, they're always good articles.

Yeah, definitely. Okay, the next thing we have here is a GitHub repo with a new operating system that was written entirely in C++. And it's called the Serenity OS. I saw this on the Reddit, CPP subreddit. that was written entirely in C++. And it's called the Serenity OS. I saw this on the Reddit, CPP subreddit. And I didn't look too much into the code, but he's got a screenshot of his operating system running, and it looks a lot like kind of a classic Linux OS.

But congratulations for this person for writing their own operating system in C++. It covers a lot of stuff, too. If you look at the various things that have been implemented, it's a pretty impressive list. Yeah, and he said he did it without any formal training in kernels or anything like that. Wow. I'm trying to figure out when that actually started work

because it's been nearly 4,000 commits to it and 25 contributors, so it wasn't just overnight or anything. Right. Yeah, I was actually intrigued by the second contributor, Robin Birchall. I've heard that name before. I went looking up who it was and involved with Jolla and Qt and Qtoth

and those sort of things. It was kind of interesting. So it's got some interesting people involved. Yeah, it's been worked on definitely for well over a year. I'm not sure exactly when it started, though. Yeah, I mean, who doesn't want to make their own complete OS with GUI from scratch in C++? I know, I've always wanted to.

But I haven't actually sat down and done it. Well, you could always look at this one and contribute to it instead of starting from scratch. Yeah, no, that takes the fun out of it, though. I haven't started from scratch, so I'm going to do it. It's actually part of why I made the arm emulator that i did just so that i could say like i basically made a computer from scratch and started you know i still have to write the operating system for my arm emulator though right right okay uh and the last thing to talk about

is the meeting c++ 2019 uh schedule has been. You can now look at all the talks, keynotes, and speakers. It's all up there now. Any of these talks jump out at you, Rob? The first one is another edition of Hana's compile time regular expressions talk.

How many iterations and how many versions of the library has she made now? Every time she redoes this talk, I think she's re-imple of the library has she made now i mean uh because every time she redoes this talk i think she's like re-implemented the library more or less well no i don't think she re-implements it from scratch because it's it's far too complex now but but she makes changes every time every time she makes talks uh it's new um and this is has to be at least the fifth iteration of the talk yeah and i And I love that, because I don't remember this ever being, meeting C++ before, maybe I just never paid attention,

that it says the audience level, beginner, intermediate, or advanced. And most of the talks are like, oh, they're good for all levels. Her talk, advanced. Yeah. I think I might have to have a little, I don't know, some sort of a throwdown with Arna here because he's got fantastic code smells and how to find them. And the talk that I'm getting ready to give at TechTown

is C++ code smells. And I don't know what his conclusion is going to be. I know what my conclusion is as to what the most important code smells are and what we should look for. But I would be very curious to see how that how we compare yeah you have to have a chat with him about what what code smells he's looking at is there a reason why he misspelled fantastic spelled with a ph that kind of jumped out at

me i wasn't sure if there was a meaning behind that i don't know i assumed it might have been uh just german to English, kind of. I noticed a couple of other title things that were just things that a native English speaker wouldn't have done. And I don't know, again, if some of them were meant to be ironic or puns or some of them were just unintentional. My personal favorite is The Dawn of a New Era. They should have an award for the most amusing titles. Phil Nash. Phil's great at titles.

Yes, yes, and great at puns. And he'll listen to this episode. I know he will. Yes, Phil, your top titles, we notice them. Okay. your talk titles we notice them okay and i don't think we mentioned the keynotes but there's an opening keynote from howard hennant on uh actually i don't think he they list titles for keynotes and then one from francis blue tempo i don't think we've had talked about before on the show and then a closing from walter brown i don't recognize that name. Yeah.

Okay. I'm sorry. Where did you see the list of keynotes? It's, I think I had to click on the main meetings people's plus 2019 and go into speaker. Oh no, I don't know. Oh, I see. Yeah. From the schedule, from the schedule, you can see it at least anyhow.

Okay. I got it. Yeah. Right. Cool. Okay. Okay. the schedule from the schedule you can see it at least anyhow okay i got it yeah right cool okay well craig uh do you want to start off by telling us how you got involved in cmake yeah sure um so fairly early on in the 2000s i was dealing a lot with cross-platform software so going through the gamut of build systems doing the auto auto tools, SCONs, QMake, eventually landed with CMake. We were dealing with Windows, Mac, Linux, Decalpha, but we also had C++, we had Fortran, we had Qt.

So trying to find something that could deal with all those different combinations. Eventually, so we hit on CMake and it was like was like okay this is something that's going to hit the bill and pretty much every employer I've been at since then Seamaker has been the build system so yeah it was just kind of like got into it that way then I think about five years ago I started blogging about things just as a as my own kind of personal interest thing. And then it was a case of, actually, I like this. It was kind of fun. I started writing about the CMake sort of stuff as well, and that was pretty cool.

And I was finding it a kind of weird situation where I'd be at work, people would be asking about stuff, I'd write a blog about it, and I could use that to help teach my colleagues and so forth. So I kind of got into that in a fun sort of way. But I think the real thing that got me involved was when a colleague had a problem and it kind of buried itself in my head and I was like, I need to have a crack at this. We had test cases that needed to run where they would set up some things before they ran, like start up some servers, run the test case, and then clean up afterwards. And CMake has a feature where you can rerun failed tests, which is great, except when you rerun only the test that failed, it doesn't also run the bit before it that starts up a server, and the bit that comes after it and closes down a server. A bit of a problem when you're trying to set up your CI builds.

Right. So that sort of buried itself in my head, and it's like, okay, I might have a crack at this, and that was where I got into sort of more into the CMake code base and working out how it worked under the covers, and that eventually turned into the test fixture support that's in CMake now. So that was kind of like my entry into CMake and how I kind of got into it. But the why I stayed part is actually kind of, I think, more interesting. CMake community is one of the most positive and encouraging communities I think I've been involved with

from a software development point of view. I was really impressed when I was doing these things. Everybody makes maybe mistakes and whatnot, but it was a very encouraging and well-run community. The infrastructure behind it was also really cool. It was really easy to do issue reporting and merge requests and all that sort of stuff. So I think I came because it was interesting,

and I stayed just because the environment was very positive and very fostering. It was very well run. That's cool. Yeah. If you don't mind, I'm kind of curious, just for some context, what kind of software you were working on that used Qt and was on a bunch of different operating solvers and then some pre and post processing, 3D visualization, kind of a whole gamut of things. It was like a whole framework with tools that went around that. It's eventually grown into an entire graphical workflow framework that you can build commercial products around so yeah since then

there's been um video camera toolkits and factory processing tools and things like that yeah all sorts of different stuff i find it you said that you went the gamut like i i started with make files and automake and and i i want sometimes tell people, people who say today that they prefer makefiles, that you've never actually done cross-platform development, because it's way too difficult to deal with with plain makefiles. And you said you just ended up landing on CMake because it seems it was the tool that finally worked. Is that basically how you... Yeah, basically it had the broadest coverage of platforms, languages, features for toolkits, dealing with other packages that you rely on and bring into your build. Obviously, it's gotten a lot better since then, but at the time, there was really nothing that could compete with that breadth.

How did you go from blogging and contributing to CMake to writing your own book? Yeah, it was kind of almost a natural progression in many respects. Because I was enjoying blogging so much, it was a case of I'm enjoying the writing side. But also, there was just such a huge gap. It had been a long time since the Mastering CMake book had come out. It hadn't been kept updated. And nothing else had really appeared. So there was this big vacuum of anything that was half-decent and modern showing the best way to do current practice and make the most of recent CMake features.

And it stayed that way for an awful long time. So in the end, I thought, well, better than watching TV every night and on the weekend, I want to do something useful and write a book. And yeah, that's pretty much how it happens. So yeah, a lot of fun along the way. I guess, since we just mentioned the book, what is the title of your book? And, you know, tell us about it some more. Sure. So Professional Seake, a practical guide. It's basically intended to be a logical, structured way to learn CMake. So basically you can go from, okay, I'm just getting into CMake,

never seen it before, through to, okay, I've been using it for a while. I need to know how to do some of the more trickier bits and the advanced bits, through to, okay, I really need to get the advanced packages, all the different platforms, make sure things work robustly, contest all the stuff. So it takes you right from the beginning through to getting a complete product out at the end is kind of the intention. But it has a more practical focus. So each chapter has a recommended practices section, which is kind of like summarizes the main key points for that thing.

It seems to be one of the things that people get the most value out of from what I hear. But yeah, it's always a bit of a black hole of what are people really looking for and what are they finding useful. So it's always great when people tell you, yeah, I've been looking at this part and this part was useful and whatnot. So that's always good. And is it an e-book or a print or either?

Yeah, interesting story behind that. So it's only available in electronic form. And there's a couple of reasons for that. So I knew up front that this was going to be something that would change fairly frequently. CMake is an evolving package. It has, on average, about three feature releases a year, which is a pretty snappy rate. And part of the problem with CMake material in the past

is it gets out of date. So I knew up front that there were going to be updates fairly often. And so I needed to ensure that I had the ability to put out updates and things at a fairly easy and frequent pace. Also, it takes a lot more work to distribute printed material. If it's digital form, it's not only easier to produce an update, but it's also relatively easy to distribute. So that was one of the reasons but yeah also at the time looking at whether to go the publisher route or to do the self publishing angle

obviously digital it's easier from the self publishing part and for various reasons I eventually did get decide to do the self publishing thing there's the tools available for that now are surprisingly powerful and easy to use it's it's definitely doable to do your own self-published work. So those are the basic reasons why I've gone the digital version. For those who are interested in the book writing part, there's an excellent article that Scott Myers put out a few years ago. He went into great detail about the publishing process,

the costs involved, the royalties, why you might or might not want to do the self-publishing thing, why he did what he did. It was a really, really illuminating article called Publishing Effective Modern C++ Part 1. I really, really recommend it to read for anyone who's considering writing a book. It was very, very helpful for me me i feel like i read that article but i don't remember anything about it yeah i had

to go back and reread it again just before doing the interview just to remind myself of all the different things that it pointed out he wrote a few articles around that time was about the time where i think he was retiring, and he wrote a number of articles which were really illuminating, but that's the one that really stood out for me around that time. And he had been using, let's see if I have this right, Addison Wesley

for most of his publication, and then switched to O'Reilly for his last book, so that comes into play, I believe. Yeah, yeah. And he talks a little bit about, about that as well. Okay. I'll make sure to put a link to that in the show notes. I wanted to interrupt the discussion for just a moment to talk about the sponsor of this episode of CppCast, the PVS Studio team. The team promotes the practice of writing high quality code,

as well as the methodology of static code analysis. In their blog, you'll find many articles on programming, code security, checks of open source projects, and much more. For example, they've recently posted an article which demonstrates not in theory, but in practice, that many pull requests on GitHub related to bug fixing could have been avoided if code authors regularly use static code analysis. Speaking of which, another recent article shows how to set up

regular runs of the PVS Studio St code analyzer on Travis CI. Links to these publications are in the show notes for this episode. Try PVS Studio. The tool will help you find bugs and potential vulnerabilities in the code of programs written in C, C++, C Sharp, and Java. So, I mean, I bought your book in its first edition um and for me personally i use it as a reference to say okay i know how to do x and y but do i know how to do it today with the current best practices for cmake so i'll go and look at your examples and be like oh okay this is how i should have structured this thing or whatever, instead of doing whatever nonsense I would have been doing from, you know, 17 years of bad habits or 16 years of bad habits or whatever for me here. That's how I personally use it. But I

would like to say it seems that you keep releasing new editions. You said you knew that it was going to be an evolving work. And I get those updates for free, which seems like a killer deal, really. Yeah, so from my point of view, you pay for it once. And in reality, how many people will buy the same book a second time? If they do, it'll be many years later. And in that period, you're out of date.

So my point of view is you pay for it once. You're unlikely to buy it a second time. I'm going to give you all updates. It's no skin off my nose. But you get more up to date and it's better for me, better for you. So that's my philosophy on that. So it's interesting for me to keep updating it because I have to keep on top of things and learn stuff.

So writing the updates is also helpful for me. It's somewhat, I wouldn't say embarrassing to admit this, but on not an infrequent occasion, I'm at work and I'm trying to figure out how to do stuff, and yes, I'll, how do I do that again? Go back to my book. Oh, yeah, I know it's in there somewhere. Do a search.

There it is. It's just, you just can't keep it all in your head. And so you've got to have a place to go back and refer to stuff. Sometimes you go to the CMake documentation, but when you know you've covered that bit before, just go and look it up. It seems like the book covers

everything, so I guess I have to ask a question from the flip side. What does the book not cover? Yeah, so there's plenty of things it doesn't cover, and some of those are chapters that I thought I would have had written and added by now. So it doesn't cover Qt yet. That's the one I'm trying to work on at the moment.

And also, I've got material still to come for covering things like Clang Tidy, CppCheck, and how you can incorporate those things into your build. It doesn't deal with things like Fortran or other languages like that, and I don't yet cover material on CUDA. Those are the kind of the main things I see popping up on mailing lists that would be nice to cover at some point. You can't cover everything for everybody, but you can cover the bulk of things that

the majority of people are likely to come across. And that's my goal. If you try and put everything in there, it just becomes overwhelming. There's already an awful lot there. It's a balancing act. That's one of the hardest things, actually, is to figure out where to draw the line. That's an interesting point, although I wonder how much your line, I would

assume, is continuously moving, since you are continuously updating it, right? You had to draw the line for the first release, but then on the second release, that line's further. Yes? Is that fair? Yes and no. So there will come a point where you have to decide, look, this material no longer needs to be here.

It should be removed. Otherwise, it just keeps growing and growing and growing. So you have to decide at what point something becomes unhelpful to be in the book. You might still mention it more as an aside. Maybe you put a reference to where you can find out about the deprecated things or whatever. So it's a constant balancing act. So every time a release comes out, you have to look at what things need to change. It's still relatively new.

It's only been out a year, so I haven't really had to deal with the removing stuff part yet. But I know that that will come. You've released, I believe, four editions in the first year then. Is that correct? Correct. The fourth edition came out about a month ago. Yeah, I got the email for it and just updated my local download a couple weeks ago. So how much are you changing with each release? How much time do you spend writing new parts or

updating parts of the book? So yeah, for about a month I have no life. So every time there's a new release, the release candidate... It took me a while to work out the pattern, and I think the pattern is this. The release candidate series starts, and at that point I go through all the release notes and see what are the things that will affect people that are new or that are changed. And then I also have to wear my CMake maintainer hat, and I go through and I test most of those things.

So I have to understand what they are, check to make sure they don't have any bugs in them, and then sometimes that means fixing things, updating documentation. Then I get to update the book, and I have to update them in an order where the riskier things that might get pulled, I do last. Occasionally, features do get pulled. It's happened once or twice during the release candidate cycle.

But generally, it takes about four to six weeks for a full release candidate cycle through to release. So for that period, yeah, mostly I'm doing that research, that work, that updating, so that I can put the book out, hopefully soon after the official release. That's my target. I've been careful to never promise that, but that's been the pattern so far.

So have you found bugs in CMake in the course of writing the book? Yeah, for sure. You do come up with things like that. And, you know, they usually aren't particularly big ones. Some of them, they're easy enough that you can fix yourself. Sometimes

they are more, okay, report this as an issue, but it's going to require some deeper work by different people. It's a bit of a mixed bag. A bit of a mixed bag. Okay. I tend to focus more on the user-facing aspects of CMake development more so than the internal guts.

There's a lot of people who really take great pleasure about getting into the nitty-gritty of every little internal bit. I tend to more look at the is this consistent does this make things easier for users is this confusing with this other feature over here where is this going to go in a year or two's time they're kind of more the things that i pick up because i've been working on cmake only in my own time i have to pick and choose what things I get involved with. So that's kind of dictated where I've tended to focus. Yeah, it does sound like, I mean, you're saying you work in CMake on your own time, and this book, it sounds like a lot of time

commitment, presumably outside your normal work hours. Yes, so all this work is outside of my work hours, although I do use a lot of the material and techniques and try them out at work some of the features that i've added to cmake have initially been things that have been developed in in the workplace and we've tried them out for a year or two and evolved them and then i've brought them in but largely the work i do on this is in my own time i have no kids. So it's possible. I don't know how people do this and have children and families. It's just

the time community, it's insane. When I'm teaching, I like to ask my students what their hobbies are, and I will often get answers from students that say, I have two young children. And that's just their answer. And I'm like, you know, that is a perfectly acceptable answer.

I get that you don't have time for all these other things in those cases. Big time commitment. I mean, in order of what parents achieve. Rob, you do the podcast and have two small kids. Yeah. It takes a lot of time sometimes, but I enjoy it. So when we were preparing for this interview, you sent us a link to this one particular pool request for CMake

that you said exposed an interesting bug, and it's simply marking the default generator for your current platform with an asterisk. Yeah, this one's a fun story. So as I mentioned, I typically pick and choose what things I get involved with, and I often pick out things that look like they're documentation related or things of that nature. So this particular merge request was in the similar way that when you do a git branch

and it shows you the current branch has a little asterisk beside it, when you do cmake dash dash help, at the end of that, it lists the generators that are available. And somebody wanted to do a similar thing and put an asterisk next to the default generator. So if you don't specify one, which will you get?

Will you get makefiles? Will you get Ninja? Will you get Visual Studio? Very reasonable request. Yeah. And it looked like the change involved with that didn't take too much. It was kind of manageable.

So I thought, okay, we worked on that and we cleaned it up a bit and we put it into the nightly builds. There's about 150 builds that take place in different combinations of compiles and platforms. 100, wow. I think it's actually at 170 now, but it was about 150 when this happened. I think it's actually at 170 now, but it was about 150 when this happened.

I think that's even bigger than Boost. I think there's a good chance it is. These are a mixture of kitware machines and machines that other people maintain, volunteer machines. And anybody can contribute one. So yeah, out of all

those different nightly builds, there was one that hung. It was like, okay, is this a problem? We often get little spurious failures because these are all different kinds of machines. Maybe the antivirus kicks in or someone runs out of swap space or all sorts of different things can go wrong. So you get used to entertaining little failures like that. And this looked like just another one of those little ones. But it was like, I can't be certain about this one.

So it was over the summer break. So I waited until I came back to off break and people could look at what happened on that particular machine. And it turned out that after exploring various things and different whatnot, it actually exposed that there was a bug in the Visual Studio runtime. And they thought that this bug had already been fixed, but there was actually, and there must have been another variant of it or whatever,

the workaround was to set the locale earlier in the program. So it was a locale-related bug, and it was resulting in loader locking or something along that sort of a line. So just trying to add one single asterisk to help output, not even to the CMake proper, exposed a bug in

Visual Studio. And as it found out later, it also broke the CMake add-in for Node.js, but that's what you get for scraping help output. Okay, so is this code using printf? Is it using cout? Did you say cout? It's just standard printing out of an asterisk,

but that wasn't actually where the bug came. I think it was actually in the initialization setup phase of things where the bug came i think it was actually in the initialization setup phase of things where the bug was being triggered because you could actually trigger it without lib uv or any of that stuff that's involved in cmakes startup phases and things like that so it was it was more just about um the way that the windows calls were being called too early or in the wrong order or just happened to tickle things the right way. I think Visual Studio 2019 Preview 3 was where they fixed it. So, yeah, it was something that seemed so innocuous but turned out to be rather amusing in the end.

This is the kind of thing that's both fascinating and makes me stop and say, how does any of this work at all yeah yeah both scary and amusing at the same time right and to be fair i mean to be clear i'm not making that as a jab towards like the visual studio runtime right maintainers or anything right like it's it's happens on all platforms in various ways. Definitely. So, Craig. That's probably my, yeah, that's my favorite maintainer moment, that one. Yeah.

Right. Craig, you'll be giving a talk at CBCon this year, is that right? Yeah. So, again, with my sort of more practical end user focus, I'll be talking about CMake features for cross-library, cross-platform library authors. More looking at if you're doing cross-platform library development, what are the CMake features that can help you,

but also what's actually happening under the covers at the platform level? What are those platform differences? Why do I need to do some of these things, or why does CMmate present them that way or what's what are the limitations so so talking about things like symbol visibility and how that can be used to hide parts of your api for example talking about how you evolve your api of your library so from release to release how do you manage that? What's happening at the operating system level when you've got multiple versions of your library installed?

How does it deal with those? How does your tooling deal with those? How do people who are packaging your library, what do they have to deal with on different platforms or even just different flavors of platforms? And what can you as a library author do to make it easier to package your library by other people because you're not in control of that and lastly what can you do to make it easy for people to consume your library

specifically cmake projects so it's packing a lot in um but i kind of i looked at this as what would i want to tell earlier developer me who was just starting out trying to do cross-platform library work with CMake. So this is a collection of the stuff I've had to learn the hard way over years in some respects. So what is the title and

time slot of the talk? The title I think is Deep CMake for Library Authors and it's first up on tuesday morning at 9 a.m okay hopefully i'm hopefully i'm over the jet lag by then when are you getting into town uh on the sunday so i should have hopefully enough to at least get close yeah you should probably be pretty close for me personally off topic as far as the podcast goes but i'm okay the day that i

arrive well the day that i arrive i'm exhausted doesn't matter which direction i'm heading the next day i feel fine and then the the third day my second you know after sleeping two nights that's when the jet lag hits me and i'm like i don't even know how i'm still standing upright at the moment yeah well i've got a first thing in the morning talk, so that should be about evening my local time, body clock time. So I'm hoping that I'll still be okay at that point. Two cups of coffee, you'll be fine. Yeah, so if you see me jittering on stage like this, you'll know why. Yes, I will. I'll understand fully.

I'm curious, have you spent much time looking into modules now that we know that's going into C++20? I'm curious how CMake is going to handle modules. Yeah, so I've been watching modules more from the sidelines until just recently. Last year, there was a really detailed discussion on the mailing list between Stephen Kelly and David Blakey. Stephen Kelly did a lot of the work for what we call Modern CMake now,

but they were talking about Clang and how modules and things like that would be handled. And there's been a couple of other nibbles by people who have tried to bring in some form of module support into CMake since then, but nothing that's really kind of materialised into something proper yet. There's already some module support for Fortran, which people are saying will help a lot for the C++ module support, specifically for dealing with working out dependencies. So if you're working on modules in your own project,

you change a file, what other files are going to have to be rebuilt? Those sort of problems. But yeah, I think there's still a whole lot more to be dealt with. It's a pretty sticky kind of task. So there was an article that Richard Smith put out in June, the Packaging C++ Modules title. It scared me a little bit reading through that and just seeing the different things that are going to have to be dealt with just in terms of naming of things alone and how they all get stuck together. We talked about manifest files to link the code

with what's installed in packages and all these sort of things. So it's pretty complex. Yeah, I think there's still a fair bit of work to do. I think there are people from Kitware that are involved with SG15, the tooling working group, I think. Tooling subgroup. I'm sure there is, yeah. Yeah, so I think there's definitely people who are tackling this

and looking at various aspects of it. But, yeah, it's a pretty meaty area to say the least say the least okay uh craig you also mentioned before we uh had you on the show that you're starting a new company or have started a new company recently uh yeah so i just recently created my own uh consulting company having seen how much i've enjoyed working on cmake and build systems and the success of the book, I thought, well, you know, why not make a proper go of it? And so, yeah, I decided to create this consulting company, basically provide services to companies who want to perhaps migrate to CMake or upgrade to better practices, perhaps solve specific build issues.

Some companies can't go to my public mailing lists or Stack Overflow to ask questions for confidentiality reasons, so I can help out in things like that. Perhaps integrating CMakeBuild with CI systems or package creation for different platforms. All the things that are built around that kind of thing. A lot of companies don't have that in-house expertise. So to be able to hire someone in who they know, I'm hoping

that'll be a popular thing. So I thought, yeah, I'll give that a bit of a go. So that's my new focus. So how is that? Are you just at the starting phases of this? Have you already started working with clients? The company only existed as of a couple of weeks ago. So it's still just tidying up to set up phases. I've had some inquiries already just coming out from the book. But yeah, so that's kind of like what's prompted me to

head in that direction. Hopefully the demand will be there to sustain it. I can imagine. I mean, just as a consultant helping, you know, let's see, I'm thinking about one particularly large project that I've worked with. There's been over time, four of us who have poured a considerable amount of time just into maintaining the build system.

And no one person owned it fully during any of that time. But sometimes someone would have to come in and spend two weeks cleaning up some issue just because we don't tend to appreciate that our build system code is code. It needs to be maintained. It needs to be cleaned up. It needs to have old crap removed from it, you know?

Code gardening. Yes. People definitely don't enjoy that work, but for whatever perverse reason it's the sort of stuff i really love so that sounds like a great niche then uh if you can find the thing that other people don't like doing and you like doing it yeah hopefully hopefully that's the plan anyway cool okay well wish you uh good luck with that is there anything else you wanted to go over before we let you go today, Craig?

I think that's probably about it. It's been a pretty fun ride talking about this stuff. So, yeah. Okay. Well, it's been great having you on the show today. Cheers. Thanks, guys. See you at CppCon.

Will do. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at

patreon.com slash cppcast. And of course you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by