CppCast - Vcpkg Registries

Episode Date: February 26, 2021

Rob and Jason are joined by Nicole Mazzuca from Microsoft. They first talk about a differential equation library, and modules support in build2 and meson. Then they talk to Nicole from Microsoft's vcpkg team about some new features in vcpkg to enable teams to host their own libraries. News Solving Differential Equations with LLVM Complete C++20 Modules Support with GCC in build2 Meson Build System 0.57.0 is out w/ experimental suport for C++ Modules, Qt6, ThinLTO and more Links Registries: Bring your own libraries to vcpkg Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies Sponsors PVS-Studio. Write #cppcast in the message field on the download page and get one month license The Evil within the Comparison Functions Top 10 Bugs Found in C++ Projects in 2020

Episode 288 of CppCast with guest Nicole Mazzucca, recorded February 19th, 2021. 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. In this episode, we discuss module support and two build systems. Then we talk to Nicole Mazzucca from Microsoft. Nicole talks to us about new features in the VC package. Welcome to episode 288 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 are you doing today? I'm all right, Rob.

And in fact, I should share, I got fancy speed upgrades on my network. So I don't know know i just thought that was fun i have managed to clock 1.2 gigabits download oh that is exciting that is just once though okay yeah for for our listeners we we do sometimes struggle a little bit with internet connectivity on your side like sometimes your video goes a little bit bad especially at the end of the episode while uploading but uh hopefully that will be a thing in the past and i'm starting to get suspicious it's actually my laptop overheating i'm serious yeah uh and and cpu throttling so next step will be one of those stupid laptop cooling fans and see uh and then i don't know where i'm going from there okay i have not seen those laptop

cooling fans is that really something that would be necessary i don't know where I'm going from there. Okay. I have not seen those laptop cooling fans. Is that really something that would be necessary? I don't know. Well, when I feel the heat of my laptop, that's true. Bottom of my desk. Oh yeah. Okay.

Uh, or through the bottom of the bottom of the top of the desk. Yeah. Then, um, it makes me wonder. Okay. Well,

at the top of every episode, like through the piece of feedback, uh, this week we got an email from artemy and he writes i really like your podcast in one of the latest episodes you've mentioned c++ comma interoperability and how it became easier nowadays i really like to hear more on this topic especially for win32 applications i would think that raymond shen is a good candidate for discussing this topic uh who's of course course, the author of the Old New Thing blog. Looking forward to hearing any new episode of your podcast. Thanks for doing a great job. It'd be great to talk to Raymond Shen. I don't know how available he might make himself for, you know, something like a podcast. I don't,

I'm not aware of him doing any like public speaking, but obviously his blog is very well known. Yeah, I mean, I've been aware of is very well known yeah i mean i've been aware of raymond i think as long as i've been programming at c++ approximately the same era that i learned about herb so yeah he's been around for sure and we've mentioned his article several times on here oh yeah we've had several of his articles in the news over the past few years but uh yeah it's worth at least trying to email him and see if he's interested in coming on. So I will definitely be doing that. Cool.

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 cppcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Nicole Mazzucca. Nicole is a software engineer at Microsoft working on the VC package package manager for C++. She graduated from Western Washington University in 2019 with a degree in mathematics and was hired out of school by Microsoft to work on VC package. Since then,

she both designed and implemented two VC packages, major new features, manifests and registries. She has been involved extensively with Rust in the past and is a founding member and moderator for the Include C++ community. Nicole, welcome back to the show thanks uh hi y'all how are you doing doing good good how are you doing really good we i feel like we should mention due to a slight miscommunication here nicole did not get access to the articles uh so two minutes ago yes um so if if she doesn't have anything to add it's it's our fault yeah uh but yeah so nicole we'll discuss these uh do feel free to comment on any of them and then we'll start talking more about what we mentioned in the bio which is those new vc package features that you worked on okay cool all right so this first one is an article on solving differential equations with lvm and there is a github link in

here the library is called hioka and uh i i have not done differential equations in a very very long time so i don't think this is something i would make use of but uh they're making use of lvm's jit capabilities which we discussed on the show recently right jason yeah that at least came up maybe last time we talked to ben dean i believe that sounds right yeah uh something like that yeah so i mean this looks pretty cool if you're you know into solving differential equations yeah yeah looks looks very cool very powerful i'm sure it is very fast with the uh use of the just in time compilation lvm but um yeah differential equations that just brings back nightmares from my time in college i do not remember you know have good fond memories of that at all nicole's

