Developers have been led down a path by graphical tools. The tools in question are the so-called IDEs (integrated development environments). They are a nice idea in theory: combine your editor, compiler and debugger into one graphical program so that the developer can edit away, pressing \u00e2\u20ac\u0153build\u00e2\u20ac\u009d when they feel like it and single step through the running program for debugging. I can\u00e2\u20ac\u2122t deny that there is a certain appeal to it, and for getting you started in programming, they can be very useful.<\/p>\n
The problem with them is that they make you stupid. A developer in my office wouldn\u00e2\u20ac\u2122t use a free compiler I suggested because it didn\u00e2\u20ac\u2122t have an IDE to go with it. Instead, he\u00e2\u20ac\u2122d rather pay the hundreds of pounds per version charge for a compiler that comes with a graphical interface. Not me; and hopefully not you by the end of this article. The correct way (I think) is to keep each of your tools separate, this is the programmers way anyway \u00e2\u20ac\u201c modular thinking. The key advantage is that you can then swap out particular components for different jobs without having to relearn everything from scratch.<\/p>\n
UNIX is designed using this same philosophy \u00e2\u20ac\u201c small, interchangeable, easily connected tools that do one job and do it well. Everything I write is going to be about working on a Linux platform. There are ways of getting a similar environment on Windows (MSYS<\/a> and Cygwin<\/a>), but I\u00e2\u20ac\u2122ll talk about them another day.<\/p>\n Here then are my chosen tools:<\/p>\n Let\u00e2\u20ac\u2122s begin then\u00e2\u20ac\u00a6 open up a terminal (possibly labelled xterm) and get yourself a command line to start issuing commands. I\u00e2\u20ac\u2122ll mainly be showing command line examples. I\u00e2\u20ac\u2122ll be writing them like this:<\/p>\n You would type the bit after the \u00e2\u20ac\u0153$" and you’d expect to see something like the sample output when you do; I’ll write comments prefixed with a "#", you shouldn’t enter these nor expect to see them in the output — I’ve added them only as explanation. You don’t type the "$<\/span>\u00e2\u20ac\u009d, that\u00e2\u20ac\u2122s just there to show that this is a command prompt, and \u00e2\u20ac\u0153$\u00e2\u20ac\u009d is commonly the default character used already on your system.<\/p>\n We\u00e2\u20ac\u2122ll want some tools to begin, so let\u00e2\u20ac\u2122s install them. On Debian:<\/p>\n Or use whatever package management system you\u00e2\u20ac\u2122re comfortable with to get these programs. I\u00e2\u20ac\u2122m assuming that you already have a text editor that you\u00e2\u20ac\u2122re comfortable with. If not, now is the time to find one and get comfortable with it.<\/p>\n Let\u00e2\u20ac\u2122s begin with the classic, \u00e2\u20ac\u0153Hello, World\u00e2\u20ac\u009d.<\/p>\n Then enter the source for the C++ program:<\/p>\n Now we\u00e2\u20ac\u2122ll compile that manually.<\/p>\n Pretty simple? The C++ compiler, This is okay, but the compiler command line is already tediously long to type, and it\u00e2\u20ac\u2122s near the shortest compiler command line we could have. Let\u00e2\u20ac\u2122s write a A The indent before the command must<\/em> be a real tab. Spaces won\u00e2\u20ac\u2122t work. So, you can see that our You can see that Let\u00e2\u20ac\u2122s improve the The compiler recipe has changed to In short, it means we don\u00e2\u20ac\u2122t have to write We\u00e2\u20ac\u2122ve also used this facility to make the There is now also a There\u00e2\u20ac\u2122s more we can do yet to improve our Let\u00e2\u20ac\u2122s see what happens when we run it:<\/p>\n What\u00e2\u20ac\u2122s this? Exactly the same as before. We changed our compiler recipe definition from \u00e2\u20ac\u0153 There is more to be done yet. Let\u00e2\u20ac\u2122s get the names of things written as few times as we can, and lets split the compile command into more flexible separate compile and link stages.<\/p>\n What we\u00e2\u20ac\u2122ve done here is make a user variable called We can also use variables to hold settings for the whole file \u00e2\u20ac\u201c for example switches to the compiler and linker. By keeping all the settings in one place near the top, we make it easier to customise the build without getting bogged down in the actual command lines.<\/p>\n This There are two key features of \n
vim<\/code>. Many people don\u00e2\u20ac\u2122t like vim<\/code>, that\u00e2\u20ac\u2122s fine. The beauty of a modular system is that you can use whatever suits you; SciTE<\/code><\/a> and notepad++<\/code><\/a> are nice on Windows, and kate<\/code>, emacs<\/code>, vim<\/code>, nedit<\/code>, gedit<\/code>, and many more<\/a> are all good on UNIX. vim<\/code> is available for Windows<\/a> and UNIX so I get the same editor whatever I\u00e2\u20ac\u2122m working on.<\/li>\nmake<\/code><\/a>. make<\/code> is the glue that holds the whole show together, it\u00e2\u20ac\u2122s essentially a program that runs lots of different snippets of shell script from a file you supply. That description doesn\u00e2\u20ac\u2122t really do it justice, but hopefully you\u00e2\u20ac\u2122ll understand more later.<\/li>\nbash<\/code>. We want some way of starting the compilation or running the program. In an IDE, there\u00e2\u20ac\u2122s a button to push. We\u00e2\u20ac\u2122ll be using a terminal with a command line running on it.<\/li>\ngcc<\/code>. There is an advantage to choosing gcc<\/code> as well in that it is widely cross-platform, there is a gcc<\/code> compiler or cross-compiler for almost every system and CPU. The Windows version is called mingw<\/code>.<\/li>\n<\/ul>\n# Comment about what name_of_command will do\n$ name_of_command command_line_parameters\nSample output of command.<\/code><\/pre>\n$ sudo apt-get install g++ make manpages-dev<\/code><\/pre>\n# Change to our home directory, and make an empty directory\n# to work in\n$ cd\n$ mkdir -p projects\/hello\n$ cd project\/hello\n# Start the editor of your choice...\n$ vim hello.cc<\/code><\/pre>\n#include <iostream><\/span>\nusing namespace std;\n\nint<\/span> main()\n{\n cout << "Hello, World!"<\/span> << endl;\n return<\/span> 0<\/span>;\n}<\/code><\/pre>\n$ g++ -o hello hello.cc\n$ .\/hello\nHello, World!<\/code><\/pre>\ng++<\/code> would default to outputting a program called a.out<\/code> if we didn\u00e2\u20ac\u2122t override that with -o hello<\/code>; and of course the hello.cc<\/code> parameter simply tells it what source file to compile.<\/p>\nMakefile<\/code> to take care of calling the compiler, and remembering the command line options we want for us. Put the following in the same directory with the name Makefile<\/code> (the initial capital is important).<\/p>\nrun:<\/span> hello\n .\/hello\n\nhello:<\/span> hello.cc\n g++<\/span> -o hello hello.cc<\/code><\/pre>\nMakefile<\/code> is a list of so-called recipes<\/code>. The form of a recipe is like this:<\/p>\ntarget:<\/span> dependency\n commands_to_make_target_from_dependency<\/code><\/pre>\nhello<\/code> Makefile<\/code> tells make that to create the file hello<\/code> from the file hello.cc<\/code> it should run g++ -o hello hello.cc<\/code>. For convenience, I\u00e2\u20ac\u2122ve also included a run<\/code> recipe. This tells make that to create run<\/code> it needs a file called hello<\/code>, and it should run .\/hello<\/code>. The clever feature of make<\/code> is that if, when it comes to execute the run<\/code> recipe, it can\u00e2\u20ac\u2122t find a file called hello<\/code>, it will look through it\u00e2\u20ac\u2122s other recipes and see if it has been told how to create it. We can check that like this:<\/p>\n$ rm -f hello\n$ make run\ng++ -o hello hello.cc\n.\/hello\nHello, World!<\/code><\/pre>\nmake<\/code> first ran the compiler (it echoes the commands it\u00e2\u20ac\u2122s running to the screen), and then<\/em> runs the program.<\/p>\nMakefile<\/code> a little.<\/p>\nrun:<\/span> hello\n .\/$<\/span><\nclean:<\/span>\n -<\/span>rm<\/span> -f hello\n\nhello:<\/span> hello.cc\n g++<\/span> -o $<\/span>@ $<\/span><<\/code><\/pre>\ng++ -o $@ $<<\/code>, this looks a little like a cat has walked on the keyboard, but really it is making use of make<\/code>\u00e2\u20ac\u2122s variable facility. Variables in make are prefixed with a \u00e2\u20ac\u0153$\u00e2\u20ac\u009d.<\/p>\n\n
$@<\/code>\u00e2\u20ac\u009d variable means the name given as the target of this recipe<\/em>.<\/li>\n$<<\/code>\u00e2\u20ac\u009d variable means the first dependency in the given list<\/em>.<\/li>\n<\/ul>\nhello<\/code> and hello.cc<\/code> again \u00e2\u20ac\u201c the fact that we named them in the recipe declaration means that make<\/code> already knows what they are. Why do we want to do this? We\u00e2\u20ac\u2122ll see more later, but for now just notice that if we renamed hello.cc<\/code> to helloworld.cc<\/code> we would only have one place to change in the Makefile<\/code>.<\/p>\nrun<\/code> recipe run whatever dependency it is given, in our case hello<\/code>. Again, we\u00e2\u20ac\u2122ve reduced the number of places that we have to state a name.<\/p>\nclean<\/code> recipe, which runs the deletion command we showed earlier. This means we don\u00e2\u20ac\u2122t have to worry about mistyping when we\u00e2\u20ac\u2122re deleting and leaves us with an easy way to go back to a directory with no compiler output in it.<\/p>\nMakefile<\/code>, the compile recipe can be changed to:<\/p>\n%:<\/span> %<\/span>.cc\n g++<\/span> -o $<\/span>@ $<\/span><<\/code><\/pre>\n$ make clean\nrm -f hello\n$ make run\ng++ -o hello hello.cc\n.\/hello\nHello, World!<\/code><\/pre>\nhello: hello.cc<\/code>\u00e2\u20ac\u009d to \u00e2\u20ac\u0153%: %.cc<\/code>\u00e2\u20ac\u009d. This is a pattern recipe. We\u00e2\u20ac\u2122re telling make<\/code> that it can create a file called XYZ<\/code> by compiling XYZ.cc<\/code>, and that this works for any XYZ<\/code>. We represent that \u00e2\u20ac\u0153any\u00e2\u20ac\u009d with the %<\/code> symbol. Now, when we run make<\/code>, it decides that to create the run<\/code> target, it needs the file hello<\/code>, but there is no hello<\/code> file, it checks its recipes and finds that it knows how to create hello<\/code> if it has hello.cc<\/code> (\u00e2\u20ac\u0153%: %.cc<\/code>\u00e2\u20ac\u009d). It does<\/em> have hello.cc<\/code> available, so it runs that pattern recipe, expanding the \u00e2\u20ac\u0153%\u00e2\u20ac\u009d symbol appropriately. We see now the additional advantage to our use of \u00e2\u20ac\u0153$@<\/code>\u00e2\u20ac\u009d and \u00e2\u20ac\u0153$<<\/code>\u00e2\u20ac\u009d for specifying the files to the compiler \u00e2\u20ac\u201c they take on the values of the target and dependency after<\/em> the expansion of \u00e2\u20ac\u0153%\u00e2\u20ac\u009d. So, make turns \u00e2\u20ac\u0153%: %.cc<\/code>\u00e2\u20ac\u009d into \u00e2\u20ac\u0153hello: hello.cc<\/code>\u00e2\u20ac\u009d, and then uses that to turn \u00e2\u20ac\u0153g++ -o $@ $<<\/code>\u00e2\u20ac\u009d into \u00e2\u20ac\u0153g++ -o hello hello.cc<\/code>\u00e2\u20ac\u009d; which is exactly what it runs.<\/p>\nNAME <\/span>:= hello<\/span>\n\nrun:<\/span> $(<\/span>NAME<\/span>)<\/span>\n .\/$<\/span><\nclean:<\/span>\n -<\/span>rm<\/span> -f $(<\/span>NAME<\/span>)<\/span>\n -<\/span>rm<\/span> -f $(<\/span>NAME<\/span>)<\/span>.o\n\n%<\/span>.o:<\/span> %<\/span>.cc\n g++<\/span> -c $<\/span><\n%:<\/span> %<\/span>.o\n g++<\/span> -o $<\/span>@ $<\/span><<\/code><\/pre>\nNAME<\/code> to hold the word hello<\/code>. User variables are just like the $@<\/code> and $<<\/code> we saw earlier, but they are not assigned automatically, we must assign them something. The first line is that assignment. Then, whenever we need to use hello<\/code>, we write $(NAME)<\/code> instead and rely on make<\/code> to substitute hello<\/code> in when it is running. In this way we\u00e2\u20ac\u2122ve removed all but one of the explicit uses of a filename. You can imagine that should we want to start a new project, it would be very easy to copy this Makefile<\/code> and change the NAME<\/code> at the top as appropriate.<\/p>\nMakefile<\/code> is still a little limited because it only compiles one source file. When a project gets larger, we want to be able to compile multiple source files into their respective object files, then link all into one final executable. Let\u00e2\u20ac\u2122s alter our Makefile<\/code> to do that automatically for a directory filled with source files.<\/p>\nTARGET <\/span>:= hello<\/span>\n\nSOURCE <\/span>:= <\/span>$(<\/span>wildcard *.cc<\/span>)<\/span>\nOBJS <\/span>:= <\/span>$(<\/span>SOURCE:.cc=.o<\/span>)<\/span>\n\nrun:<\/span> $(<\/span>TARGET<\/span>)<\/span>\n .\/$<\/span><\nclean:<\/span>\n -<\/span>rm<\/span> -f $(<\/span>TARGET<\/span>)<\/span>\n -<\/span>rm<\/span> -f $(<\/span>OBJS<\/span>)<\/span>\n\n$(<\/span>TARGET<\/span>):<\/span> $(<\/span>OBJS<\/span>)<\/span>\n g++<\/span> -o $<\/span>@ $<\/span>^\n%<\/span>.o:<\/span> %<\/span>.cc\n g++<\/span> -c $<\/span><<\/code><\/pre>\nmake<\/code> we\u00e2\u20ac\u2122ve used here:<\/p>\n\n
$(wildcard)<\/code> is a special variable which, rather than expand to a value that was set earlier, instead performs an operation to generate the value. For $(wildcard *.cc)<\/code> it looks in the current directory for all the files that end with \u00e2\u20ac\u0153.cc<\/code>\u00e2\u20ac\u009d. That list is then written to the user variable, SOURCE.<\/li>\n$(SOURCE)<\/code> would be replaced with the value of the SOURCE<\/code> variable. However, make<\/code> gives an additional syntax which lets us run a pattern substitution on the replacement. That mode is activated by ending the variable name with a colon, \u00e2\u20ac\u0153:\u00e2\u20ac\u009d. For example, $(SOURCE:.cc=.o)<\/code> looks up the variable