Hello and welcome.
In this video, I'm going to show you how to build and run the program from the previous video.
So if you recall, we had a little program that basically asked the user to enter their favorite number
and then printed out that favorite number.
So from past videos, you should understand that there are many steps to create a program that you can
run.
You have to compile, you have to link, and then you have to create that binary.
And so up till this point, we were able to compile successfully.
We don't see any errors.
Now we need to basically take all of the external dependencies for this program, write standard i o
header file and any other libraries provided by the C programming language.
You take all of that which can be many O files and take all that external code to create one single
executable.
Right?
So here we have our source code.
You'll see we kind of have the source code that's kind of bunched up together.
You can actually make this code a little bit more readable by adding some new lines, something like
this.
It just makes it a little bit more readable.
Now, as I mentioned, we've already compiled it.
Just to refresh your memory, you can compile a source file in many different ways.
You can right click on the source file and say compile, or you can actually select that source file,
go up to build and you can say compile current file.
If we select our project, you'll see many different options related to building.
You see build, rebuild, clean, stop, build.
Let's talk about clean first.
Clean is going to basically wipe out any old files that you had.
So remember beforehand in previous videos that a C program when it gets compiled, you're compiling
each source file and a program may consist of many source files.
Main dot C Any other files as well?
There are programs that contain thousands and thousands of C source files.
Once you compile all those C files, it creates all the old files and then you take those old files
and you link them together to create one single executable.
Now, when you select the project, setting the project self and you say clean, what you're doing is
you're basically deleting all those old files, you're deleting any extra artifacts, you're deleting
the program executable and you're starting from scratch.
You're essentially getting a clean workspace that you can then recompile, rebuild, relink and recreate
a program itself.
Typically you want to use clean if you're running into errors and maybe you just want to recompile every
source file because typically when you run a C compiler, if the code as it doesn't change and you try
to compile that code, it usually doesn't recompile it.
And so if you just are running into problems, you have a lot of source files, you're seeing errors
that don't make sense.
It may be good to start from a clean state, go to clean, clean everything out.
You say clean and it will show you exactly that.
It's basically removing everything from your build debug folder.
Again, all those dot os the executable you're starting from scratch.
It's a nice way to resolve any kind of dependencies or any kind of issues with not recompiling the whole
project again to start from scratch.
So after running clean, we don't have anything compiled or anything built and we could go through and
we can compile individual files by saying compile and click on each file.
If you have many source files, that's not really a great way to get to the final executable.
Typically what will happen is you want to make sure you have your app project and you'll typically just
say build and that will go through all of the source code in your project and build all of the files.
So when you hit build, you'll see it go through and grab all of the source codes and rebuild.
And same thing as if you if you right click and you say rebuild, this will not rebuild all the files
or only rebuild the files that have changed.
And so you can say build, which makes it a little bit easier than just compiling every source file.
The build will actually again compile all the source files, but also link them so you can kind of see
that in the output, right?
If you go to the build output window, you can see that we're first issuing a GCC command dash C, which
is the flag for compiling on main dot C, We then pass in parameters for 64 architecture optimization,
some debugging standard C, 99 warnings for all warnings.
And then we do the dash o to link to the Main.cpp file.
We're basically going to also include some include directories.
And then in the next step, right, we issue the dash zero to do our linking to every external dependency.
In this case, we don't really have many, we just have basically linking, we're linking statically
with the Dash L and we're basically building this object list text.
The big important thing here is it's actually creating an executable named our first program.
See.
And so building does both steps of a C program, right?
It compiles it and links it and creates the executable.
And so it just makes things easier by building as opposed to compiling everything at first.
Now, you may want to compile individual files just to maybe see what's going on, to make sure your
source code is correct and you're not ready for linking.
You may have five files in here.
You select each one you want to say, okay, I just wrote some code, let's compile it, make sure it's
all good to go, and then I'll go and out at the next file, compile that and then eventually you build
everything.
Now that we have an actual program executable that's created, we can actually run our program.
And so you want to make sure that you have your program, your project as the active project and have
it highlighted, and then you can go up to build and you can simply say run.
Now when you select run, you'll probably get this pop up that says, Do you want to build again and
execute?
Now you've already built, so you don't really need to.
You can just say execute.
You can select the checkbox to make sure this doesn't always come up.
And when you run, it doesn't always rebuild.
It's up to you.
It takes up some CPU processing time to rebuild everything, but you're probably not worried about that.
So you can always say build and execute and not have a pop up or you can always just execute.
Now, if we select execute, it's going to take that executable and it's going to run.
And what you'll notice is it's asking you to enter your favorite number, the user.
And so you can just put in a number 45, hit the enter button on the keyboard and then it will just
display you enter number 45.
Again, a very simple program asks for input, displays, output, and then you can hit any key to continue
to close that window.
Now, if we go back to our workspace view, our workspace window, our workspace pane, whatever you
want to call it, you notice we have three projects, right?
Our first program is highlighted.
That's the active project.
The other projects still have their source files in them, right?
Main dot C, Right.
And our other projects, they're pretty much templated.
Hello, World Code.
But what you don't see is you don't see any of the object files, the dot zero files, you don't see
the executable file, anything like that.
Now you can actually view those by clicking on the Explorer tab and you can actually specify a folder
to open.
And usually this should be the root folder of where you're creating all your workspaces.
So I typically put them, I think I put them in documents inside of right inside documents.
I have my workspaces.
You'll see that it does have a lot of stuff in here.
So usually you want to put that local, but you'll see that you do have Workspace one and Workspace
two, and you'll see that that workspace has the dot code light file.
Actually, you'll probably be better to open the exact workspace files, right?
Because that's really only what we're included interested in.
Workspace two is what we're interested in.
So let's say select folder, workspace two, and then let's go ahead and close our our existing documents
so we can go ahead and we can just say close.
So now we have Workspace two and now we can actually see all of our executables for all of our projects
and all of our files.
And so you notice there's a code light folder in there.
That code light directory just contains some of the preferences for the workspace and so forth.
We have our build debug folder.
This contains our binary directory which contains our executable and you'll notice that we also have
an R first program directory and that's inside build debug because that workspace, that project has
been built and you'll see in there we have our object files and any other dependencies that are built
this object list.
We actually have our first program project, right?
And that concerns our source file and any other make files and so forth.
And you see the same thing for the other projects.
And then at the very bottom you see compile commands, dot JSON.
This is usually used for code completion.
You see a make file and then you see a workspace file.
But the Explore tab helps us see our entire workspace layout, all of our projects, everything that's
been built, all the project settings files and all the project source files, and then also any dependencies
on code completion files and so forth for the workspace itself.
And so we talked about clean, Right?
How clean can actually delete everything, all the object files in the executable.
So if we go back to Workspace View and we highlight our our first program project when we right click
and we say clean, that's going to delete all of those.
So now if you go back to your Explorer tab and you go to the build debug, you see you'll see everything
in there because it hasn't been refreshed.
So you can actually refresh this view.
So I'm going to right click on our workspace and I'm going to say refresh the build debug folder.
So that usually gets deleted, but there's nothing inside of it, right?
You might have a bin again.
Usually that gets cleaned up.
Depends on the permissions, but you don't have any old files.
You don't have your executable after doing a clean.
Now, again, if we go back to workspace, you can see this little dropdown menu that tells you what
to build, whether you're building for debug or whether you're building for release.
When you build for debug, it includes debugging information in the program executable itself.
That's usually happens when you're developing your code.
You want debug information and in case you need to run the debugger and so forth.
That's not always good to do when you release some program out into the field or to a customer into
production mode so you can change the release to release when you're building and you want to distribute
this program somewhere.
And so then when you build it, what you'll notice is if you go to the explore tab, you'll see again
do a refresh.
You'll see a build release folder and this will lack the debugging information essentially so you won't
have to worry about.
Basically, if you have debugging information, you can generate a core file and you can have hackers
that can kind of get information about your source code.
So you only build debug for debug mode when you're developing and you would change it to build release
mode when you're maybe releasing your program out to a customer.
Again, it depends if you're working somewhere or if you're working for an employee, if you're actually
delivering some code somewhere.
Usually you don't really modify anything in the Explorer tab.
It just gives you a view of what's built and your executables and so forth.
Again, I mentioned you see some helper files.
You can look at some of these things.
Some of these things will be auto generated.
You can see a make file in here.
And this is actually a make file that can be generated depending on your project settings.
This is a make file for the entire workspace.
You can look at specific programs and see some of the make files that are generated again, but usually
you don't want to mess with any of this stuff.
This just again provides a make file to compile.
Sometimes when you have errors, you can look at the make file to see exactly what's going on.
Maybe something wasn't generated correctly.
Code like sometimes has some bugs depending on what make system you use.
Again, we usually go with the UNIX file make system for if you're on Windows and then if you're on
Linux or Mac OS, you just go with default.
So that's basically it, right?
You can close these files, but you kind of see what's going on in the Explorer and the workspace views.
Now in the Workspace view, again, if you select a project, you can also say stop, build.
So sometimes compiling and building and your executable can take a long time.
I mean, if you have thousands of files, you could be building for 30 minutes.
So stop, build just allows you to stop building anything, you know, compiling and linking anything,
any of the projects.
Again, useful for when you have a long compilation process, but you typically don't see that in some
of the code we're going to be writing for our class.
The other thing that might be nice is if you highlight the workspace view, you can actually build all
the projects in one shot.
You can say build workspace or clean workspace and delete all the dependencies for all the projects.
But if you say build workspace, that will build all the projects regardless if it's active and that's
what you see in the output window.
Right.
We're building Project three, we're building Project two and we're building our first program.
And so again, just a quick rundown of how you can actually build and run your code from the active
project, some of the settings and how you can see your Explorer tab.
Thank you.