 So, this one is easily one of the most bizarre behaviors I've ever seen for an IDE, ever. Not just for the project systems, but just outright anything. You see, GPS's default project type is the GPR, the NAT project. And I'm going to open one of these for a project that I do not have the dependencies installed for. Normally, this would just mean that the project itself will open up fine. I just will not be able to build it, because how do you build it if you don't have the dependencies for building it? That just doesn't work. But I should still be able to view the sources for the project, right? This should basically just make sense. So let's try that. Okay, so I guess my little panels over on the side just disappeared, so let's get them back. It was a project outline and scenario. Now we go to our project, and you can see this is completely empty. And it says down in the messages that the console project is complaining about there being an unknown project file, colors. That is, one of its dependencies is not installed, it cannot find its dependency. So therefore it's just not going to show me the files at all. It's not going to load even the project source. Now I know at least some people try to rationalize this behavior, but let me phrase this in a way that should make it really obvious how flawed this approach is. But if I made a typo in the dependency name, and literally all I need to do is fix that typo, let it load the project, so I can't actually go through the IDE to do that. Now I can treat the IDE like just a text editor and open the file directly. And this approach does in fact work. But seriously, let's compare this to a system that I think largely has the right approach. Visual Studio Solutions. The way a solution works is there's multiple projects within it. Each project can either be a, well, actually it gets sort of complicated, but for most programming languages every project is either a assembly project, one that is built into a library, a program project, one that is built into an executable, or a test project, one that is not exactly built into anything, although they typically is still built into an assembly, but the point behind a test project is not to produce an object that's going to be used, it is rather to do, to run the tests. With VS Solutions. If any of the constituent projects are unable to load, the solution itself loads just fine. All of the projects that were able to load, load just fine. And that one problematic project merely throws an error and the IDE presents that it could not load that project for you properly. Because file references happen to be stored inside of most of those project types, it generally will not show you the internal files, but it still provides a convenient way to edit that project file, assuming that the file was misread. If the file is not present at all, then you have other ways of resolving that problem. Similarly, and more like what we've got going on here, if any of these projects within the solution do not have their dependencies installed, regardless of the language type, the project itself will load just fine. You will be able to see the project itself, all of the files within it. You just will not be able to build it. And I think that's fair. Your dependencies have nothing to do with being able to view the file, does have everything to do with being able to compile it, so it makes sense that that doesn't work. But there's nothing to do with being able to view it or not. So using another approach that is different from Visual Studios, but that I also happen to agree with, I don't prefer one over the other, let's open up this same project in Visual Studio Code and see what happens. And would you look at that? It opens up fine. I can see the project file. I can even see the sources. It just works. Now understandably, if I try to do a build, this is still going to fail, but I think this behavior that you're seeing right now is what should be done, that this is the reasonable approach. The files are all there. The project file is intact, mind you Visual Studio Code is not using the project file, but you can still easily present those files. Just you can't build. Okay, GPS might not handle problems with projects or missing dependencies of projects, great. But how does it actually handle the projects in the first place? GPS, GPRs are both made by Idecor. In fact, GPRs are the preferred project method for GPS. They should be coupled really tightly together, right? They should work really, really well, right? God, I wish they did. Let's, I don't know, create this somewhere. I think I have a demo folder still. Oh yeah, I was messing around with this, we can create it in there, it's fine. So it did that again. That's lovely. You know what I really like doing guys? Reconfiguring the GUI, every single time I open a project, you're fucking serious? So this must have been introduced within the past year or two because the scenario variables didn't use to include the build stuff automatically. And in fact, I'm curious if these actually change anything just because I've grown so skeptical of that heenie lot. Let's, yeah, let's create a, because I want to see if those are messed up too. Yes, did you actually do that, right? What the fuck? You're fucking serious, okay? That's lovely. Let's just make this a really basic, what, what? So I mean, it also didn't add the thing that it was supposed to add either because the file I just created was apparently main slash ADB dot ADB because it renamed it without telling me because there was already a file with that name. And instead of telling me that, it just creates a new file with a different name than the one I specified and doesn't add that name that it came up with to the GPR. But it adds the one I entered that's already there, there again. Holy shit. Okay, guys, I have a few of these planned, but I'm literally uncovering more problems with this. Just trying to record the shit that, oh my god, this is worse than I intended to show. Holy shit. Actually, while I'm thinking of it, because I know, I'm pretty sure they still do this. Yeah. See, I'm telling it to use tabulations. See how those aren't tabulations? See I'm telling it to use a default indentation of eight. You see how those three spaces, now it evades it properly when I press the tab key. But also, let's adjust this to four, which the way most editors work, it just decreases the amount the tab stop is equivalent to, not this one. I can keep hitting tab all day, and it's still going to be four spaces. Because apparently it only counts as a tab if the number there is eight. Otherwise, even though you say use tabulations, apparently you don't really mean use tabulations because reasons. I don't really know. I don't know. Right, I just want to have some really basic shit here, just so that there's something to build. Now let's see the scenario variables for default should just do a bog standard build. Does, maybe nice if there were tooltip prompts, okay. If I go to debug, does it change? Okay, wait, you put something there, what was it? So it does add stuff there. That's good. It is actually adding stuff. That's good. Now is the project itself, no. So they are not stored inside of the project, they are just things the GPS passes. Cool, let's see if I can break this, because, oh yeah, yeah, thank you. Don't realign those though. Just leave those at the broken default that has nothing to do with what my settings were. Yeah, thank you. So what is it? Package builder is, what, okay, so this one we're going to tell it to optimize regardless, I think. I want to see whether GPS puts both O2 and O0, whether O2 trumps O0, or whether O0 trumps O2. Now only one of those is correct, and it's the last one I said. The rest of them are things not being done the way they should. All right, so let's build this again. Undefined attribute for default. Isn't that what it's called though, for default flags? Right? Oh, I don't remember this shit. All right, screw it. Let's edit you through the UI, project property, builder, isn't, so I guess you're not going to show optimization stuff by default. So let's just put O2 there manually. That's fine. Reload this for, oh, it's just switches, not default switches. I think there is a default switches property too though, I just, does that go somewhere else? O2 is not a builder switch, completing it, moving it to the global compilation switches. Considering your builder is either GCC or not make, O2 is absolutely switches for both of those, so I'm a little confused by that, but okay. Let's break the heck out of this the way I was planning on showing you. Yeah, we'll go back to default mode. Let's add a variable, var1, and we'll just give it some values, a, b, c, okay, and we've got var1 as a. So let's, oh yeah, be careful about this, guys. It doesn't make those changes automatically. Even though you exited the project properties UI, you know, this, it doesn't always make those changes automatically. So little tip if you are still insistent on or have to use GPS and GPRs for whatever reason. If it's got that little pencil there, right click on it, go over to project, go to save project. That's totally convoluted. It should just happen for you to prevent these kinds of things, but yeah. So we've added the scenario variable, and let's go in, not manually, I specifically am going to do it through this because you sort of have to to get it to mess up like this. Let's add in Aida2012 mode as well as assertions, build the project, and they don't like how it does that, but okay. So I'm, I'll show you the source after, but let's say, oh no, go back here. Let's say you're doing, you know, some additional development, whatever. I know this file isn't really mean jack shit, but you've got a more legitimate project and you've made some changes, you've gone through some builds, whatever. You just happen to leave the scenario variable on A for whatever reason. It's not like you can deset these. So you have to test something related to another scenario variable. You go over to B, apply. It's now on scenario variable B. You make some more changes to whatever you had to, you get that working, and then you realize that, oh, you should really have an additional flag, like some of checks or something. So you go back into here, no not preferences, project properties, and we're going to increase the multiprocessing, just because it's getting really sick of how many times you've been rebuilding it. You want to build it back a little faster, so you're going to use more threads if you can, and you might as well make sure you're using the shared runtime, because we're on a modern system, shared libraries are a thing, you know, take use of that, those are beneficial, and no, that should be good. So you go back to doing your thing, you do some more development, whatever, you change your scenario variable back to A where it was, and you go back to developing things again. And you notice builds have been going slowly, like they were before, like you think something's wrong, you open up the task manager or whatever, and check out some builds, and you realize the only one core is doing any of the work. But how could that be? We said that it should be using a multiprocessing, it was a J4, I said it at, right, no, that's one. No, you told it, you left it at J of one. You say how that could that be, I saw it, I said it to four, I know I said it to four. I said a few other things, I told it to use the, no, I told it to use the, no, no, no, no. It meant to set it to the shared NAT runtime, but I guess I didn't. What? What about the things I set for A before, I mean, I set those, so I didn't, why didn't these? Why aren't those set? Why don't you look at that? Now they're not set, but these are. See you've got to be very careful when using scenario variables because the project settings that should probably apply universally across the projects instead only apply inside of the scenario variable. Over the last few years I was using GPS and GPR, I would always go in and edit the file by hand because it just does some bizarre things. Now there are times where you truly want this, where you truly want a switch or something else tied to a scenario variable. I just feel like the expected default, and certainly the default behavior for pretty much everything else is to tie it to a global one, that things like the switches shouldn't be inside this case statement, but should rather be up here. And you notice going back to what I was sort of showing up before, even though it generated these, it's not respecting my settings at all, those are all spaces. And if you want to count six and nine, it's keeping with its three space policy regardless of what I set it at, not using the right white space, it's not using the right amount. You have your own preferences, GPS doesn't really care. So again, let's go back to VS Code and I'll show off a GPR where I am using scenario variables, but it's in a way that makes quite a bit more sense. So we have this scenario variable target, and it's got two different values, Unix and Windows, and if you notice over here there's two folders, Unix and Windows, and essentially what this variable is, is what target to build for, because we have the package specs console, wide console, and wide wide console that are in the top level directory, because these apply regardless of what the underlying target is. But then we have specific implementations for Unix and Windows. This is accomplished by merely setting the source directories different depending on what the scenario variable is, however, things like the default switches and naming policies are set globally not caught into a scenario variable, but I had to edit this file by hand in order to get this behavior fun, right? I do want to cover one more thing related to GPRs, but considering the time of this video already, I'm going to leave that into another video. That's a pretty in-depth issue on its own, so that one will easily fill up video of my normal length. So until then, have a good one.