?? gnome-build.html
字號:
<HTML><HEAD><TITLE>The GNOME Build Environment</TITLE><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.61"><LINKREL="HOME"TITLE="Writing GNOME Applications"HREF="index.html"><LINKREL="PREVIOUS"TITLE="GNOME"HREF="gnome-intro.html"><LINKREL="NEXT"TITLE="Creating Your Own Configuration"HREF="creating-configuration.html"></HEAD><BODYCLASS="CHAPTER"><DIVCLASS="NAVHEADER"><TABLEWIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">Writing GNOME Applications</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="gnome-intro.html">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="creating-configuration.html">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="CHAPTER"><H1><ANAME="GNOME-BUILD">Chapter 3. The GNOME Build Environment</A></H1><DIVCLASS="TOC"><DL><DT><B>Table of Contents</B></DT><DT><AHREF="gnome-build.html#CONFIGURATION-SCRIPT">The Configuration Script</A></DT><DT><AHREF="creating-configuration.html">Creating Your Own Configuration</A></DT><DT><AHREF="generating-makefiles.html">Generating Makefiles</A></DT><DT><AHREF="dealing-with-libraries.html">Dealing with Libraries</A></DT><DT><AHREF="adding-gnome.html">Adding GNOME</A></DT></DL></DIV><P> Part of writing a proper GNOME application is knowing how everything fits into the big picture. GNOME is not 100 percent GNOME code, but rather a rich strata, each layer depending on the layer beneath to support it. </P><P> GNOME uses the GNU build system, a powerful suite of tools created to ease the burden of compiling, porting, and installing free software. This build system employs macros and scripts to deal with the repetitive drudgery that software projects normally require. No longer will you have to spend hours and hours handcrafting build scripts and cutting and pasting makefile rules into new projects. The GNU build system can produce a complete, full-blooded compilation environment for your project with as little as three files and a dozen handwritten lines of text. All the reams of duplicated setup code are automatically generated by the GNU build tools. As a result, you can spend your valuable time writing code rather than fiddling around with makefiles. </P><P> Software installation is another major source of headaches; a poorly written installation setup can lead to a package that won't run or install on the user's system. A crabby, frustrated user may never touch your software package again, regardless of the amazing wonders it can perform once it's up and run- ning. New software projects have enough to worry about, without alienating potential users. A clean, simple, reliable installation gives your software a professional appearance and will lead to return customers. </P><P> The three main components of the GNU build system are autoconf, automake, and libtool. We'll explore the ins and outs of each of these components in this chapter. These tools also come with extensive documentation, available through the info command-for example, info autoconf. </P><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="CONFIGURATION-SCRIPT">The Configuration Script</A></H1><P> If you've installed many open-source software packages, you've probably run across the popular configure script. This configuration script automatically scans your system, running a series of checks, compiling and running little test programs, and reporting all the results to the software package you're trying to install. The new software can then use this information to tune itself to the particular quirks of your system. </P><P> The configuration script is very handy when it comes to porting your application to different brands of UNIX. For example, if you wanted to use a somewhat exotic function call from the C library but knew it wasn't supported on all platforms, you could check for it in the configuration script. If the configuration script found the function call on system A, your code could use it directly. However, if the function call didn't exist on system B, you could provide a fallback routine to use instead. All of this would happen at compile time, on the target system. Obviously this type of configuration script would not work with binary-only software. It is practical only when you can use it to tweak the compile settings and react to it at the source code level. </P><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN293">Running configure</A></H2><P> The following series of commands is all the user needs to do to set up, compile, and install most software distributions created with the autoconf system. The commands are always the same, so the process is easily predictable for the inexperienced installer. The only thing different between packages is that there are extra command line options you can use with configure. </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ ./configure$ make$ make install </PRE></TD></TR></TABLE><P> All GNU-based configure scripts come with a basic set of command line parameters; you can get a list of them at any time by typing in </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ ./configure --help </PRE></TD></TR></TABLE><P> You can use these parameters to control where configure installs the software, which extra components to use (or not use), how much debug information to generate, and where to find external libraries and header files. The package owner can also add new parameters to handle special situations unique to a software package. All these parameters have sensible defaults, so it's usually a safe bet to run configure with no parameters. In normal usage, you'll probably need to include only the --prefix parameter, if you want to change the target install location. By default, configure puts things in the /usr/local directory. If you wanted to install the software in a special directory-for example, if it was beta software, or just something you didn't want polluting your normal install directories-you might do something like this: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ ./configure --prefix=/custom/path </PRE></TD></TR></TABLE><P> configure would then install the software into /custom/path/bin, /custom/path/lib, and the like. If you decided to keep the software, you could run configure again without the --prefix option and rebuild, and it would install things into /usr/local/bin, /usr/local/lib, and so on. </P><P> That's a lot of black magic, right? You're probably wondering how it all works, and how hard it would be to create a configure script for your own project. At its essence, the configure script is nothing more than a long, complex shell script. If you had to write it by hand, you would spend half your time debugging it and converting it for new projects. Fortunately, the GNU build system provides a simple-to-use set of tools for automatically generating configure scripts (and much more). We'll explore these tools in Sections 3.2 and 3.3. </P></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN303">Inside the configure Script</A></H2><P> For now, let's create a minimal configure script and see what it looks like. Create a temporary directory somewhere, and then run the following commands: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ echo "AC_INIT(main.c)\nAC_OUTPUT(Makefile)" > configure.in$ cat configure.inAC_INIT(main.c)AC_OUTPUT(Makefile)$ touch main.c Makefile.in?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -