Makefile中头文件在依赖关系中做用

摘于：http://bbs.csdn.net/topics/120024677

（1）在makefile的依赖关系中用不用体现.h头文件？
（2）若是在依赖关系中要体现.h头文件，应该体现到什么层次？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
（1）在makefile的依赖关系中用不用体现.h头文件？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 下面是个人一些认识：
 头文件中定义的是接口（函数接口，文件外全局变量和宏定义），它的做用是向调用文件封装函数的实现过程。在第一次make的时候依赖关系中没有.h文件是没有关系的。因此主要讨论在修改文件的时候从新make的状况。
（一）接口
以一个类CBase的.h文件和.cpp文件为例：
//CBase.h
Class CBase
{
    ....
};
//CBase.cpp
CBasee::CBase(){}
....
//file upper.cpp
#include “CBase.h”
...
按照书上的例子这样的文件依赖关系应该为：
    upper.o : upper.cpp CBase.h
        gcc ........
    CBase.o : CBase.cpp CBase.h
        gcc ........
(1)若是函数实现（CBase.cpp）被修改而函数接口(CBase.h)没有被修改。这种状况应该是出现最多的状况，咱们须要对函数的实现进行修改。这个时候很明显CBase.cpp将会有一个新的时间戳。因此在依赖关系中有没有CBase.h均可以。
(2)函数接口被修改。也就是.h文件被修改。在全部正常状况下对接口（.h）的修改必将致使相应的实现(.cpp)的修改和调用文件（upper.cpp）的修改（若是调用文件中使用了.h中的接口，淡然没使用upper.o就更不须要从新编译）。这样CBase.cpp和upper.cpp都有一个新的时间戳，因此在依赖关系中更不须要.h头文件。
（二）文件外全局变量。在头文件中的全局变量的申明是通知使用者在链接的时候要到文件中去找定义。因此在头文件中修改全局变量没有任何意义。一种状况是
//a.cpp
int a =5;
...
//a.h
extern int a;
...
//b.cpp
...
a++;
...
以前的make是ok的。若是咱们人为的将a.h的全局变量的声明改成
extern int amm ;
这样make之后是会报错的，除非在依赖关系中体现.h头文件。
（三）宏定义
我想这个是要使用.h头文件的最重要因素了。若是咱们在头文件中定义
＃define PI 3.14
而后咱们想提高pi的精度，修改头文件
＃define PI 3.1415
这样咱们必须将头文件包含在makefile的依赖关系中。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
（2）若是在依赖关系中要体现.h头文件，应该体现到什么层次？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
一个例子
在一个Has_a的类关系中，
class CWhole
{
private:
    CPart1 Part1;
    CPart2 Part2;
    ...
}
这样咱们在CWhole类的头文件中显然要include
#include "CPart1.h"
#include "CPart2.h"
....
而在CWhole类的实现文件中只要include
#include "CWhole.h"
那么咱们在CWhole.cpp的依赖关系中要怎么写？
（1）CWhole.o :CWhole.cpp CWhole.h
         gcc ...
 (2) CWhole.o : CWhole.cpp CWhole.h CPart1.h CPart2.h ...CPartn.h
         gcc ...
 (3) ?????万一CPart1.h中#include的头文件要不要写在CWhole.o的依赖关系中？下面全部的头文件要不要写在依赖关系中

头大，请你们帮我想一想

 

---------------------------------------------------------------------------------------------------------------

在 C++ 中由于头文件包含了一些实现的内容（好比类成员的定义），而这些内容因为面向对象的封装原则，客户代码是不去理会的，然而编译客户代码时倒是须要的。那么当这些内容发生改变的时候，实现文件（.cpp）每每也发生改变，这致使相应 .o 的从新编译生成。然而若是不把该头文件加入到客户代码的依赖关系中，由于客户代码没有改变，时间戳未发生变化，客户代码不会被重编译，而这种状况在链接时也未必会被发现，最后只能致使难以调试的运行时错误。

例如：

class SomeLinkList {
public:
    ...
    bool HasDupElement(); // 是否存在重复的元素
    ...
private:
    Node * pHead;
    Node * pTail;
};

HasDupElement() 这个方法原先以每次遍历链表的方式实现，后来程序员想到在每次插入新元素的时候查找一下用一个成员变量保存结果，每次返回这个变量值就能够了，效率更高。因而他修改了实现，并在类定义中添加了一个 bool 型的私有成员。这个改动对客户代码没有影响，客户代码不须要修改，这正是面向对象但愿的。然而 C++ 的封装并不彻底，在生成机器代码时客户代码依赖于使用的类的大小，所以虽然没有修改客户代码，但客户代码仍须要被从新编译。这时客户代码的时间戳不能解决问题，必须依赖于这个头文件的时间戳。

所以我认为无论什么时候，把用到的可能修改的头文件加入到依赖关系中能够省去不少麻烦，而这也偏偏反应了实际状况，也让本身对代码的依赖关系更加清晰，也让本身在代码中包含头文件时更加谨慎（仅包含须要的，这也会减小编译时间，减小包含关系错综复杂带来的混乱）。那种能够不写头文件依赖的技巧带来的结果是得不偿失的。

 

----------------------------------------------------------------------------------------------------------------------

用 gcc -M 选项吧

 

----------------------------------------------------------------------------------------------------------------------

若是用GNU make，就会变得很简单了，能够参考下面的Makefile：
mymtom@fc6:src/csdn/make$ cat Makefile
PROG    = hello
SRCS    = main.c hello.c
DEPS    = $(SRCS:.c=.d)
OBJS    = $(SRCS:.c=.o)

RM      = rm -f

.SUFFIXES: .d
.c.d:
        $(CC) -MM $(CPPFLAGS) $< > $@

all:    $(PROG)

dep:    $(DEPS)

hello:  $(OBJS)
        $(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS) -o $@

-include $(DEPS)

clean:
        $(RM) $(OBJS) $(PROG) $(DEPS)

mymtom@fc6:src/csdn/make$ make
cc -MM  hello.c > hello.d
cc -MM  main.c > main.d
cc    -c -o main.o main.c
cc    -c -o hello.o hello.c
cc   main.o hello.o  -o hello
mymtom@fc6:src/csdn/make$ cat main.c
#include <stdio.h>

#include "hello.h"

int main(void)
{
        hello();
        return 0;
}

mymtom@fc6:src/csdn/make$ cat hello.c
#include <stdio.h>

#include "hello.h"

void hello(void)
{
        (void)printf("%s\n", HELLO);
}

mymtom@fc6:src/csdn/make$ cat hello.h
#define HELLO "Hello!"

void hello(void);

mymtom@fc6:src/csdn/make$