cj*版 问个Makefile的问题

想飞的蜗牛

cj*兄 问一个问题。
我现在想编译个工程，但是makefile不会写
工程的文件架构比较复杂，有三个主文件夹lib/和src/、include/
src/下有三个文件夹lan/，free/，open/，还有一个比较重要的文件pmi_main.c

展开应该是这样的:
include       lib        src
                             |
                  lan/  free/ open/   pmi_main.c

include/放的都是头文件，lib/放的是库文件，封装的函数都是给应用程序调用的，比如：pmi_main.c
而src/ 放的三个文件夹是实现底层的，算是驱动层，封装的函数都是给lib/ 的库文件调用。
举个例子
pmi_main.c 的 readdata()是lib/read_data.c实现的函数。
而lib/read_data.c的read_hw_data()是src/free/read_hw_data.c实现的函数。

如此关系的makefile，应该如何写啊？而且同一个文件夹内的函数又有可能相互调用。
能不能把除了pmi_main.c文件其他的东西都打包成一个静态库文件?

我现在实在苦恼，希望能帮帮忙 谢谢！

[ 本帖最后由 想飞的蜗牛 于 2008-9-19 22:08 编辑 ]

cjaizss

1. 
   
2. 最简单的方式:
   
3. gcc -Iinclude `find . -name '*.c'`
   

复制代码

还要链接别的什么吗?链接再加上
makefile懒得写了

周杰伦

http://www.ibm.com/developerworks/cn/linux/l-makefile/

想飞的蜗牛

to cj*
系统下没有find。
用的os是windows
编译工程用的是Tornado自带的编译器和make
其实你的意思是说把所有的文件都放在一起编译算了?

to 周杰伦
1.项目是在windows下
2.项目还要插到别的工程里面去

周杰伦

那就只能好好啃Makefile了，找个gnu make中文手册看看，看看例子，改改。

cjaizss

呵呵,之前没有在UNIX-like OS下工作过吗?我觉得写makefile是在UNIX下写C语言代码的基本功啊

cjaizss

试试这个

1. 
   
2. CC=
   
3. vpath %.o lib src/lan src/free src/open src/
   
4. vpath %.c lib src/lan src/free src/open src/
   
5. vpath %.a lib
   
6. CFLAGS=-Iinclude
   
7. SRC=$(wildcard src/*.c)
   
8. LIB_SRC=$(wildcard lib/*.c)
   
9. LIB_DEP_SRC=$(wildcard src/lan/*.c src/free/*.c src/open/*.c)
   
10. .PHONY:all
    
11. all:libtest.a app
    
12. app:libtest.a $(SRC:%.c=%.o)
    
13.         $(CC) $^ -o $@
    
14. libtest.a:$(LIB_SRC:%c=%.o) $(LIB_DEP_SRC:%.c=%.o)
    
15.         ar rcs $^ -o lib/libtest.a
    

复制代码

前面有空格的地方你需要把它改成\t
因为你没有UNIX下的这些好工具,那么Makefile只好暂时写的这样
有些地方你或许还得自己改改,比如CC=?...........可是不懂Makefile的话,或许比较难改

想飞的蜗牛

呵呵 在linux环境工作过
makefile我看得懂，也知道怎样修改 简单的makefile也会写
但是就没怎么动手写过 所以这次就遇到难题了 遇到一堆文件夹就不知道怎样动手

谢谢你的makefile了，我后来想想打包成静态库不太方便修改
不过不打包成静态库的话，会不会遇到很多.o文件由于编译顺序都没办法链接其他.o文件呢
恩，太多疑问了，我还是晚上好好想想一个好办法再问你

prolj

以后不要写Makefile了，autotools很难用，而且Win上不方便，用CMake，KDE项目组开发的跨平台Makefile生成软件，生成的Makefile很漂亮，比yacc生成的c好看多了。

eveson

跟你说个思路，首先对于一个工程源代码，每个需要编译的目录写一个makeifle，确保单独的这个makefile可以编译通过，然后在源代码目录的顶层写一个总的makefile，调用底下的各个makefile，结构层次清晰，易于维护。屡试不爽。