much closer to university than either of us and nicole you got your degree in math didn't you yeah uh actually i really i had a really good uh differential equations teacher but i still didn't understand any of it uh so i i am not the person to ask about this i prefer things that aren't numbers like numbers too too much for me i don't for reason, I feel like I didn't have to take differential equations. Maybe I did, and I just completely blocked it from my memory. But the highest level math class I recall taking is multivariable calculus. Calc 3 is how it was split up in Virginia Tech. I did computer engineering, not comp sci.

So maybe I was a bit more math for engineering. And my wife has a math degree so i know she took all these things she know her differential equations maybe she can come on yeah why not well i told her what this project was about and she you know seemed to at least think it sounded interesting i guess okay yeah i think it's cool like uh that they're using the JIT for this. It's like the perfect thing to use jets for, you know, it's like, um,

creating programs at runtime and then compiling them. Like, like that's the perfect use case for jets. Yeah, that's true. I think it's neat. Anyways, one of the projects,

I mean, I've mentioned that I do energy simulation stuff with one of my clients. Uh, they've got, uh, energy simulation stuff with one of my clients. They've got some projects that we're integrating on the site right now that does like, not a project that we wrote, but a project that we're using that generates the problem set in like Java and then uses JVM with its JIT to actually then solve the problem. So it's kind of like custom recompiling the problem at the same time too. Yeah, that sounds really cool. The one concern I would have is like, I don't know how fast LLVM's JIT is. I know it's not as well taken care of as Java's or like C-sharps. So I would be

curious if this would be faster if it was doing the same thing with like writing doing jvm or doing clr or doing even like javascript like i would expect that those would be better at this maybe not the javascript one but at least the java and clr one well i mean to be fair the javascript engines are state-of-the-art super fast things I almost think we wonder if anyone is doing that right now, like generating JavaScript source code to get a finely tuned solution to a problem and sending that off to the JIT. What's the word I'm looking for? It would be really cool if you, like in the future when the JITs are better tuned for

WebAssembly, I feel like in the future when the jits are better tuned for um web assembly i feel like wasm would be like the perfect uh outlet for something like this yeah it's an interesting idea all right one of you should work on that let us know how it goes okay uh next thing we have is a post on build 2's website and this is complete C++20 module support with GCC in the newest version of Build2. And it's a pretty good detailed post talking

about exactly what you can do with modules now using Build2, and they have several examples in here. And yeah, if Build2 is your go-to build engine uh it's nice to know they have modules now and uh you know these look like pretty great examples this is interesting because how many times recently have we said on the show that it'll be like 2023 before anyone can actually use

modules because of build system support and stuff but it looks like our they're all coming in yeah starting to at least yeah i think the one thing i'm curious about is uh when when will the build tools be good enough at modules that it actually like makes uh modules worthwhile yeah like obviously modules are worthwhile for the um for the uh hidden stuff but for like compilation speed and improvements yeah yeah that's what i'm most excited about i think is the compilation speed improvements um but i have to compile with g++ uh seven so i'm not going to be able to use modules for the next 10 years seven oh uh and this does mention that currently their support is tied to GCC because GCC has module support now,

but it sounds like it's coming soon to Clang, and as soon as that is in there, the Build 2 support should come for Clang as well, so that's good. Does Build 2 support CL? Yeah, I was just going to ask the same question, actually. I think they don't support modules with CL, but do they support CL at all? I don't support modules with cl but do they support cl at all like i don't really understand build 2 um i saw the syntax and i was like nope i i'd

rather use cmake uh so i i i'd like to know more about build 2 i don't really know anything about it i mean i just went to their FAQ page and it does mention that they work with across different platforms and compilers including GCC, Clang, MSVC and Intel. So I guess they don't have the module support yet, but they do have some support for MSVC.

We've never done an episode devoted to Build 2, have we, Jason? Not that I recall. I'd be super interested. Because like, I want to know what like what what's the benefit of build to over Mason or CMake, which are kind of my favorite build systems. Well, since you mentioned Mason, our other post is from Mason, because they also are adding C++ module support in the newest version, which is release 0.57, although their module support is for Visual Studio.

