Troubleshooting

(Problems and suggestions, in increasing order of unlikeliness.)

• Did you use gmake?
• Do all your command lines begin with tab characters?
• Does the last line of the makefile end in a newline character?
• Have you run gmake depend recently?
• If it can't find an include file, did you leave a -I option out somewhere? Remember that make's built in rules for compiling C++ code (.cc.o rules) are something like this:

  .cc.o:
     ->   $(CXX) $(CXXFLAGS) ...

  Remember that C compilation, and the built in rule for linking of .o files use CC and CFLAGS and that C++ compilation uses CXX and CXXFLAGS. If you've added a -I only to CFLAGS, it won't show up when you compile C++. The fix I use is as follows:

  CFLAGS = -g -I$(OLA) ...
  CXXFLAGS = $(CFLAGS)

• If it tells you ``symbol undefined,'' did you forget a .o file or perhaps a library? Are you doing templates correctly? (That's another whole story...) Or, and this is tricky to notice: If you're using suffix rules, are you using something like:

  .o :
     ->   $(CC) ...

  Make's built in rules are something like that. Remember that C compilation, and the built in rule for linking of .o files uses CC and CFLAGS and that C++ compilation use CXX and CXXFLAGS. If you use gcc to link C++ object files, it doesn't know to add in the C++ library, which has the code for ostreams and such. The quickest fix is to add:

  CXX = g++
  CC = $(CXX)

• Did you define a macro and discover that it's mysteriously changing value?

  PRINTER = teerlp2
  
  print:
     ->   print -p$(PRINTER) $(FILES)

  Make has this feature where it reads your environment variables (strings such as your path and X display which you change with the setenv command) and defines macros based on them. Just be forewarned that occasionally something funny happens to makefile macros that have the same name as environment variables. This feature can be useful, but also confusing.

  You're more likely to notice this if you make a typo or forget the name of your variable:

  PRYNTER = teerlp2   # OOPS.
  PRINT_COMMAND = print
  
  print:
     ->   $(PRINTCMD) -p$(PRINTER) $(FILES)   # OOPS.

• Pseudo-targets can be strange. If you accidentally create a file named, say, ``clean,'' it will mess up gmake clean.
• Also, beware of doing fancy shell commands inside a dependency rule. The command interpreter, usually tcsh or bash, is called separately for each command. This means that if you set an environment variable in one line of the command, it doesn't exist in the next one:

  printout: $(SRC) $(HEADERS)
     ->   setenv PRINTER teerlp2
     ->   print -p$PRINTER $WHATEVER ...         #OOPS.

  If you need to do anything that fancy, write a shell script instead, and have make call it.
• Is your makefile too complicated? That can happen when you get into stuff like the second example with built-in suffix rules and if statements going all over the place.