[Make, Clang] [Nate Hardison] [Harvard University] [This is CS50] [CS50.

TV] So
, let's say I've written a little C program to print out the words "hello, world
!," and I've saved it in a file called hello.c. How do I actually run this progr
am? If I just try running the .c file, that's not going to work.
The computer is not going to treat it as a C program like I intended. It turns o
ut that even though C code looks pretty cryptic at first, it's still not low-lev
el enough for computers to understand it. Before you can run C code on a compute
r, you first need to compile it, which transforms your C code into machine code,
which--as its name implies--is a binary format that the machine can understand.

The easiest way to do this is to just use a command called "make." Make is a uti
lity for compiling source code. It's not a compiler itself, but rather a program
that organizes invocations of the compiler on source code files so that things
get compiled in the proper order and in the proper way since compiler flags can
get kind of complicated, as we'll see. It's particularly helpful when you're wor
king with large projects with lots of source code files and many different libra
ries. But it's also nice to use it when you're just working with a single file.
So, let's compile this "hello, world!," program using make. The name of my sourc
e code file is hello.c, so I'll type make hello, and make will use its default s
etup to compile it.
Assuming all goes well, I can use the ls command to list all of the files in the
directory, and I should see a new file called "hello." This file is called an "
executable," and it's in the binary format that the computer can understand. If
we open it up, we can see some characters that we can understand, but for the mo
st part it's just a bunch of mumbo-jumbo. However, I can run this file and watch
it print out "hello, world!" over and over again.
Oh, the excitement! So, let's go back a bit to our make command and see what act
ually happened in order to produce the executable file. You can see that when I
ran make, it printed out this line beginning with "clang" and ending with "hel
lo." This is make invoking the compiler--in this case, one called "Clang" with a
bunch of default flags or options in order to produce our executable.
Clang is one of a number of C compilers out there in the world. You might have h
eard of or used other ones, particularly one called "gcc" that is especially com
mon. We've chosen to use Clang in CS50, because we think it does a really good j
ob of providing helpful warnings and error messages and because using it is real
ly similar to using gcc, so you can pretty easily switch between the two.
When make ran Clang, it ran it with a whole bunch of options. However, it's not
necessary to use all of those options to just compile a single .c source code f
ile. All I need to do is use clang hello.c. Again, if all goes well, this produc
es an executable file. However, if I try running ./hello, I get an error saying
that there's no such file or directory. What happened? Clang by default names it
s executables a.out, which we see if we list the directory with ls. This file w
e can run, and it will also print out "hello, world!" as intended.
If we want to rename the executable, we can use the move command to do so, but m
ost of the time we just want Clang to do the proper naming for us. We can do thi
s with the -o flag. If I run clang hello.c -o hello, then I'll get an executable
named "hello." The -o option is super common, so expect to see and use it a lot
. The next Clang options that you'll see a lot of begin with -W. These options c
ontrol what kinds of warnings Clang gives you about your code. For example, Clan
g can warn you if you declare a variable that's never used. If I put an int vari
able called x is hello.c and then compile with Clang -Wunused-variable hello.c -
o hello, Clang warns me about this unused variable in my code.
Now, there are a ton of different warning types, and it would be obnoxious to ha
ve to list them all out when you run Clang. Instead, there is a shortcut option
to turn them all on-- -Wall. We have this turned on by default when you run make
in the appliance, so you'll get all of the warnings that Clang can give you abo
ut your code. In general, having your code produce compilation warnings is not a
good thing, and we'll expect the programs that you write for CS50 to be warning
free. However, as you see, Clang will still produce an executable file even if
there are warning during the compilation process. We can, however, force Clang t
o stop compilation and produce an error if it encounters something worthy of a w
arning in the code. We do this with the -Werror option.
Now, if I compile my hello.c file with the unused int variable x, I won't get a
n executable file. Now, I can't ignore compilation warnings. I need to go fix my
code. Another important option is -ggdb. This enables special debugging informa
tion in the executable file, so that I can run the debugger, gdb, if it crashes.
Without this option, I can't access much of my program's information within gdb
, like variable and function names, so it's important to include -ggdb, too. Whe
n you run make on the appliance, this option is also included by default.
The final option that it's important to know about is -l, which is used to link
libraries into your code. For example, if you want to use functions from the CS5
0 library, like GetString, you need to make sure that not only do you #include t
he library's header file, CS50.h, in your .c source code file but also that you
use -lcs50 when compiling, so that the library's implementation is linked with y
our program. Let's change the hello world program to prompt the user for a name
with the GetString function and then use the name in our hello string.
Now, if we try to compile this program o using -lcs50, we get an error about an
undefined reference to GetString. Uh oh! Let's add in -lcs50, and now everything
works just fine.
One gotcha is that it does make a difference where in the command you write -lcs
50. If I write it before I write hello.c, then the CS50 library is loaded and pr
ocessed before my source code. So, it's as if I didn't write -lcs50 at all. As a
rule of thumb, you'll generally want to put all of your -l options at the end
of your command. So, now let's put it all together. Clang -ggdb -Wall -Werror he
llo.c -lcs50 -o hello-- that's a lot of stuff.
That's why make is so helpful. It takes care of all of that for you.
So, now you've got a good idea of what goes into compiling your code. My name is
Nate Hardison. This is CS50. [CS50.TV]