I'm not sure if they already had it in for GCC or Clang, or I guess probably not Clang, but they're now using C++ Visual Studio's module support. I have a question for Nicole here, because I've only just dabbled in Rust, and I see that both Build2 and Mason are advertising multi-language project support for Rust and C++. And do you just have any gut like reaction to that? Because I mean, versus using Cargo or Crate or, you know, the Cargo

build system or whatever, and usingason with rust and c++ like what do you see here so um i do have thoughts about this but i need to put them in order um i think one thing i know at least i'm pretty sure my knowledge might be out of date so don't you know take this with a grain of salt but um in general cargo is pretty difficult to um integrate into other build systems and mostly i think that's due to cargo wanting to take care of all the dependencies um so mason and build2 supporting Rust. So the really nice thing about Cargo is that it handles all of your dependencies for you. And the unfortunate thing about Cargo is that it handles all your dependencies for you. So it's much harder to kind of integrate with build systems because each kind of sub project in Rust, like let's say you have 10 modules, five of which are C++, two of which are Rust, three of which are C. For the C++ and the C,

you can kind of control their dependencies from outside and deal with that that way. But for the Rust projects, you have much less control over their dependencies. And so having Mason or build two, or I'm hoping in the future CMake, have support for Rust means that you kind of have a lot more control because these tools don't expect to control the dependencies. And it means that you'll be able to integrate a lot easier with multiple Rust sub-projects. Does that kind of make sense? Sure. I think so. Yeah.

And something that I'm interested in, just by virtue of being literally everything is one language and there's no like cross-language projects except with a bunch of frustrating c bindings that you have to write yeah or just maybe having a couple older c files in your otherwise c++ project is yeah it happens yeah like i i think that that's that it's unfortunate that we can't, like, choose languages, especially for Rust C++, languages that do work well with other languages. Not like maybe OCaml that has a runtime, but like, it would be nice to be able to, like, write a module in whatever programming language you want and be able to use it from any programming language. And I think that that's something that, you know, NPM, Rust, or Cargo specifically, don't do that well. But I'm not sure. Like, there's kind of a lot of complexity here. And a lot of questions of like, is it better for the user to have less flexibility, but it's easier to use? or for enterprises especially

like we want more flexibility and we don't care that much about ease of use um right i don't know i mean we see this in the c sharp.net ecosystem right people just mix and match c sharp and f sharp at the very least yeah yeah which i think i I think that's really good. Like I love that part of C sharp and F sharp. And I would like for that world to kind of exist in the systems programming world, because I think that Rust is a really, really good language that I want to see adopted more. Yeah. And that would certainly help with its adoption.

If you could just choose to have some small module or even just a few source files of Rust in your otherwise C++ code base. Yeah, exactly. And I think that Cargo makes that hard. Interesting. Yeah. Okay, well, Nicole, we have had you on the show before,

but it's been quite a while. Yeah. It was four years ago. I think so. And as we mentioned in your bio, you're still in university then. You graduated in 2019. Do you want to tell us a little bit about what's been going on over the past few years? Because you're now with Microsoft.

Apparently I've been dumping my tea on myself. So, yeah. So I think that the last time I was on was before I went to university. Oh, okay. Um, and then I went to NYU, quit after a quarter cause I didn't like NYU and just worked at Starbucks for a year and then got my degree at Western. Um, but during the two summers that I was there, I worked at Microsoft. And first I worked on godbolt.ms. So Compiler Explorer doesn't have Windows servers.

They actually, like, whenever you want to do a build with a Windows compiler, that's not the Wine compiler, but like the actual MSVC, you call out to us us and I implemented that. And then the next year I did just work on VC package. And so I've mostly been working on making the experience in VC package with C++ package management as good as it is in any other language is kind of my raison d'etre. Okay. very cool. Something that has frustrated me for a long time and actually frustrated me back when, like, four years ago

