How to automatically include header dependencies in makefile

Why automate inclusion of header file dependencies: While working on a new project, I had to write a makefile from scratch. I found it little challenging to find out how to automatically include header dependencies in makefile, because everytime you include some header file in your source file, you can not modify your makefile. So, I thought, there must be some mechanism that automatically takes care of it. If you search on google, you will find various ways. Manual solution is to use sed command that I guess searches for #includes in your source code and puts all those dependencies in your makefile. But with modern compiler, you dont need to do much. It will do your job. You just need to pass some flags to it.

For instance, with gcc version 4.1.2 20080704 (Red Hat 4.1.2-51), before including header dependencies, target to make object file was

./%.o : ../%.cpp
     g++ -c $(INC_PATH) $(FLAGS)  $< -o $@
./%.o : ../%.cpp
     g++ -c $(INC_PATH) $(FLAGS) -MMD -MP $< -o $@

-include $(SRC_FILES:.cpp=.d)

you just need to pass -MMD and _MP flag and need to include these dependencies (.d file).

 See the below example that demonstrate it

Let us say we have 3 c++ and 3 header files :

1. test.cxx
2. add.cxx
3. sub.cxx
4. test.h
5. sub.h
6. add.h

add.cxx includes add.h
sub.cxx includes sub.h
test.cxx includes test.h , add.h and sub.h

Following is the makefile that only includes dependencies of .cxx files  :

---------------------------------------------------------------------------------
### declaration of all variables
FLAGS := -g
COMPILER := g++
SRC_FILES := $(wildcard *.cxx)
OBJ_FILES := $(SRC_FILES:%.cxx=%.o)
.PHONY  : all clean
EXE := my_exe
STATIC_LIB := my_exe.a
all : $(EXE)

### compile source files to make object files
### expand this section for each object file to include dependency of header files
## NAAAA I am not gonna do it..  :P
%.o : %.cxx
        $(COMPILER) -c $(FLAGS) $< -o $@

### make static libary of object files
$(STATIC_LIB) : $(OBJ_FILES)
    ar -crv $@ $^

### make executable  
$(EXE) : $(STATIC_LIB)
    $(COMPILER) $^ -o $@

# clean all the files
clean :
    rm -rf $(OBJ_FILES) $(EXE) $(STATIC_LIB)
---------------------------------------------------------------------------------

If you do any changes in .h file and try to do "make" it will say nothing to be done for 'all'  as we have no where mentioned that any of my target depends on header file.

Hence,  to include dependency of header files I should explicitly include header files in my makefile but what if I add one more header file in test.cxx? I will again need to modify makefile which is a cumbersome task and non-practical in a real project.

Today compiler provides you facility to automatically generate dependency graph. All you need to do is to just pass some flags.

e.g. with g++ compiler you should give -MMD -MP flag. It will generate dependency file(.d) for each object file and include those dependency files in makefile as follow :

---------------------------------------------------------------------------------
## not including variable declaration part

%.o : %.cxx
        $(COMPILER) -c $(FLAGS) -MMD -MP $< -o $@

### include all dependency files

-include $(SRC_FILES:.cxx=.d)

$(STATIC_LIB) : $(OBJ_FILES)
    ar -crv $@ $^
   
$(EXE) : $(STATIC_LIB)
    $(COMPILER) $^ -o $@

clean :
    rm -rf $(OBJ_FILES) $(EXE) $(STATIC_LIB)
---------------------------------------------------------------------------------

Test.d : 

test.o: test.cxx add.h sub.h test.h

add.h:

sub.h:

test.h:

This is how a dependency files look like. Now test.o depends on  test.h, add.h and sub.h along with test.cxx. similarly add.o includes dependency of add.h and sub.o takes sub.h into account.

Whenever time stamp of any of header file changes corresponding object file will be modified that solves our purpose. :)

Meyer's Singleton pattern

