Makefile 实际用例分析(二) ------- 比较通用的一种架构

简介: 之前已经讲了这一篇文章:Makefile实际用例分析(一)-----比较通用的一种架构 现在这篇其实和那个差的不是很多,只是在布局上有些差别(这个makefile也是论坛上一起讨论过的,囧,忘了哪个论坛)   还是先看看基本的文件布局: 介绍: debug是调试版本的binary文件夹...

之前已经讲了这一篇文章:Makefile实际用例分析(一)-----比较通用的一种架构

现在这篇其实和那个差的不是很多,只是在布局上有些差别(这个makefile也是论坛上一起讨论过的,囧,忘了哪个论坛)

 

还是先看看基本的文件布局:

介绍:

debug是调试版本的binary文件夹

release是发行版本binary文件夹

src是所有的源文件文件夹、

lib是引用库

include一般是引用库头文件之类,或者其他头文件

obj所有.o文件和.d文件

 

src中:依然使用之前的那个ir_tree的例子

 

在lib中有一个外来的引用库,命名为libnew.a,

 

在include中是这个库的头文件new.h:

 

我们对于最基本的文件分别已经清楚了,这种架构下只使用了一个makefile,下面我们具体看看:

 

---------------->>>>>> 我无语了,对csdn格式彻底无语了!这是第三次修改代码格式了,

算了,直接贴成文字吧。。。。。。。。。。。。。。。。。。。。。。。。。。。

 

********温馨提示:由于csdn格式问题,下面的命令前面的TAB都没有了,所以自己写的时候就得加上!

 

#################################
# 常见的配置,不多说
#
SHELL=/bin/sh
CC=gcc
MAKE=make

#################################
# 下面定义的是一些目录路径

MAKE_DIR=.                                           # 当前文件夹
SRC_DIR=$(MAKE_DIR)/src/ # 源文件夹
OBJ_DIR=$(MAKE_DIR)/obj/ # obj文件夹
LIB_DIR=$(MAKE_DIR)/lib/ # 引用库文件夹
INCLUDE_DIR=$(MAKE_DIR)/include/ # include文件夹
DEBUG_DIR=$(MAKE_DIR)/debug/ # debug文件夹

RELEASE_DIR=$(MAKE_DIR)/release/# release文件夹

EXEC_DIR= # 最终的binary文件夹


#################################
# 下面是include路径和库的路径


INCLUDE=-I$(INCLUDE_DIR) -I$(SRC_DIR)
LIB=$(LIB_DIR)/libnew.a -L$(OBJ_DIR) -lm      # 引入库,包括自己的库文件( 如果你将libnew.a放到/usr/lib中了, )

  # 那么直接-lnew就可以了

#################################
# 下面是可执行名称

EXEC=ir_tree

#################################

# 注意:当我们下面出现%.c的时候,先在当前文件夹寻找,如果找不到,那么
#       到下面指定的文件夹中寻找!!!

# 说白就是:如果依赖文件在本文件夹找不到,那么到下面文件夹寻找!仅仅是依赖文件!

vpath %.h $(INCLUDE_DIR)
vpath %.c $(SRC_DIR)
vpath %.o $(OBJ_DIR)
vpath %.d $(OBJ_DIR)

#################################
# 下面是指定SRC  OBJ  DEP
# 注意:都是不带目录的basename

SRC_TMP:=$(wildcard $(SRC_DIR)*.c)
C_SRCS:=$(notdir $(SRC_TMP))                            # 源文件
C_OBJS:=$(patsubst %.c,%.o,$(C_SRCS)) # o文件
C_DEPS:=$(patsubst %.c,%.d,$(C_SRCS)) # deps


#################################
# 编译选项!
#
FLAG_DEBUG=-g
CFLAGS=-O2 -Wall -c

# 下面判断是debug还是release

DEBUG:=1
ifeq ($(DEBUG),1)
EXEC_DIR:=$(DEBUG_DIR)
CFLAGS:=$(CFLAGS) $(FLAG_DEBUG)
else
EXEC_DIR:=$(RELEASE_DIR)
endif


# 最终binary的名称( 路径+名称 )

EXEC:=$(EXEC_DIR)$(EXEC)


################################
# 下面是终极目标all
#

#################################################################
# 关于下面的执行: 
#
# 首先-include $(addprefix $(OBJ_DIR),$(C_DEPS))
# 目的是为了将所有的.d文件包含进来,那么.d文件里面是所有的.o的
# 完整的依赖,那么即使.h被修改了,那么也是可以识别编译的!在第一次
# 处理时,没有.d文件,那么需要找.d的生成规则。因为我们include的是
# $(addprefix $(OBJ_DIR),$(C_DEPS)),那么需要找的依赖是$(OBJ_DIR)%.d
# ,那么OK,这个地方必须注意!如果你include的.d是例如card.d,那么
# 规则必须是:%.d: %.c,而不是$(OBJ_DIR)%.d: %.c。好!现在生成.d文件了
# 然后执行all:$(EXEC),那么需要找依赖$(C_OBJS),本文件夹没有,那么到
# vpath %.o $(OBJ_DIR)中寻找!那么可以因为开始.o是不存在(或者过期的),
# 那么需要寻找生成规则:%.o: %.c %.d,OK生成!
# 等所有的.o处理OK,链接成可执行!
#
#################################################################