was how annoying it was to have dependencies in C++. And my hope is that with VC package, we are creating, like, a world where C++ developers don't feel like they have to deal with the BS of depending on all of the BS that you know goes into dependency management in C++ and C. Well, we'll talk about specifically what you've worked on there in a minute. But you said that it's basically been four years that it's been frustrating you already. How many more years do you think we have left until you are no longer frustrated by this? I think most people, if they wanted to, could become unfrustrated within the next six months. Six months.

Okay. All right. Then let's get back to what will make us that excited in six months. Yeah. Okay, all right, then let's get back to what will make us that excited in six months. Yeah, like, I think that it's very, if you are a normal developer, like normal open source developer, using VC package will make you happy and like, deal with all your dependencies for you. And it's super nice. It's just getting people to actually like, realize that there's that option and put in the necessary work to actually get that option working. Right. And coming from someone who's worked in the Rust community and is used to using something like Argo,

do you feel like it's a pretty comparable experience using VC package compared to other programming languages that have a built-in package manager? I'd say so, especially if you're using CMake with VC package compared to other programming languages that have a built-in package manager? I'd say so. Especially if you're using CMake with VC package. The difference is mostly in how annoying it is to get set up with developer tools. And installing VC package is still not an amazing experience, but we're working on it. But once you have all of it installed, then the experience of writing a manifest, using the CMake integration is, in my opinion, comparable, if not just as good as using the Rust experience. Except that you have to write two files

because it's CMake plus VCc package you don't have one thing that does both okay so vc package doesn't generate the cmake imports or whatever for you automatically no it doesn't um and and we did design that intentionally that way so that you know something that people have a frustration with in rust and cargogoland is like system developers, like people who work on apt packages. They don't have control over their dependencies. They kind of have to like either hack up Cargo or use Cargo to build the thing and download all the dependencies and do all that.

Whereas in the Linux world, you want to have like one.so that is this specific library. You don't want to have like 10 different library copies. So VC package really supports that well by not trying to like generate the imports in CMake. Like you can choose, if you have a project that uses VC package and it's a well-written project,

you can choose whether to use VC package or to use your system dependencies or even to use a different package manager entirely and that was like a major important thing for us so obviously we've talked about vc package a couple times before on the show uh last year i think we had billy o'neill on and uh we also had some members of the Visual C++ team on during CppCon, including Augustin Popa, and talked about VC Package during both those episodes. What's kind of the latest and greatest since those past two episodes with VC Package?

Yeah, so I'm not sure exactly when those episodes were, but I think Manifest had just landed when those episodes were i think it was at least announced at cpp con yeah when we talked to augustine yeah it's honestly been a while i don't remember but so manifests are implemented they're not technically stable yet you still have to pass a future flag if you're using them from anything that isn't MSBuild or CMake. However, in MSBuild or CMake, you don't have to do anything. Like, in MSBuild, you have to set a variable. But in CMake, you don't have to do anything.

You write a vcpackage.json and put it next to your CMake list. And vcpackage takes care of all of your dependencies for you. It's not experimental with CMake. And we plan on stabilizing it very, very, very soon. Could you back up a little bit more and just give a little more detail about what the manifest feature is? Yeah. So basically, if you've ever used NPM or Cargo, the classic experience for VC package and

a lot of C++ package management solutions has been install your dependencies with like a command line interface and then build your project using those dependencies the manifest mode for vc package what you do is you actually write down a list of your dependencies like i depend on boost i depend on thump i depend on thump. I depend on zlib. And then you put it down in that vcpackage.json. And suddenly, when you run your CMake build system, we install the dependencies for you. And then you can link to them normally. So there's no separate step.

You just configure and build. So when you go to link to these vcpackage install dependencies in your CMake project, what does that look like? I mean, is it just like boost colon colon boost or do you do like VC package colon colon boost or is there some special way that it's imported? No, it's you going like if you remember, we want to be supportive of like not using VC package if you need to. We want to be supportive of not using vcpackage if you need to. We want to be supportive of those system package managers. And so in order to use Boost, you do what you normally do to use Boost if it was a system install package. You find package Boost, and then target link libraries Boost Boost,

or Boost System, or Boost whatever. Right. Funct is find package fumpt, and then target link libraries fumpt colon colon fumpt. You are referring to libformat, I assume? I am, yes. I've never heard anyone pronounce it before. I also say stood

