韦东山2440_第一期学习笔记_009_arm_linux_gcc和makefile

最新推荐文章于 2022-04-10 15:48:09 发布

又一个小垃圾

最新推荐文章于 2022-04-10 15:48:09 发布

阅读量209

点赞数

分类专栏： # 韦东山_jz2440

本文链接：https://blog.csdn.net/weixin_42215853/article/details/107268151

版权

韦东山_jz2440 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

文章目录

1.arm_linucx_gcc
2.makefile

1.arm_linucx_gcc

2.makefile

001_Makefile的引入

使用keil, mdk, avr等工具开发程序时点点鼠标就可以编译了，
它的内部机制是什么？它怎么组织管理程序？怎么决定编译哪一个文件？（其实内部也是makefile类似的编译，不过在桌面上集成度更好，开发更加的简单。在Linux和ARM中运行资源没有Windows那么好，所以采用这种方式。）

首先列举一个比较简单的例子。

编写主函数a.c

  1 #include <stdio.h>
  2 int main ()
  3 {
  4     func_b();
  5     return 0;
  6 }

编写辅助函数 b.c

  1 #include <stdio.h>
  4 void func_b()
  5 {
  6     printf("this is B !\n");
  7 }

运行结果

linux@linux:~/csdn/wprk7.10$ gcc -o test  a.c b.c
linux@linux:~/csdn/wprk7.10$ ./test
this is B !

实际现象如图：

gcc -o test  a.c  b.c  
这样生成test 可执行文件，我们分析一下他的产生的过程，
.C文件大致时经过这样的过程：
1.预处理（）
2.编译
3.汇编
4.链接

其中： 1 2 3 可以合称为：编译。
a.c==>编译后==>生成xxx.s==>链接后==>生成xxx.o
b.c==>编译后==>生成yyy.s==>链接后==>生成yyy.o
xxx.o 和 yyy.o 合在一起生成test文件。

举的例子是一个很简单的一个程序, 但是如上的gcc 操作会对所有的文件都处理一次, 如上1234的过程。
但是，文件多时如果只修改其中一个文件，但是却要编译整个工程，这样会导致开发效率变低，而makefile有一个很好的机制.
我们不妨想一下在进行STM32和STC51单片机的开发的时候，第一次“编译”程序要等好久，但是进行修改后，第二次在编译速度就会快很多，有没有注意到这个细节。。啊哈！！！
官方的说法是： xxx.o文件的生成需要时间，在编译生成 xxx.o文件后，如果下一次再编译的时候发现没有发生变化（具体的操作可能是时间戳？？？），就不对这个文件再次编译，那么就会节省出相应的时间。
makefile，就是这样的原理。或者说keil5的第二次编译变快，就是，，makefile 的原因。哈哈！！

002_Makefile的核心 : 规则 :


目标 : 依赖1 依赖2 ...

[TAB]命令

当目标不存在的时候，或者依赖比目标新的时候，执行命令。

test：a.o b.o
	gcc -o test a.o b.o 
a.o:a.c
	gcc-c -o a.o a.c
b.o:b.c
	gcc-c -o b.o b.c
代码片如下列出：

在这里插入图片描述

我们可以看到下面的图片，我已经make一次了，更改了b.c重新make一次，得到下面的图片。
重新make只是a.c发生了变化。再次make提示 "test is up to date " 也就是说test已经最新不再需要编译了。
所以，可以想 一个是在keil5中第二次编译速度变快，另一个是我们需要make 来方便的进行编译和提升速度
（如果代码量从两个.增加到了100个.c那么一个一个的进行输入，将是一个噩梦。）

在这里插入图片描述