How to write a Makefile

本文介绍了Makefile的基础知识,包括Makefile的命名、组件、目标规则等,并提供了多个实例,帮助读者掌握如何使用Makefile来自动化软件构建过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

How to write a Makefile

Introduction

Make is one of the original Unix tools for Software Engineering. By S.I. Feldman of AT&T Bell Labs circa 1975. But there are public domain versions (eg. GNU) and versions for other systems (eg. Vax/VMS).

Related tools are the language compilers (cc, f77, lex, yacc, etc.) and shell programming tools (eg. awk, sed, cp, rm, etc.). You need to know how to use these.

Important adjuncts are lint (source code checking for obvious errors) ctags (locate functions, etc. in source code) and mkdepend. These are nice, and good programmers use them.

Important, and related tools, are the software revision systems SCCS (Source Code Control System) and RCS (Revision Control System -- the recommended choice)

The idea is to automate and optimize the construction of programs/files -- ie. to leave enough foot prints so that others can follow.

Makefile Naming

make is going to look for a file called Makefile, if not found then a file called makefile. Use the first (so the name stands out in listings).

You can get away without any Makefile (but shouldn't)! Make has default rules it knows about.

Makefile Components

  • Comments

    Comments are any text beginning with the pound (#) sign. A comment can start anywhere on a line and continue until the end of the line. For example:

    # $Id: slides,v 1.2 1992/02/14 21:00:58 reggers Exp $
  • Macros

    Make has a simple macro definition and substitution mechanism. Macros are defined in a Makefile as = pairs. For example:

    MACROS=  -me
    PSROFF= groff -Tps
    DITROFF= groff -Tdvi
    CFLAGS= -O -systype bsd43
    There are lots of default macros -- you should honor the existing naming conventions. To find out what rules/macros make is using type:
    % make -p
    
    NOTE: That your environment variables are exported into the make as macros. They will override the defaults.

    You can set macros on the make command line:

    % make "CFLAGS= -O" "LDFLAGS=-s" printenv
    cc -O printenv.c -s -o printenv
  • Targets

    You make a particular target (eg. make all), in none specified then the first target found:

    paper.dvi: $(SRCS)
    $(DITROFF) $(MACROS) $(SRCS) >paper.dvi
    NOTE: The the line beginning with $(DITROFF) begins with TAB not spaces.
    The target is made if any of the dependent files have changed. The dependent files in this case are represented by the $(SRCS) statement.

  • Continuation of Lines

    Use a back slash (/). This is important for long macros and/or rules.

  • Conventional Macros

    There are lots of default macros (type "make -p" to print out the defaults). Most are pretty obvious from the rules in which they are used:

    AR = ar
    GFLAGS =
    GET = get
    ASFLAGS =
    MAS = mas
    AS = as
    FC = f77
    CFLAGS =
    CC = cc
    LDFLAGS =
    LD = ld
    LFLAGS =
    LEX = lex
    YFLAGS =
    YACC = yacc
    LOADLIBS =
    MAKE = make
    MAKEARGS = 'SHELL=/bin/sh'
    SHELL = /bin/sh
    MAKEFLAGS = b
  • Special Macros

    Before issuing any command in a target rule set there are certain special macros predefined.

    1. $@ is the name of the file to be made.
    2. $? is the names of the changed dependents.

    So, for example, we could use a rule

    printenv: printenv.c
    $(CC) $(CFLAGS) $? $(LDFLAGS) -o $@
    alternatively:
    printenv: printenv.c
    $(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
    There are two more special macros used in implicit rules. They are:
    1. $< the name of the related file that caused the action.
    2. $* the prefix shared by target and dependent files.

  • Makefile Target Rules

    The general syntax of a Makefile Target Rule is

        target [target...] : [dependent ....]
    [ command ...]
    Items in brackets are optional, ellipsis means one or more. Note the tab to preface each command is required.

    The semantics is pretty simple. When you say "make target" make finds the target rule that applies and, if any of the dependents are newer than the target, make executes the com- mands one at a time (after macro substitution). If any dependents have to be made, that happens first (so you have a recursion).

    A make will terminate if any command returns a failure sta- tus. That's why you see rules like:

    clean:
    -rm *.o *~ core paper
    Make ignores the returned status on command lines that begin with a dash. eg. who cares if there is no core file?

    Make will echo the commands, after macro substition to show you what's happening as it happens. Sometimes you might want to turn that off. For example:

    install:
    @echo You must be root to install
  • Example Target Rules

    For example, to manage sources stored within RCS (sometimes you'll need to "check out" a source file):

    SRCS=x.c y.c z.c

    $(SRCS):
    co $@
    To manage sources stored within SCCS (sometimes you'll need to "get" a source file):
    $(SRCS):
    sccs get $@
    Alternativley, to manage sources stored within SCCS or RCS let's generalize with a macro that we can set as required.
    SRCS=x.c y.c z.c
    # GET= sccs get
    GET= co

    $(SRCS):
    $(GET) $@
    For example, to construct a library of object files
    lib.a: x.o y.o z.o
    ar rvu lib.a x.o y.o z.o
    ranlib lib.a
    Alternatively, to be a bit more fancy you could use:
    OBJ=x.o y.o z.o
    AR=ar

    lib.a: $(OBJ)
    $(AR) rvu $@ $(OBJ)
    ranlib $@
    Since AR is a default macro already assigned to "ar" you can get away without defining it (but shouldn't).

    If you get used to using macros you'll be able to make a few rules that you can use over and over again.
    For example, to construct a library in some other directory

    INC=../misc
    OTHERS=../misc/lib.a

    $(OTHERS):
    cd $(INC); make lib.a
    Beware:, the following will not work (but you'd think it should)
    INC=../misc
    OTHERS=../misc/lib.a

    $(OTHERS):
    cd $(INC)
    make lib.a
    Each command in the target rule is executed in a separate shell. This makes for some interesting constructs and long continuation lines.

    To generate a tags file

    SRCS=x.c y.c z.c
    CTAGS=ctags -x >tags

    tags: $(SRCS)
    ${CTAGS} $(SRCS)
    On large projects a tags file, that lists all functions and their invocations is a handy tool.
    To generate a listing of likely bugs in your problems
    lint:
    lint $(CFLAGS) $(SRCS)
    Lint is a really good tool for finding those obvious bugs that slip into programs -- eg. type classes, bad argu- ment list, etc.

  • Some Basic Make Rule

    People have come to expect certain targets in Makefiles. You should always browse first, but it's reasonable to expect that the targets all (or just make), install, and clean will be found.

    1. make all -- should compile everything so that you can do local testing before installing things.
    2. make install -- should install things in the right places. But watch out that things are installed in the right place for your system.
    3. make clean -- should clean things up. Get rid of the executables, any temporary files, object files, etc.

    You may encounter other common targets, some have been already mentioned (tags and lint).

  • An Example Makefile for printenv

    # make the printenv command
    #
    OWNER=bin
    GROUP=bin
    CTAGS= ctags -x >tags
    CFLAGS= -O
    LDFLAGS= -s
    CC=cc
    GET=co
    SRCS=printenv.c
    OBJS=printenv.o
    SHAR=shar
    MANDIR=/usr/man/manl/printenv.l
    BINDIR=/usr/local/bin
    DEPEND= makedepend $(CFLAGS)
    all: printenv

    # To get things out of the revision control system
    $(SRCS):
    $(GET) $@
    # To make an object from source
    $(CC) $(CFLAGS) -c $*.c

    # To make an executable

    printenv: $(OBJS)
    $(CC) $(LDFLAGS) -o $@ $(OBJS)

    # To install things in the right place
    install: printenv printenv.man
    $(INSTALL) -c -o $(OWNER) -g $(GROUP) -m 755 printenv $(BINDIR)
    $(INSTALL) -c -o $(OWNER) -g $(GROUP) -m 644 printenv.man $(MANDIR)

    # where are functions/procedures?
    tags: $(SRCS)
    $(CTAGS) $(SRCS)

    # what have I done wrong?
    lint: $(SRCS)
    lint $(CFLAGS) $(SRCS)

    # what are the source dependencies
    depend: $(SRCS)
    $(DEPEND) $(SRCS)

    # to make a shar distribution
    shar: clean
    $(SHAR) README Makefile printenv.man $(SRCS) >shar

    # clean out the dross
    clean:
    -rm printenv *~ *.o *.bak core tags shar

    # DO NOT DELETE THIS LINE -- make depend depends on it.
    printenv.o: /usr/include/stdio.h
  • Makefile Implicit Rules

    Consider the rule we used for printenv

    printenv: printenv.c
    $(CC) $(CFLAGS) printenv.c $(LDFLAGS) -o printenv
    We generalized a bit to get
    printenv: printenv.c
    $(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
    The command is one that ought to work in all cases where we build an executable x out of the source code x.c This can be stated as an implicit rule:
    .c:
    $(CC) $(CFLAGS) $@.c $(LDFLAGS) -o $@
    This Implicit rule says how to make x out of x.c -- run cc on x.c and call the output x. The rule is implicit because no particular target is mentioned. It can be used in all cases.

    Another common implicit rule is for the construction of .o (object) files out of .c (source files).

    .o.c:
    $(CC) $(CFLAGS) -c $<
    alternatively
    .o.c:
    $(CC) $(CFLAGS) -c $*.c
  • Make Dependencies

    It's pretty common to have source code that uses include files. For example:

    % cat program.c

    #include
    #include "defs.h"
    #include "glob.h"
    etc....
    main(argc,argv)
    etc...
    The implicit rule only covers part of the source code depen- dency (it only knows that program.o depends on program.c). The usual method for handling this is to list the dependen- cies separately;
            etc...
    $(CC) $(CFLAGS) -c $*.c
    etc...
    program.o: program.c defs.h glob.h
    Usually an implicit rule and a separate list of dependencies is all you need. And it ought to be easy enough to figure out what the dependencies are.

    However, there are a number of nice tools around that will automatically generate dependency lists for you. For example (trivial):

    DEPEND= makedepend $(CFLAGS)
    etc...
    # what are the source dependencies

    depend: $(SRCS)
    $(DEPEND) $(SRCS)

    etc....
    # DO NOT DELETE THIS LINE -- ....

    printenv.o: /usr/include/stdio.h
    These tools (mkdepend, mkmkf, etc.) are very common these days and aren't too difficult to use or understand. They're just shell scripts that run cpp (or cc -M, or etc.) to find out what all the include dependencies are. They then just tack the dependency list onto the end of the Makefile.

Based on Make and Makefiles by
Reg Quinton
Computing and Communications Services
The University of Western Ontario
London, Ontario N6A 5B7
Canada


From:
http://www.hsrl.rutgers.edu/ug/make_help.html
资源下载链接为: https://pan.quark.cn/s/1bfadf00ae14 “STC单片机电压测量”是一个以STC系列单片机为基础的电压检测应用案例,它涵盖了硬件电路设计、软件编程以及数据处理等核心知识点。STC单片机凭借其低功耗、高性价比和丰富的I/O接口,在电子工程领域得到了广泛应用。 STC是Specialized Technology Corporation的缩写,该公司的单片机基于8051内核,具备内部振荡器、高速运算能力、ISP(在系统编程)和IAP(在应用编程)功能,非常适合用于各种嵌入式控制系统。 在源代码方面,“浅雪”风格的代码通常简洁易懂,非常适合初学者学习。其中,“main.c”文件是程序的入口,包含了电压测量的核心逻辑;“STARTUP.A51”是启动代码,负责初始化单片机的硬件环境;“电压测量_uvopt.bak”和“电压测量_uvproj.bak”可能是Keil编译器的配置文件备份,用于设置编译选项和项目配置。 对于3S锂电池电压测量,3S锂电池由三节锂离子电池串联而成,标称电压为11.1V。测量时需要考虑电池的串联特性,通过分压电路将高电压转换为单片机可接受的范围,并实时监控,防止过充或过放,以确保电池的安全和寿命。 在电压测量电路设计中,“电压测量.lnp”文件可能包含电路布局信息,而“.hex”文件是编译后的机器码,用于烧录到单片机中。电路中通常会使用ADC(模拟数字转换器)将模拟电压信号转换为数字信号供单片机处理。 在软件编程方面,“StringData.h”文件可能包含程序中使用的字符串常量和数据结构定义。处理电压数据时,可能涉及浮点数运算,需要了解STC单片机对浮点数的支持情况,以及如何高效地存储和显示电压值。 用户界面方面,“电压测量.uvgui.kidd”可能是用户界面的配置文件,用于显示测量结果。在嵌入式系统中,用
资源下载链接为: https://pan.quark.cn/s/abbae039bf2a 在 Android 开发中,Fragment 是界面的一个模块化组件,可用于在 Activity 中灵活地添加、删除或替换。将 ListView 集成到 Fragment 中,能够实现数据的动态加载与列表形式展示,对于构建复杂且交互丰富的界面非常有帮助。本文将详细介绍如何在 Fragment 中使用 ListView。 首先,需要在 Fragment 的布局文件中添加 ListView 的 XML 定义。一个基本的 ListView 元素代码如下: 接着,创建适配器来填充 ListView 的数据。通常会使用 BaseAdapter 的子类,如 ArrayAdapter 或自定义适配器。例如,创建一个简单的 MyListAdapter,继承自 ArrayAdapter,并在构造函数中传入数据集: 在 Fragment 的 onCreateView 或 onActivityCreated 方法中,实例化 ListView 和适配器,并将适配器设置到 ListView 上: 为了提升用户体验,可以为 ListView 设置点击事件监听器: 性能优化也是关键。设置 ListView 的 android:cacheColorHint 属性可提升滚动流畅度。在 getView 方法中复用 convertView,可减少视图创建,提升性能。对于复杂需求,如异步加载数据,可使用 LoaderManager 和 CursorLoader,这能更好地管理数据加载,避免内存泄漏,支持数据变更时自动刷新。 总结来说,Fragment 中的 ListView 使用涉及布局设计、适配器创建与定制、数据绑定及事件监听。掌握这些步骤,可构建功能强大的应用。实际开发中,还需优化 ListView 性能,确保应用流畅运
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值