and unique putter. Yeah, by stood and unique putter, I've heard fumpt I hadn't, so I was just making sure. I'm a big fan of ignoring vowels that are not there. And also vowels that are there. And also consonants that are there. Ignoring.

Well, that sounds pretty handy. I'm curious, how does that magic work? Like, if I do find package in CMake, how does it know to find the one that you just installed, a VC package, versus whatever one was installed by ubuntu or whatever by apt well cmake gives really good uh utilities for um for for dealing with this you just said cmake and really good in the same sentence i know i i actually love cmake i think it's stockholm syndrome uh but i work on CMake all the time, and it's a bad

language, but it's a very good library. And Find Package, you can set up your Find Package search paths, and that's how VC Package does it. So it hooks into that. It says, when you go to find boost or whatever, first look in my directory. yeah okay um there's slightly more complexity going on but it's not important to understand for you and for me it's very important and very frustrating but i'm sorry the cynical side of me immediately thought until it breaks because i mean i'm not saying v VC package will break when I go to do this. I'm just saying tools tend to break. Yeah, especially with CMake. But I have used VC package a lot with my own projects. And I know a lot of other people have.

And usually it's pretty dang good. Additionally, you know, if you have an issue uh we are very available like if you go on hash includes c++ discord you can ping any of us uh and we're always happy to fix bugs uh yesterday i introduced a very fun bug and uh it was fixed within like at 11 o'clock at night when someone pinged me on discord and i fixed it. That's unfortunate. You shouldn't be rolling out to production at 11 o'clock. Probably not, but it was an urgent bug. Like it was in Master, so it wasn't like in a release version. Okay.

That's an interesting question by itself. So there are actual specific releases of VC package. We're not supposed to live at head if we're using VC package. You not supposed to live at head if we're using vc package you're supposed to live at head but we're in the process of making it so that you don't so so like vc package has been kind of not experimental not unstable but like we have not implemented specific release we haven't implemented specific slas or anything like that and we're in the process of doing the work to actually stabilize VC package, especially for versioning and registries.

Pre-versioning and registries, everything lived in the same repo. You made changes to the tool. You made changes to the libraries. You made changes to the scripts all at once. And it was totally fine. But with versioning and registries, it's no longer fine to do that anymore. So we're actually now, I'm personally doing the work,

along with Billy and Robert, to make it so that these things are stable. And when we stabilize registries and versioning, all of it will be stable. And we will actually have releases of like DC Packagekgs the tool okay sponsor of this episode of cppcast is the pvs studio team the team develops the pvs studio static code analyzer which detects errors in c c++ c sharp and java code when you use the analyzer

regularly you can spot and fix many errors right after you write new code this means your team is more productive during code reviews and has more time to discuss algorithms and fix many errors right after you write new code. This means your team is more productive during code reviews and has more time to discuss algorithms and high-level errors. Let the analyzer that never gets tired do the tedious work of sifting through the boring parts of code looking for typos. For example, let it check comparison functions. Why comparison functions? Click the link in the podcast description to find out.

Remember that you can extend the PVS Studio trial period from one week to find out. Remember that you can extend the PVS Studio trial period from one week to one month. Just use the CppCast hashtag when requesting your license. So I think you just referenced another new feature that we also mentioned in your bio, which is registries. Do you want to talk some more about that? Yeah. So obviously we have the main VC package package so a registry is like a set of packages basically okay okay so if you've ever used um apt like apt repositories i think is what they're called um yes where you have like sets of packages that you can uh download download and use those packages from those repositories. And vcpackage has the main registry,

which is at Microsoft slash vcpackage on GitHub. And then we haven't really, up to this point, had the ability to nicely have closed-source packages. So if you're an enterprise and you depend on closed source packages, or you depend on your own versions of open source libraries, it's not in the main registry because we only accept like public libraries. So if you have your own private libraries, it hasn't been easy to use those with vcpack. And that's what registries are actually doing,

is they allow you to write your own packages that are internal, that no one will ever see outside of your company, and manage them with VC package. It also allows you to do fun stuff. If you are someone who wants to have experimental libraries that you don't want to publish to the main registry, you can put them in your own kind of registry. What is this?

