浅析Makefile不要使用make -e传递变量,会导致莫名问题,直接使用make var1=value传递
因为Makefile中有变量CROSS_COMPILE和LINUXDIR,使用-e传递导致莫名其妙的编译问题,
可以直接使用make LINUXDIR=/vobs/works/lnx2625pxa CROSS_COMPILE=arm-eabi-来编译
使用make LINUXDIR=/vobs/works/lnx2625pxa赋值的变量,在Makefile脚本中的所有赋值操作都将被自动忽略,比如在Makefile中
LINUXDIR := /sdfsdflkjlasdf/sdlfjsldfj
CROSS_COMPILE := sdsfsdfddsdf
那么这2个赋值操作都因为make传递了这2个变量的终极数值,而将这2个赋值语句完全忽略掉.
使用如下-e环境变量方式传递LINUXDIR导致严重错误,不能编译出modules
luther@gliethttp:/vobs/works/broadcom/src/bcmsdio/linux$
make -e CROSS_COMPILE=arm-eabi- -e ARCH=arm -e LINUXDIR=/vobs/works/lnx2625pxa/ -j4
不需要-e,直接传递变量,这样数值也就直接传递到要进行make的Makefile了:
luther@gliethttp:/vobs/works/broadcom/src/bcmsdio/linux$ make LINUXDIR=/vobs/works/lnx2625pxa CROSS_COMPILE=arm-eabi-
或者将这2个变量直接放到/vobs/works/broadcom/src/bcmsdio/linux/Makefile中
LINUXDIR := /vobs/works/lnx2625pxa
CROSS_COMPILE := arm-eabi-
也可以正常编译出ko,以上开源源码可以使用如下命令检出:
git clone git://android.git.kernel.org/platform/system/wlan/broadcom.git
以下内容摘自:《GNU-Make中文手册.pdf》
6.9 系统环境变量
make在运行时,系统中的所有环境变量对它都是可见的。在Makefile中,可以引用任何已定义的系统环境变量。(这里我们区分系统环境变量和make的环境变量,系统环境变量是这个系统所有用户所拥有的,而make的环境变量只是对于make的一次执行过程有效,以下正文中出现没有限制的“环境变量”时默认指的是“系统环境变量”,在特殊的场合我们会区分两者)正因为如此,我们就可以设置一个命名为“CFLAGS”的环境变量,用它来指定一个默认的编译选项。就可以在所有的Makefile中直接使用这个变量来对c源代码就行编译。通常这种方式是比较安全的,但是它的前提是大家都明白这个变量所代表的含义,没有人在Makefile中把它作其他的用途。当然了,你也可以在你的Makefile中根据你的需要对它进行重新定义。
使用环境变量需要注意以下几点:
1. 在Makefile中对一个变量的定义或者以make命令行形式对一个变量的定义,都将覆盖同名的环境变量(注意:它并不改变系统环境变量定义,被修改的环境变量只在make执行过程有效)。而make使用“-e”参数时,Makefile和命令行定义的变量不会覆盖同名的环境变量,make将使用系统环境变量中这些变量的定义值。
2. make的递归调用中,所有的系统环境变量会被传递给下一级make。默认情况下,只有环境变量和通过命令行方式定义的变量才会被传递给子make进程。在Makefile中定义的普通变量需要传递给子make时需要使用“export”指示符来对它声明。参考 5.6.2 变量和递归 一小节
3. 一个比较特殊的是环将变量“SHELL”。在系统中这个环境变量的用途是用来指定用户和系统的交互接口,显然对于make是不合适的。因此make的执行环境变量“SHELL”没有使用同名的环境变量定义,而是“/bin/sh”。make默认“/bin/sh”作为它的命令行解释程序(make在执行之前将变量“SHELL”设置
为“/bin/sh”)。(参考 5.2 命令的执行 一小节)
我们不推荐使用环境变量的方式来完成普通变量的工作,特别是在make的递归调用中。任何一个环境变量的错误定义都对系统上的所有make产生影响,甚至是毁坏性的。因为环境变量具有全局的特征。所以尽量不要污染环境变量,造成环境变量名字污染。我想大多数系统管理员都明白环境变量对系统是多么的重要。
阅读(10783) | 评论(1) | 转发(1) |