#
# 重要理解:
#    1: 你有什么样的依赖,那么就是什么样的一个子规则的目标!
#           例如:$(C_OBJS)是不带目录路径的.o的集合,例如a.o b.o c.o
#           那么,我们需要寻找生成他们的规则,那么肯定有一个子伪目标
#           名称是:(%.o:依赖),而不是($(OBJ_DIR)%.o:依赖),所以
#           要理解哦!

#    2: 注意vpath用途,当“依赖”在本文件夹下找不到的时候,去指定
#           文件夹寻找!
#
#    3:注意Include是将.d文件中的内容加载到当前文件夹中!那么,如果.d
#           里的是例如:card.o: card.c card.h,那么$(C_OBJS)也应该是不带目录
#           路径的*.o形式!!!
#

all:$(EXEC)

$(EXEC): $(C_OBJS)
@echo 'start building  $(notdir $@) ...'
@$(CC)  $(addprefix $(OBJ_DIR),$(notdir $^)) $(LIB) -o $@

#
# 注意关系:每次makefile的时候,需要加载.d文件,那么所有的依赖被加进来
# 但是也必须有$(OBJ_DIR)%.d: %.c,这个是为了当我们的.c改变的时候,例如
# 可能心增加一个include,那么可以改变.d文件!那么后面的处理又是连带关系!
#

# 与上一篇说的一样

%.o: %.c %.d
@echo 'start building $(notdir $@)...'
@$(CC) $(CFLAGS) $< $(INCLUDE) -o $(OBJ_DIR)$@

$(OBJ_DIR)%.d: %.c
@echo 'start building $(notdir $@)...'
@$(CC) $< $(INCLUDE) -MM -MD -o $@

# 将所有的d文件引入,作用,为了更新~
-include $(addprefix $(OBJ_DIR),$(C_DEPS))

clean:
@$(RM) $(OBJ_DIR)*
@$(RM) $(EXEC)
@clear

run:
@$(EXEC)

debug:
@echo $(C_OBJS)
@echo $(C_DEPS)

.PHONY:all clean debug run

 

OK,现在你可以make,然后make run看结果、、、

 

如果你需要这个工程,同样可以免费下载:ir_tree

from:http://blog.csdn.net/shanshanpt/article/details/17199695

目录
相关文章
|
2月前
|
安全 数据处理 数据安全/隐私保护
C/S架构与B/S架构的适用场景分析
C/S架构(客户端/服务器架构)与B/S架构(浏览器/服务器架构)在适用场景上各有特点,主要取决于应用的具体需求、用户群体、系统维护成本、跨平台需求等因素。
234 6
|
19天前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
20天前
|
运维 NoSQL Java
后端架构演进:微服务架构的优缺点与实战案例分析
【10月更文挑战第28天】本文探讨了微服务架构与单体架构的优缺点,并通过实战案例分析了微服务架构在实际应用中的表现。微服务架构具有高内聚、低耦合、独立部署等优势,但也面临分布式系统的复杂性和较高的运维成本。通过某电商平台的实际案例,展示了微服务架构在提升系统性能和团队协作效率方面的显著效果,同时也指出了其带来的挑战。
59 4
|
1月前
|
存储 SQL 分布式计算
湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
【10月更文挑战第7天】湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
90 1
|
2月前
|
存储 监控 安全
SaaS业务架构:业务能力分析
【9月更文挑战第20天】在数字化时代,软件即服务(SaaS)模式逐渐成为企业软件解决方案的首选。SaaS 业务架构设计对于提供高效、可靠的服务至关重要。其核心业务能力包括:用户管理(注册登录、角色权限)、数据管理(存储备份、安全共享)、业务流程管理(设计定制、工作流自动化)、应用集成(第三方应用、移动应用)及客户服务(支持培训、反馈改进)。通过优化这些能力,可为企业提供更高效、可靠的 SaaS 服务。
59 11
|
2月前
|
缓存 负载均衡 数据管理
深入探索微服务架构的核心要素与实践策略在当今软件开发领域,微服务架构以其独特的优势和灵活性,已成为众多企业和开发者的首选。本文将深入探讨微服务架构的核心要素,包括服务拆分、通信机制、数据管理等,并结合实际案例分析其在不同场景下的应用策略,旨在为读者提供一套全面、深入的微服务架构实践指南。**
**微服务架构作为软件开发领域的热门话题,正引领着一场技术革新。本文从微服务架构的核心要素出发,详细阐述了服务拆分的原则与方法、通信机制的选择与优化、数据管理的策略与挑战等内容。同时,结合具体案例,分析了微服务架构在不同场景下的应用策略,为读者提供了实用的指导和建议。
|
3月前
|
前端开发 大数据 数据库
🔥大数据洪流下的决战:JSF 表格组件如何做到毫秒级响应?揭秘背后的性能魔法!💪
【8月更文挑战第31天】在 Web 应用中,表格组件常用于展示和操作数据,但在大数据量下性能会成瓶颈。本文介绍在 JavaServer Faces(JSF)中优化表格组件的方法,包括数据处理、分页及懒加载等技术。通过后端分页或懒加载按需加载数据,减少不必要的数据加载和优化数据库查询,并利用缓存机制减少数据库访问次数,从而提高表格组件的响应速度和整体性能。掌握这些最佳实践对开发高性能 JSF 应用至关重要。
70 0
|
11天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
10天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
10天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
25 1
服务架构的演进:从单体到微服务的探索之旅
下一篇
无影云桌面