Yeah, no, it makes sense. But I do want to, I guess, clarify. So right now, currently, all of the packages that vcpackage supports is in basically a monorepo of the vcpackage repo. It has the source code for vcpack package itself and all of its packages that you can import. It did.

So, um, very recently, Billy pushed through the work to actually pull VC package, the tool out into its own repo. So that's at Microsoft slash VC package tool. Um, and then I'm currently doing the work to pull like all of the scripts,

like the helper scripts out into VC package tool as well. Okay. But for now, we're still in the process of doing that. So you can kind of treat them as the same repo. But yeah, did that answer your question? Okay, cool. So when you go to make your own registry then for your internal packages, what does that look like? Do I need to create my own GitHub repository? Can it just be a directory, a subdirectory inside my current project or what? Yes, both.

Okay. We support Git registries, which is what the main repo is, which you have a set of versions of... Sorry, now I'm looking at my background here. No worries. So, Git registries are like the most common, we think, probably people will set up. Okay. And it's just like the main registry.

So, you have a set of packages, and then you have a set of metadata files that tell you where to find the packages in the Git registry. So in order to support versioning, we have a set of metadata that point out at which Git object a specific library at a specific version will be. Oh, interesting. Okay. And so you set up that metadata, you set up the ports backing store, and we call packages ports. They're interchangeable.

And then you just simply write a little configuration file that says, this is the registry where I want these packages from. And you're good. Like you have the packages from that registry. Does VC package today support binary packages? Kind of. So we have the opinion that building from source all the time is the best option. Okay. We think that binary packages are usually a bad idea.

And if you want most of the benefits of binaries, you can get them by caching the results of source builds. And we have support for that. Okay. by caching the results of source builds. And we have support for that. Okay, so if I don't do anything special at all, but I've got VC package, I've got two different projects that both use Boost, and I compile project A with Boost, and then I go and compile project B,

will VC package automatically use the build from project A, or does it build Boost the second time? Yeah, it uses the build from project A. So you don't have to build twice. It has to unpack a zip file into your installed directory, but it's super cheap. I was thinking the way you described using VC package that it will automatically cache those.

I would say in all practicality, even though Conan supports binary packages, all the projects that I work on have special flags that we require for all of our Conan packages that they can't use the binaries anyhow. So I just end up having to build them once on my system regardless. Yeah, exactly. And that's kind of where we're at.

Like there are libraries where it is valid to have binary releases if you don't want to release the source code. Although I would caution any companies from using any libraries where you don't have access to the source code. Pay for your source code license. It will save you down the road. a binary package that doesn't have that, you can always just install the package manually in your port file, which is like the package build instructions, and just like download the binary

and put it where it needs to go. But we would very strongly recommend against doing that because not owning the source code is very bad or not having access to the source code is very bad. This message, unofficially sponsored by breakabicompatibility.com. Is that how it works? Yeah, basically.

I would like us to be able to break ABI. I like breaking ABI. I don't like stdregex. I've been unofficial, like just realized after a few weeks that I basically, or Rob, one of us has basically asked every guest that we've had on for at least three months, whether or not they would be okay with breaking ABI. And so far everyone said for the most part, they would be okay with breaking ABI. So it sounds like you're in the same camp also. Yeah. I mean, I think like part of the nice thing about VC package, I think this is personal speculation. I'm not saying that this is true, but part of the reason why Microsoft has been funding VC package is so that we can kind of look at ABI breaking stuff. Like if we have a

package manager, no one's insisting that we put graphics user interfaces into the standard. Therefore, we don't have to worry about ABI for packages that you get from a package manager like vcpackage. You might worry about

ABI, but Microsoft, the standard library implementer, does not have to worry about it. The topic of graphics packages, I think last timeer, does not have to worry about it. Well, the topic of graphics packages, I think last time I looked at VC package, it didn't have any of these giant projects like Qt in there yet. Does it now? It does, yeah. Okay. Maybe I'm misremembering or it's been a very long time since I last looked. I don't really know anything about VC package past like a year ago when I first started working on it.

Just because I was in university and not doing a lot of C++. Right. So I'm guessing if you're going to set up your own registry because you're in a company and you can't use open source libraries or you want to use your own versions of it, I'm assuming it's very easy to set up your VC package repository with your version of a library that already exists on vc packages uh global registry like you know this is my own version of boost that's

