11 Modules and Makefiles11.1 Modular Organization and makefiles.11.1.1 History11.1.2 General Concepts11.1.3 Enumerations and External Objects11.1.4 Rules11.2 A Makefile defines the project.11.2.1 Making the Bargraph ApplicationChapter 11: Modules and Makefiles11.1 Modular Organization and makefiles.From the Fanny Farmer cookbook:Before beginning to mix, be sure that all ingredients and utensils are on hand.You can’t bake a good cake if you don’t have enough eggs or if your butter is spoiled. You can’t compile or runa program successfully if you need files that are missing or out of date.11.1.1 HistoryThe C++ standard does not address the issues of code files and header files. These and makefiles developedas part of the Unix system environment because of a clear and evident need to mechanize and automate theproduction of large-scale applications.Projects. Both Unix-based and Windows-based systems have supported projects as part of an integrateddevelopment environment (IDE). The project facilities vary greatly in both power and convenience of use, andcan be more difficult for a newcomer to use than the old-fashioned makefile. At this time, the Microsoft projectfacility is both confusing and intolerant of error. Mac’s XCode is flexible and less intolerant of error, but highlycomplex. Both organize the project using a special project file. The cross-platform Eclipse IDE gives theprogrammer a choice of producing a traditional makefile or a non-portable project file.A modern IDE offers much more than just a project facility. Most useful are syntax coloring, global renamingand refactoring, and global search-and-replace. It is clear that, as IDEs improve and our experience with themincreases, they will gradually replace the old ways of doing the job: compiling from the command line andhand-built makefiles.Whether you are using a project or a makefile, one kind of information must be supplied: the full pathnameof every source code file and every header file that is needed by the project. Given this information, a projectfacility and some makefile facilities will generate a list of which modules depend on which other modules. Thisdependency list is used to determine which modules are unaffected by a change to part of the program. Whenyou ask to build the application, the only modules that will be recompiled are those that have been affectedby some editing change since the last build. Thus, if one module of a massive application is changed, we avoidrecompiling almost all of the program. Re-linking will happen if anything was recompiled.ccode graphscores.ingraph.hpprow.cppMakefilerow.hppitem.hppgraph.cppCS626CS636CS670etc.sortins.csort.outsortinsfloats.incppcode c4_stackc5_callsc6_debughc7_graphc9_modeltools.cpptools.hppetc.graphM.cppgraphM.otools.ograph.orow.oassignmentsstudentsetc.scores.outFigure 11.1: A typical directory structure.131132 CHAPTER 11. MODULES AND MAKEFILESNamespaces. Very recently, the C++ standard adopted the concepts of namespaces, and Visual C++ imple-mented them in conjunction with workspaces. These facilities may or may not replace the traditional makefilesand separate compilation. At the moment the added facility leads more to confusion than to ease of use. Thepurpose of namespaces is the same as one of the purposees of separate compilation: to allow many modules todefine objects and functions freely without concern about conflict with other objects of the same name in othermodules.File and Directory Organization. A multi-module program in C++ consists of pairs of .cpp and .hppfiles, one pair for each class (or closely related set of classes), and one .cpp file that contains the main program.(Exceptions: he main program may or may not have a matching .hpp file, and some simple classes are writtenentirely within the class .hpp file.) Each .cpp file includes just its own .hpp file. Each .hpp file in the projectmust include the other .hpp files that contain the prototypes it uses.Experienced programmers define a separate directory for each project. (This saves much pain in the longrun.) This directory contains the .cpp, .hpp, and .o files for the project as well as the makefile, the executablefile, the input, and the output. Since many projects may use the tools files, they are placed a level or two abovethe project directories, as indicated by Figure 11.1.g++ -c -Wall graphM.cpprow.orow.hppgraphM.cppgraphM.og++ -c -Wall row.cppg++ -o graph -Wall graphM.o graph.o row.o tools.ographgraph.hppgraph.cpp row.cppg++ -c -Wall graph.cppgraph.oSource code filesHeader filesObject filesExecutable fileCompilation stepsLinking steptools.oitem.hppg++ -c -Wall tools.cpptools.cpptools.hppFigure 11.2: The BarGraph application with four code modules.11.1.2 General Concepts• A program that is physically located in many files will be compiled as a single module if the main programincludes (directly or indirectly) the .cpp files for the other modules. In a multi-module compilation, main()includes the header files of the other modules, not their source code.• When doing a multi-module compile, each module is compiled separately to make a .o file, as shown inFigure 11.2. Then the linker integrates these .o files with the .o files for the libraries to make an executablefile.• A makefile (in Unix) automates the process of separate compilation and linking. The project files inWindows systems accomplish the same goals as a makefile, but a makefile has somewhat more power andflexibility because it can be hand-coded and/or hand-modified. Project files are automatically generatedand, therefore, rigid. Makefiles are universally portable in the Unix world.• One .hpp file may be included by several others, so we must do something to prevent definitions frombeing included twice in the same module. (This would cause the compiler to fail.) Many systems supportthis directive at the top of a header file:#pragma once;This is advice to the compiler to include the header only once per module. If your system does not supportthis, you must surround the entire .hpp file with conditional compilation commands.11.1. MODULAR ORGANIZATION AND MAKEFILES. 133#ifndef MYCLASS_H#define MYCLASS_H... put the class declaration here ...#endifIf an attempt is made to include the same header twice in one module, this ”wrapper” will cause theinclusion to be skipped the second time, avoiding conflicts due to duplicate definitions. The ”wrapper”always follows the pattern shown above, where MYCLASS is