904-906.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 114 行
HTML
114 行
<HTML>
<HEAD>
<TITLE>Linux Unleashed, Third Edition:Source Code Control</TITLE>
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!--ISBN=0672313723//-->
<!--TITLE=Linux Unleashed, Third Edition//-->
<!--AUTHOR=Tim Parker//-->
<!--PUBLISHER=Macmillan Computer Publishing//-->
<!--IMPRINT=Sams//-->
<!--CHAPTER=56//-->
<!--PAGES=904-906//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="901-904.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="906-909.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<H4 ALIGN="LEFT"><A NAME="Heading8"></A><FONT COLOR="#000077">Suffix Rules</FONT></H4>
<P>As mentioned earlier in the “Macros” section, <TT>make</TT> does not necessarily require everything to be spelled out for it in the <TT>makefile</TT>. Because <TT>make</TT> was designed to enhance software development in Linux, it knows how the compilers work, especially for C. For example, <TT>make</TT> knows that the C compiler expects to compile source code files having a <TT>.c</TT> suffix and that it generates object files having an <TT>.o</TT> suffix. This knowledge is encapsulated in a suffix rule: <TT>make</TT> examines the suffix of a target or dependent to determine what it should do next.</P>
<P>There are many suffix rules that are internal to <TT>make</TT>, most of which deal with the compilation of source and linking of object files. The default suffix rules that are applicable in your <TT>makefile</TT> are as follows:</P>
<!-- CODE SNIP //-->
<PRE>
.SUFFIXES: .o .c .s
.c.o:
${CC} ${CFLAGS} -c $<
.s.o:
${AS} ${ASFLAGS} -o $@ $<
</PRE>
<!-- END CODE SNIP //-->
<P>The first line is a dependency line stating the suffixes for which <TT>make</TT> should try to find rules if none are explicitly written in the <TT>makefile</TT>. The second dependency line is terse: Essentially, it tells <TT>make</TT> to execute the associated C compile on any file with a <TT>.c</TT> suffix whose corresponding object file (<TT>.o</TT>) is out-of-date. The third line is a similar directive for assembler files. The new macro <TT>$< </TT>has a similar role to that of the <TT>$?</TT> directive, but can only be used in a suffix rule. It represents the dependency that the rule is currently being applied to.</P>
<P>These default suffix rules are powerful in that all you really have to list in your <TT>makefile</TT> are any relevant object files. <TT>make</TT> does the rest: If<TT>main.o</TT> is out-of-date, <TT>make</TT> automatically searches for a <TT>main.c</TT> file to compile. This also works for the <TT>itquick.o</TT> object file. After the object files are updated, the compile of <TT>someonehappy</TT> can execute.</P>
<P>You can also specify your own suffix rules in order to have <TT>make</TT> perform other operations. Say, for instance, that you want to copy object files to another directory after they are compiled. You can explicitly write the appropriate suffix rule in the following way:</P>
<!-- CODE SNIP //-->
<PRE>
.c.o:
${CC} ${CFLAGS} -c $<
cp $@ backup
</PRE>
<!-- END CODE SNIP //-->
<P>The <TT>$@</TT> macro, as you know, refers to the current target. Thus, on the dependency line shown, the target is a <TT>.o</TT> file, and the dependency is the corresponding <TT>.c</TT> file.</P>
<P>Now that you know how to exploit the suffix rule feature of <TT>make</TT>, you can rewrite your <TT>someonehappy makefile</TT> for the last time (you’re probably glad to hear that news).</P>
<!-- CODE //-->
<PRE>
# The final kick at the can
OBJS = main.o dothis.o itquick.o
YN = yes.h no.h
LIB_FILES = /usr/happy/lib/likeatree.a
someonehappy: ${OBJS} ${LIB_FILES}
${CC} -o $@ ${OBJS} ${LIB_FILES}
fresh:
rm *.o
maybe.h: ${YN}
cp $? /users/sue/
</PRE>
<!-- END CODE //-->
<P>This <TT>makefile</TT> works as your first one did, and you can compile the entire program using the following:</P>
<!-- CODE SNIP //-->
<PRE>
$ make someonehappy
</PRE>
<!-- END CODE SNIP //-->
<P>Or, just compile one component of it as follows:
</P>
<!-- CODE SNIP //-->
<PRE>
$ make itquick.o
</PRE>
<!-- END CODE SNIP //-->
<P>This discussion only scratches the surface of <TT>make</TT>. You should refer to the man page for <TT>make</TT> to further explore its many capabilities.</P>
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">RCS</FONT></H3>
<P>One of the other important factors involved in software development is the management of source code files as they evolve. On any type of software project, you might continuously release newer versions of a program as features are added or bugs are fixed. Larger projects usually involve several programmers, which can complicate versioning and concurrency issues even further. In the absence of a system to manage the versioning of source code on your behalf, it is very easy to lose track of the versions of files. This can lead to situations in which modifications are inadvertently wiped out or redundantly coded by different programmers. Fortunately, Linux provides just such a versioning system, called RCS (Revision Control System).
</P>
<P>RCS is just one version control system. There are plenty of others, some public domain, some commercial. SCCS (Source Code Control System) was the first truly workable version control system developed for UNIX and is still in use. RCS is a better system than SCCS, adding many new features and abilities that the older system lacks. There are RCS systems available for most operating system platforms including all UNIX versions, DOS, Windows, and Windows NT. If you have to work on a project with many developers, there is a network-wide version of RCS available called CVS (Concurrent Versions System). CVS is included with many versions of Linux. The commands used by CVS are different than those used by RCS, and since most of you won’t be jumping into network-wide version control yet, we’ll focus on RCS here. The CVS man pages are included with versions of Linux than bundle CVS, if you are curious.</P>
<P>RCS can administer the versioning of files by controlling access to them. For anyone to update a particular file, the person must record in RCS who she is and why she is making the changes. RCS can then record this information along with the updates in an RCS file separate from the original version. Because the updates are kept independent from the original file, you can easily return to any previous version if necessary. This also has the benefit of conserving disk space because you don’t have to keep copies of the entire file around. This is certainly true for situations in which versions differ only by a few lines; it is less useful if there are only a few versions, each of which is largely different from the next.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="901-904.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="906-909.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?