Singleton pattern is my all time favorite. Some people call it anti-pattern as they use it even when it is not actually required. Today, I was reading about singleton pattern and found so many interesting things about it.

static data + static functions != singleton pattern

Static class (a class that contains only static data and functions) and singleton pattern are not same. In some cases it may seem same, but with static classes there are some problems e.g.

1. You can not extend its functionality by inheritance since static functions can not be virtual.
2. Initialization and clean up is very difficult in static classes; since there is no central point of initialization or clean up; i.e. data is not bound with constructor or destructor as the whole data is static.

Singleton design pattern takes care of this along with focusing on the fact that there is a single object in the execution of program.

Given below is one design variant of singleton design pattern :

class singleton {
     singleton *pinst_;
    singleton() {};
    singleton(const singelton&) ;
   operator =(const singleton&);
public:
   static singleton* Instance() {
      if(pinst_ == NULL)
         pinst_ = new singleton();
      return pinst_;
   }
}; 

Since all constructors are private, user is not allowed to create its instance. Hence, uniqueness is enforced at compile time. If Instance function is never called, no object is created at all. Instance of singleton is created when Instance is called first time. This optimization is useful, if size of class is too big to be very expensive, but what if singleton object is not too big.

In that case, one can keep static object of  singleton class instead of pointer as follow : 

Another design Invariant :

class singleton {
     singleton inst_;
    singleton() {};
    singleton(const singelton&) ;
   operator =(const singleton&);
public:
   static singleton* Instance() {
      return &inst_; // return its reference
   }
}; 

in implementation file 

singleton singleton::inst_; // initializing static object. 

This is not a good solution although everything is same in second invariant as well except that in 2nd approach there is static object and in first there is pointer. 

In second approach, inst_ is initialized dynamically at runtime and in first approach it happens statically (It is a type without constructor initialized with compile time constant). .

The compiler performs static initialization before the very first assembly statement gets executed. But compiler does not define the order of initialization for dynamically initialized objects found in different translation unit (A compilable source file).

int global = singleton::Instance().do_something();

depending on the order chosen by compiler to initialize global and inst_ singleton::Instance() may return an object that has not been even constructed yet. 

Destroying singleton : As we discussed above, first approach is more reliable than the second one. But it has problem that when and how to destroy the static singleton object. Like there is a function Instance(), we can make a public function destroy() that will call destructor  but one has to be very careful that nobody access the object after it has been destroyed. we would not have to face this problem if we have used second approach but definitely that is more dangerous. Scott meyer came up with another approach. Therefore, people refer it as Meyer's singleton.

singleton& singleton::Instance {
   static singleton obj; //function static object
   return obj;
}

Function static object is initialized when control flow hits this function first time. Primitive static variables are initialized with compile time constants. e.g

int func() {
  static int x=100;
  return x++;
}

In this case, x is initialized to 100 before any code in the program is executed most likely at the load time. When the static variable is not compile time constant or an object with a constructor it is initialized when the program hits for first time.  

A pseudo C++ code generated by compiler : 

singleton& singleton::Instance() {
// functions generated by compiler  extern void __ConstructorSingleton(void *memory);  extern void __DestroySingleton();// objects created by compiler
  static bool __initialized  = false;  static char __buffer[sizeof(singleton)];  if(! __initialized) {     __ConstructorSingleton(__buffer);     atexit(__DestroySingleton);    __initialized = true;
  }  return *reinterpret_cast<singleton*>(__buffer); }

Main part here is atexit function, which is provided by standard c library. It allows register function to be called automatically during program's exit. 

Each call to atexit function pushes its parameter on a private stack maintained by C runtime library. During application's exit, these functions are called.

P.S
In subsequent  posts we will disucss about following things in more details :

1. The compiler performs static initialization before the very first assembly statement gets executed. But compiler does not define the order of initialization for dynamically initialized objects found in different translation unit(A compilable source file). 
2. atexit function.. problem associated with it.
3. Renterpret cast