slightly different than regular boost but what if you do have your own purely internal libraries and you want to start sharing them through your vc package registry uh how easy is it to set that up? It's as easy as setting up an internal Git repository. Okay. Yeah. One consideration that you have to make is, so I don't know if you saw this, but about a week ago,

there was a blog post about um breaking companies uh like like security problems with companies using internal packages i did see that actually i know i was kind of thinking about asking you about that yeah yeah so uh i would link that in the show notes but you'll find it we uh we look at things like this we're like no no never ever ever gross we want people to be very very sure of exactly where their packages are coming from and so we require that all of the packages you get from a registry you say that that package comes from that registry we don't do any kind of um like uh recursive registries we don't do any kind of recursive registries. We don't do any kind of automatic lookup.

We expect that people consider exactly where their packages are coming from and write that down because we never want to be in a position where there's a security vulnerability because someone name squatted.

And we want to be able to support multiple registries without any of them ever trampling on each other. Okay, so that's something you can do now with VC package, though? You can pull from multiple registries within the same project if you want to? Like I want this from my personal registry, this one from the global Microsoft one. Yeah, it is experimental, but with feature flags, you can get that behavior.

And I've got some examples in the blog post that will be published or has been published on Monday. Will have been published on Monday. So you can see kind of how one would do this. So we are saying by the time this airs, this article will have been published. Yes. Okay. Just making sure. Yes. The plan is Monday. So if it doesn't happen on Monday, it'll probably happen on Tuesday. And this is an episode we're recording on Friday since all of that will sound a little weird perhaps to our listeners yeah i found myself curious like okay once the package management system is stable do you still get bug reports like what kind of bugs happen in a package manager system you said you just introduced one

in the middle of the night and had to fix it i'm just kind of curious like because i don't know really know anything about writing a package manager. So the bugs that we mostly introduce, or the bugs that I've been introducing, because I've been the one introducing bugs because I've been doing stabilization work, is we have... So the port definition files,

the thing that tells vcpackage how to build a package is written in cmake and the these cmake files have a bunch of helper scripts that they can use and so um so we can introduce bugs by uh breaking the helper scripts and that's what this stabilization effort is doing is making sure that we know exactly which changes we can make and exactly which changes we can't. And this is because we've had the scripts and the ports in the same repository for so long, we never stabilized the interface between them. But since we're pulling it out, now we have to actually consider stabilizing the interface. And as part of that, sometimes things break a little bit. In the case yesterday, I accidentally broke finding packages from your own CMake libraries.

And it was fixed almost immediately. But that happens when you're living life on head, unfortunately. Do you pretty much then just program in CMake? Yes. Full time? Almost. Like probably 75% of the time. That has to make you fairly unique.

I don't think there's very many people who literally just write CMake all the time. Yeah, I think you're right. I know much more about CMake than I think most people do. And most people don't, too. Yeah, I'm, like, close. I'm not at the level of, like, Izzy Muerte yet, but I'm definitely not that far away. Yeah, I would have just assumed that Izzy

spent at least a little bit more time writing C++ than CMake. So is all of, I mean, how much of VC package is written in CMake versus what else is it written in? Like how much of it is CMake? So. The tool itself. All of the packages are CMake. The tool itself is C++. So the tool itself, what mostly it does is dependency resolution, version resolution, git mangling, all the kind of stuff that actually gets the packages and figures out what to install. But the installation stuff itself is written in CMake.

Just because it's a good build system. It's kind of the easiest way to do that. Does that kind of clear it up? Well, first of all, I'm thinking, if I, as a library author, want my library to be usable by VC package, is there anything special that I should do to my library? Or, maybe phrased differently,

is there anything that I can do to help you? Or maybe phrased differently, is there anything that I can do to help you as the person who's maintaining this registry? First of all, use a good build system. Okay. Does CMake count as a good build system? CMake counts as a good build system. Okay. They actually make sure that they work on long paths and on paths with spaces on windows. Like you should work with that stuff. Don't, don't break on paths that are longer than seven characters or 13 characters is like the one that I was working on two days ago. Two,

honestly, just look at one again, like use a good build system. Mason, CMake, I think build two is also pretty decent. I don't know much about it. Not autoconf.

