Scribd
Upload
27 views20 pages

Sasasa

Uploaded by

kudo01
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
27 views20 pages

Sasasa

Uploaded by

kudo01
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 20
Tutorial on writing makefiles * DoInced a makefile? * Asimple makefile © Using variable © Pattern rules + Phony targets + Working with several directories © Template or boilerplate files © The-F compilation option + Us ards + Functions and Advanced Variable Usage © Lists of corresponding files © Source/Object Separation and Variant Builds © Explicit specifications of akernate directories © Repositories * Debugging Makefiles © amkepp_log A makefile is the set of instructions that you use to tell makepp how to build your program, Makepp can accept most. makefiles written for the standard unix make, but if you're starting ftom scratch, itis often much simpler to use some of makepp's advanced features. This is an introduction for writing makefiles that are specific to makepp. Ifyou already know a Jot about writing makefiles, you might want to at least peruse the later sections of this file because they show the preferred way to do things with makepp, Which is often different from the traditional way to do it with make. Another source of examples and advice on writing makefiles for makepp is makepp_cookbook. Building a program from its source files can be a complicated and time-consuming operation. The commands are too long to be typed in manually every time. However, a straightforward shell script is seklom used for compiling a program, because is too time-consuming to recompile all modules when only one of them has changed. However, it's too error-prone to allow a human to tell the computer which files need to be recompiled. Forgetting to recompile a file can mean hours of frustrating debugging. A reliable automatic tool is necessary for determining exactly which modules need recompilation. Makepp (short for Make-plis-phus, or make++) is a tool for solving exactly this problem. It is an improvement on the make program, a standard tool that has been around for many years. It relies either on its own builtin knowledge (in very simple cases), or on a file called a makefile that contains a detailed recipe for building the program. Usually, the input files are program source code, and the output files are executables, but makepp doesn't care what they are. You can use a makefile to control any kind of procedure where you need to selectively execute certain commands depending on which fies have changed. You could, for example, use makepp to do data analysis, where your input files are raw data and analysis programs, and your output files are processed data or graphs or whatever. Makepp wil figure out which of the processed data files need to be updated whenever some of the data files or analysis programs change. ‘The examples in this introduction will assume you are building an executable program fiom source code, but you can do a Jot more with makepp than just that if you use your imagination, If your program consists ofa single module, you probably don't need makepp, because you know that any change that you make requires recompiling that module. However, if your program consists of even just two modules, then you will definitely want to use a program like makepp. Do I need a makefile? Ifyour program is relatively simple and doesn't require anything particularly special, makepp may already know how to build it without your explicitly giving instructions. For example, suppose you have a program in a single source file, called test.c. You can just type makepp test and your program will buik like this: % makepp test makepp: Entering directory ~/sonewhere/or/other gcc -g “Wall -c test.c -0 test.o gcc -g -Wall test.o -0 test Warning: on unix, to run a program called ‘test’, you must type -/test rather than just "test". ‘These are the basic commands needed to compile a program on unix. Ifthese commands don't make any sense to you, makepp_tutorial compilation Makepp contains buitin rus for C, C+, and Fortran. Makepp can sometimes figure out how to compile programs that are contained in more than one source file, or programs that must be linked with various system libraries. It does this by guessing which source files and libraries you need based on the files that you include. The actual algorithm is too complicated to discuss here in a tutorial (but see makep_builtn); you can try it, and ifit doesn't work automatically for you, you need to write your own makefile. By default, for C and C+, makepp compiles the program with debug information and without optimization, If you want to tum on optimization so that your program runs faster, change the command line to: mmakepp CFLAGS=-02 test Ifyou're compiing C++ instead of C, use CxxFLAGS=-02 instead of CFLAGS=-02. For a complete list of other options you can configure without writing a makefil, see makepp_builtn Makepp's buitin rules are somewhat more powerful than the standard unix make, but if you write programs ofany complexity, is lixely that you'll need a makefile eventually to tell makepp what to do. Ifyou are not familiar with unix compilation commands, it may be helpfil at this point to read makepp_tutorial_ compilation for a description of what these cryptic unix compilation commands do. Asimple makefile Suppose you are writing a C++ program which has two source modules, processing.cxx and gui.cxx, along with ‘mumerous include files. If you were to build your program from scratch, you would need to execute something like these commands: crt -€ processing.cxx -o processing-o CH -€ gui.cxx -0 gui.o cH processing.o gui.o -o my_program The first two commands are compilation commands, and the third invokes the linker to combine the two object files into a single executable, If you make changes to gui..cxx but not to processing.cxx, then you don't need to reexecute the first command, but you do need to execute the last two commands. makepp can figure this out for you automatically. (ifyou've never worked with make before, you may be thinking that you could combine the above three commands into a single command, like this cH processing.cxx gui.cxx -0 my_program When you omit the -c option to the compiler, it combines the compilation and linking step. This is offen quite convenient when you are not writing a makefile. However, i's not a good idea to do this in a makefile, because it always recompiles both modules even if one of them hasn't changed, and this can take a significant amount of extra time.) In order to use makepp to control the build process, youll need to write a conbobulate-$(VERSION) tar.gz Pm =r conbobulate-$(VERSION) ‘ # This target runs regression tests to make sure the program(s) are # doing what they are supposed to do. é $(phony, test): $ (PROGRAMS) noecho for testfile in *.test; do \ -/conbobulate $$testfile | ./discombobulate - > junk_output; \ Af cmp -s junkoutput $$testfile; then \ echo passed $$testfile; \ else \ echo failed $$testfile; \ #5 \ done ® # Tf “nogcho" is the first word of the action, the action itself is not # printed before it is executed. In this case, printing the action # would merely clutter up the screen so it is very connon to suppress # printing for such long conmands. # Working with several directories Ifyour program grows to a substantial siz, or ifit uses libraries that need to be built but should be kept separate, its quite likely that you have split up your sources into several directories, One of the main motivations for writing makepp was to make dealing with several directories much easier than with the standard make utility. If you're familiar with the standard unix make, youll notice that with makepp, you don't have to mess around with ugly complexities lice recursive invocations of make. With makepp, you simply put a separate makefil in each directory that builds the relevant fies in that directory. When a makefile refers to files whose build commands are in different makefiles, makepp automatically finds the appropriate build ruks in the other makefiles. All actions in each makefile are executed with the current directory set to be the directory containing the makefile, so each makefile can be written independently of all the others. No makefile has to know anything about the other makefiles; it does not even have to tell makepp to load the rules fiom those other makefiles When you've written your makefiles, cd to the directory that contains your main program, and type nakepp just like you usually would. Makepp will oad in the makefile from that directory. It will notice that this makefile refers to files in other directories, and it will examine those other directories to see if there is a makefile in them. In this way, all relevant makefiles will be loaded. ‘Asa simple example, suppose your top level directory contains the following makefile: # Top level makefile: OK r= cH CXXFLAGS := -02 ‘my_progran: main.o goodies/1ibgoodies.so $(CXX) $(inputs) -o $(output) Ko: Kon $(CXX) $(CXKFLAGS) -c $input) -0 $(outaut) You would need to write a makefile in the directory goodies which builds 1ibgoodies..so, like this: # goodies/Makefile OK r= cH CXFLAGS = ~02 MODULES = candy.o chips.o Licorice.o cookies.o popcorn.o spinach.o Libgoodies.so: $(MODULES) $(CXX) -shared $(inputs) -o $(output) Note that the conmand is written assuming that # the current directory is the subdirectory # "goodies", not the top level subdirectory. 4 Makepp cds into this directory before executing any commands from this makefile. Kor K.cxx $(CXX) $(CXXFLAGS) -Fpic -c $(input) -o $(output) And that's all you need to do. Any variables which you specify on the command line override the definition of the variable in all makefiles, Thus, for example, if you type makepp CXXFLAGS="-g", all modules will be recompiled for debug because the definition of cxxFLAGS in both makefiles is overridden. The directories containing other sources need not be subdirectories of the top-level directory (as they are inthis example) They can be anywhere in te file system; makepp will automatically load a makefile: from any directory that contains a file which is a dependency of some target itis trying to buik. It will ako load a makefile fiom any directory that is scanned by a wildcard. Automatic loading works if files built by your maketile all reside in the same directory as the makefik itself Ifyou write your makefile so that is rules produce files in a different directory than the makefile itself, then you might have to tell makepp where to look for the makefiles, since it doesn’t have any way of guessing, You can do this using the load makefile statement in your makefile. For more information about this and other issues related to multi-directory builds, see makepp_cookbook/Tips for nuuiple directories. One caveat ifyou reference the variable $(MAKE) in your makefile, makepp automatically goes into backward compatibility mode and turns off automatic loading. Template or boilerplate files Makepp has several other features which make life slightly easier for programmers who have to maintain a program ‘spanning several directories, In the above examples, you'll notice that the definitions of the variables Cxx and CXXFLAGS have to be repeated in each makefile. It can be a nuisance to reenter the same information into every makefile, and it could be a problem ifyou ever decide to change it--you may have to modify dozens of different makefiles. What you can do instead is to put all of the information that's common to each makefile into a separate fle, located pethaps at the top of the directory tree. Common information usually includes variable definitions, and sometimes also pattern rules. (In the above example, however, the pattern rules are not the same in both makefiles.) Let's suppose you've called this file standard_defs.nk. Then each makefile simply needs to contain a statement like this: include standard_defs.mk When makepp sees this statement, it inserts the contents of the fil into the makefile at that point. The include statement first looks for the file in the curent directory, then in the parent of the current directory, and so on up to the top level of the filesystem, so you dont actually need to specify ../standard_defs.mk or ../../../../standard_def's.mk. So we could rewrite the above makefiles to look like this, standard_defs.nk woukl exist in the top level directory, and it might contain the following definitions: # standard_defs.nk OX t= cH CXXFLAGS $= -02 # # We've also included a pattern rule that might be useful in one or more # subdirectories. This pattern rule is for C compilation for putting # things into a shared library (that's what the -fpic option is for). # B08 Kecxx $(CXX) $(CKFLAGS) -Fpic -c $input) -o $(output) Note that since the inchuded fil is actually inserted into each makefile, rules in the included file are applied with the default directory set to the directory containing the makefile that included the file, not the directory containing the include file The top evel Makefile might look like this: # Top level makefile include standard_defs.mk ‘my program: main.o goodies/1ibgoodies.so $(CXX) $(Cinputs) -0 $output) Note that this pattern rule overrides the one found in standard_defs.nk, because makepp sees it later. This pattern rule is for compilation for @ module that doesn't belong in a shared library. 202 KecxX $(CXX) $(CXXFLAGS) $(input) -o $(output) ‘And the subdirectory's makefile might look like this: # goodies/Makefile include standard_defs.mk MODULES = candy.o chips.c Licorice.o cookies.o popcorn.o spinach.o Libgoodies.so: $(MODULES) $(CXX) -shared $(inputs) -o $(output) # We don't need the pattern rule for compilation of .cxx to .o files, # because it's contained in standard_defs.mk. The -F compilation option Ifyou run makepp ffom within an editor such as emacs, and you are editing sources from several different directories, you ‘may find that the default directory for makepp differs depending on which file you were most recently editing. As a result, makepp may not load the correct makefile. ‘What you can do to ensure that makepp always loads the correct makefile(s), no matter what directory happens to be your current directory, is to use the -F command line option, like this: makepp -F ~/src/my_program Makepp wil first cd to the directory ~/src/my_progran before it attempts to load a makefile Using Wildcards Up unt this point, we've had to explicitly list all of the modules that go into a program or a brary. The previous makefile, for example, contained this line: NODULES = candy.o chips.o licorice.o cookies.o popcorn.o spinach.o Libgoodies.so: $(MODULES) $(CXX) -shared $(inputs) -o $(output) In this case, listing all ofthe modules that go into Libgoodies..so is not such a big deal since there aren't very many of them. But sometimes it can be a real muisance to list all ofthe object files, especially if this ist is changing rapidly during development. Frequently, you want every single module in the whole directory to be compiled into your program or brary. It would be a Jot easier if you could just tell makepp to do that without listing them all. Well, you can. The above lines could be rewritten as: Libgoodies.so: *.0 $(CXX) -shared $(inputs) -0 $(output) ‘The *.0 wildcard matches any existing .o files, or any .0 files which do not yet exist but can be made by any of the rules that makepp knows about from any makefiles that it has read. So the wildcard will return the same list of files, no matter whether you haven't compiled anything yet, or whether all the modules have been compiled before. Ofcourse, ifyou contaminate your directories with extra fies that shouldn't be compiled directly into your library, (e.g, if you write litle test programs and leave them in same directory as the library source fils), then these modules will be incorrectly included into your library. Ifyou choose to use wildcards, i's up to you to keep the directory clean enough, Makepp supports the usual unix wiklcards and one additional one: + Matches any string of 0 or more characters, It will not mateh the / character. For example, ae matches ac, abc, and aaaaabe, but not az/bc. + Matches exactly one character (not including /). For example, 222.0 matches all filenames that have 3 characters before the .o extension, ‘* Matches any ofa list of characters at that position. For example, [abc] .o matches a.o, b.o, c.0, but not abc.o or 4.0. You can also specify a range of characters, e.g., data_[2-9] will match data_9, data_1, ete. + This isa special wildcard, found only in makepp (and the zsh shell, from which I stole the idea). It match« ‘number of intervening directories. For example, **/*.0 matches xy2.0, test_prograns/abe.o, and a/deeply/nested/subdirectory/def.0. Ifyour sources are contained in several subdirectories, and you want to link all the object modules together, you could write it ike this: Liboodles.so: **/+.0 $(CXX) -shared $(inputs) -o $(output) Functions and Advanced Variable Usage Makepp has a number of extremely powerfil ways of manipulating text. This tutorial shows a few of the more usefill ways, but you might want to glance through makepp_variables and makepp_finetions for a more complete list. Lists of corresponding files Acommon problem in makefiles is the maintenance of two lists of files which correspond. Consider the following two variables: SOURCES := a.cpp bc.cpp def.cpp 0835 := a.0 bc.0 def.o We might want to have a list of sources ifthe makefile can build source distributions, and we might need a list of objects for the link command. It's tedious to change both lines whenever a new module is added, and it's not unlikely that a programmer will change one line and forget to change the other. Here we will show four different ways to avoid the duplication. he patsubst function The first is to use makepp's functions to convert one Ist into another. A function invocation looks a little like a variable, except that a finction can take arguments: $(function argl arg? arg3 ...) Makepp supplies many powerfil fictions, but probably the most usefil of thems the patsubst fimetion. You could write the above lines lke this SOURCES = a.cpp be.cpp def.cpp 0895 = $(patsubst %.cpp, %-0, $(SOURCES)) ‘The patsubst fimction applies a pattern to every word ina list of words, and performs a simple textual substitution. Any words in the lst that match the patter in the fst argument are put into the output affer making the substitution indicated by the second argument. The % wildcard matches any string of 0 or more characters. In this example, the pattern %. cpp is applied to every word in $(SOURCES). The first word, a.cpp matches the pattem, and the % wildcard matches the string a, The % in the second argument is then replaced by a, and the result is a.o. For the second argument, % matches bc, so the result is be.0. Makepp's finctions can strip directory names, remove extensions, fter out matching words, return the output from shell commands, and other useful tricks, In addition, you can also write your own functions in perl that can be called from other parts of the makefile, See makepp_extending for details. Substitution references Since the patsubst fiction is so common, there is an abbreviated syntax for it called a substitution reference. We could have written the above lines like this: SOURCES = a.cpp bc.cpp def.cpp (BIS = $(SOURCES:%.cpp=%.o) re-style substitution Sometimes invocations of patsubst or the equivalent substitution references can be somewhat cryptic. Makepp provides another option which is sometimes more convenient: i conbined_file has an error because dis mentioned in the action but not in the dependency ist. Ifthe command had been written using automatic variables lke this: conbined_file abcd do_something $(innuts) > combined file then it would have been impossible to make this mistake, Another way that a missing dependency can occur is ifa program actually uses a file but doesn't take the fik's name on the command line. For example, if you're compiling Fortran code, makepp at the moment doesn't know how to scan for included files. Thus you must explicitly ist any files that are included One thing that is sometimes helpfil for testing isto start with a completely clean directory-~just the bare minimum you think should be necessary--and rebuild absolute everything from seratch. This can be most conveniently done by using repositories, like this: rm -rf test-build-dir makepp -R test-buil Ifthe build fils because some: file is not present, it means that makepp didn't realize some fil: was a dependency, because it only links files from the repository that it thought were needed. Performing this test occasionally may save hours of debugging later. I have worked on projects where this was never done for months because recompilation took so long, As a result, many little problems crept in, There were some object fies that didn't have source files any more, some source files that were never properly rebuilt by a preprocessing command, ete. Ofcourse, this wor't catch all missing dependencies, but it will catch some of them. Not specifying all targets You must specify all fies that a given command modifies as targets, or else makepp may not have realized they have changed. You can specify more than one target. For example, y.tab-h y-tab.c: parse.y yacc -d parse.y Ifyou had forgotten to specify y.tab.h as a target, then makepp would not know to rebuild y:4ab./ using this command, and fies that depend on y:tab.h might not be recompiled after the yace command is run. Please suggest things that you have found confusing or dangerous, and I'l either note them or try to fix makepp so they aren't a danger any more.

You might also like