 Someone brought up a good point. I have never actually covered the NAT tools themselves. The individual command line components of NAT. And this is actually kind of important, because while EdiCore's GPS does tie much of these together, one, they don't really tie everything together, so you still often need to go to the command line to do things. And two, even when they tie things together, they still mostly just have you put the command line arguments you want it to run with into the project file. So you still need to know how they work on the command line. For the first part of this, we're going to be doing NATmake and NATclean, mostly because they're two sides of the same coin. In future videos, we'll be covering just one program at a time, along with any of the necessary concepts that need to be understood with those. So let's get switched over to an editor, and I'll show you how these work. Now I have here the basic Hello World program, and that's just because we really just need something to show off these commands working. Now NATmake essentially serves as a nice, convenient wrapper around GCC, as well as the other things that need to be executed. It doesn't provide anything unique in and of itself, just a far more friendly way to approach building data sources. Now in the most basic form, it's just NATmake along with the file or files that you want to make. For this, we've got the hello underscore world dot ADB, so let's put that in there. Now just a quick disclaimer, I am running this on Windows, so case insensitivity is the normal for me. If you're running a unique system, most of their file systems are case sensitive, so you may need to be aware of that, but just know that I will often use the two interchangeably just because I can. So you'll see, as I had alluded to, NATmake was actually calling three things under the hood. GCC, which would be the compilation stage, as well as NATbind and NATlink. Now if you are familiar with how builds work with other programming languages, the compilation and linking stages should not be surprising at all. Binding is, I don't want to say unique to EIDA, but you're probably not going to see it too many other places. I will cover what that is when I cover NATbind in a later video. But just know that NATmake handles all of the appropriate steps and in the right order for you. This is typically how you're going to want to build these. So now that it's built, by default, if you're compiling a program, it outputs an executable file with the same name that your program had. So we can run that by then running Hello World. And of course, we get the expected text output. Now as far as recompilations go, NATmake handles them fine. So if we put something new in here, obviously, since EIDA is a compiled... Well, I really shouldn't say that. I hear so much that it's a bit of a trap. I was going to say EIDA is a compiled language. EIDA is normally compiled, but there's nothing about a language that intrinsically makes it compiled versus interpreted. So because we are compiling it here, and I have not recompiled, you would expect rerunning Hello World should provide the same results. And it in fact does. Rebuilding it does then provide the output that we now expect. So typically, NATmake will handle rebuilding your sources just fine. Sometimes no matter how good of a build system you have, you may need to clean these up. Sometimes it may be because you're primarily focused on editing the files and want to get this junk out so that you can more easily navigate your source code. Now obviously build directories are really what you should be using to help with that, but we're not quite there yet. So cleaning these up is done by a very similar command, Run the same exact way. Oh, typing in the wrong window. So let's do NATClean and Hello World dot ADB. So you'll see it cleaned up all of the relevant files that were generated when making that unit, that executable, that program. Now NATmake in some ways does act similar to GNU Make, and one thing that I will definitely recommend you consider doing, you should probably be familiar with this flag, the processes to spawn when building it. For one single program, this should not make any difference at all, but we can just go ahead and run that. It still builds the same way. Under the hood may spawn more processes, which can then cause it to build faster. Another one that is definitely useful is the output name. So for this one, in this example it's not going to be obvious at all, but when you're specifying the output, you do need to be careful that you're not specifying a huge list of inputs that can all be built to executables or anything that the output flag affects. But again, in this case, we only have one input file, so the output is fine. And let's just call this example.exe instead. And so now we don't have a hello world exe, we have an example exe, and it's the same thing internally. And I believe NATClean will still do the right thing. No, it doesn't. OK, then. So in that instance, we will need to remove that manually. So be aware of that, apparently. Another useful one, although more so if you're doing scripting, is the queue or client flag, and it just suppresses the output. You can see why that would be useful for scripting. I don't really know of any other times that would be useful, but building scripts for doing things that you're repeatedly doing, generally a good idea, typically helps you out quite a bit in the long run. So that's a useful thing to know as well. Another one, and I'll have to get this clean before I can run it, is verbosity levels, which would just be dash V, along with either AL for low, M for medium, or H for high. Now let's run this with high verbosity. And not a whole lot of extra stuff here, but it does explain a little bit more about what it's doing. So, you know, this can be useful for helping diagnose problems. If you are having problems with builds and are looking for help, I highly, highly recommend you run your command with the high verbosity flag and send that output to the people who are trying to help you. It'll make it much clearer what is going on. So similarly for Nat Clean, you do have the quiet flag. We will need to specify a file, of course. And then that cleaned everything quietly as expected. So let's rebuild this, and you also have verbose, although I do not believe there are verbosity levels. There is a verbosity flag for project files, and we'll get into that in another video, but just verbosity in general. I didn't really add anything, and I didn't really expect it to add anything because it's just removing files, but you do get the legal stuff. One other last thing I would recommend. Actually, we'll need to build this again. Especially the very first time you ever run Nat Clean in a project just because I've had it delete things it should not have deleted. I highly recommend you run it with this flag as well, which is dash M, and it's informative mode. So it just prints out the list of what it would delete. So that can show you what it's going to delete without actually deleting it. Again, I highly recommend you run this whenever you're involved with a new project, whenever you did an update to Nat Clean. Nat Clean has some weird rules for deciding what to delete, and this just sort of helps prevent some potentially catastrophic things from happening. So again, there are additional flags. I'll have the links to the documentation for both of these commands down in the video description. We may cover them a little bit with future tools where they become more relevant. For example, both Nat Make and Nat Clean have flags for specifically working with GPRs, but I'll be leaving GPR tooling for a separate video. This should hopefully be enough to get you familiar with building basic add-a-sources, working with small projects. I'm not sure which tool I'm going to do next. Probably Nat Find, but we'll see. Until then, have a good one.