Not autoconf. Not autoconf. Please, God, no. Don't use weird build systems, though. Use build systems that people understand. That's CMake, Mason, I don't know, build 2. Please don't use Bazel. It does a lot of weird stuff.

It's good for binaries, but packaging stuff that uses Bazel is kind of a pain in the butt. Okay. You can use Bazel. We do support libraries that have Bazel, but it's just much more of a pain in the butt. Again, I'm reminded of our interview with Patricia from a few weeks ago,

discussing how Chromium uses whatever build system they use at some random one. Like, okay, so don't use random build system that no one's ever heard of before. Exactly. And the reason I like CMake is because you can change almost everything from outside the CMake. Right. And that flexibility from the perspective of a package manager is really good. That makes sense. Yeah. Also,

write modern CMake if you can. It is very, very easy to package a library using modern CMake. Do you have to handle all different versions of CMake that there have ever been in VC package? Or you only use... We use 3.18.

Okay. CMake is very good about backward compatibility with itself. Yes. So if you want to use CMake to build your project and use VC package on the back end, we should support back to 3.1, but we don't guarantee it. Just because we don't test it yet. We have plans to do this, but that haven't come to fruition yet.

That's not a guarantee. I just said 3.1 because that's the one we know we have to have, because before 3.1 you couldn't stop variables in if statements from expanding. After 3.1, if you put quotes around names, they don't get expanded. Okay. So we at least require 3.1. But the internal VC package CMake is 3.18 and I believe we require 3.18. So any library that builds with 3.18 could be built with

VC package. And in theory we upgrade decently often. Well yeah, if you're 3.18, isn't 3.19 the current? I believe so. I can't remember if it's pre-release or not. I'm sure I could look it up. So we've talked a lot about these new features, manifest and registries.

Is there anything upcoming that you either want to work on or could tease a little bit, anything like that? Not really. Like, I think manifest or registries and versioning are like the two big features for enterprise um we're hoping that we're in talks with people to like bring vc package to their company um and that's kind of where we want to be

we want to be after registries and versioning we want to be stabilizing we want to be working with our customers to figure out what is the right way forward. What is the best way to make life easier for our customers? I am very curious, like how much effort it takes for a company that has, you know, maybe some complex internal build system to transition over to using a VC package for dependency management. Yeah. And I don't, I don't think we've had anybody like that yet.

Although, internal Microsoft, obviously there's some amount of complexity there, just from a big enterprise. But I would also be curious. I think my feeling is that VC package would do very good in that kind of environment. Okay. Jason, anything else you wanted to ask? I don't believe so.

Okay, well, Nicole, it was great having you on the show again today. Is there anything else you want to plug? Twitter? Anything else like that before we let you go? No. However, I will say, I was told by this beautiful amazing Cy to say

that Pure Virtual C++ 2 is happening in April. So keep your eyes out for stuff like that or for stuff about that. Is there a call for papers or anything or do you not yet? Okay. I don't really know anything about it. I was just told you should check it out. You should plug it.

So no information. Okay. No. And we're probably, well, We'll be releasing more information. No. And we're probably, we're definitely going to give a few talks on VC package and like VS Code and cool Microsoft products. Yeah, for our listeners, Pure Virtual was a great online only conference

around that time last year, April. Yeah. So we have another one planned and I think that's all I can say. I guess I'll jump on that to say also So we have another one planned, and I think that's all I can say. I guess I'll jump on that to say also that Phil has made some announcements about C++ on C, again, with more details to come for what it will look like for the summer. Yeah, I'm excited to see how that happens.

I'm very annoyed I can't go to conferences, because now I'm in a job where I could in theory go to conferences, and then suddenly COVID, and now I can't go to conferences because now i'm like in a job where i could like in theory go to conferences and then suddenly covid and now i can't go to conferences let the company pay for it and everything yeah exactly well hopefully end of this year if not next year everything will be fully back to normal surely by 2025 everything will be back once we're all using modules. Yes, yes. I think that's like 2040. I'm going to say 2040. I think that's a very hopeful prediction,

but I think most people will be using modules by 2040. By 2040, okay. Yeah. Thanks, Nicole. All right, thanks. Thanks, y'all. 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 CppC.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 podcastthemes.com.