creating-configuration.html
来自「linux下gnome编程」· HTML 代码 · 共 947 行 · 第 1/3 页
HTML
947 行
<HTML><HEAD><TITLE>Creating Your Own Configuration</TITLE><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.61"><LINKREL="HOME"TITLE="Writing GNOME Applications"HREF="index.html"><LINKREL="UP"TITLE="The GNOME Build Environment"HREF="gnome-build.html"><LINKREL="PREVIOUS"TITLE="The GNOME Build Environment"HREF="gnome-build.html"><LINKREL="NEXT"TITLE="Generating Makefiles"HREF="generating-makefiles.html"></HEAD><BODYCLASS="SECT1"><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-build.html">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 3. The GNOME Build Environment</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="generating-makefiles.html">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="CREATING-CONFIGURATION">Creating Your Own Configuration</A></H1><P> In Section 3.1 we saw the work that a tiny two-line, seemingly do-nothing configure.in macro script can do when run through the autoconf tool. In this section we'll see more of the power of autoconf unleashed. The autoconf package is distributed with a huge collection of macros, each of which is prefixed with "AC_". These macros expand into shell script code in the configure file, capable of searching the target system for compilers, external libraries, include files, and even specific functions inside libraries and include files. You can place these macros with their respective parameters in configure.in or even write your own macros from scratch if the standard macros won't do the job. It all ends up as a shell script, so your only limitations are what the shell can do. </P><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN333">Autoconf</A></H2><P> The autoconf system is the gatekeeper of all your configuration needs. As the name suggests, autoconf performs automated configuration. The interesting thing about autoconf is that it runs on the developer's machine but doesn't do its real magic until its generated scripts run on the end user's machine. It's like a time-released depth charge. </P><P> This setup solves many problems for the developer. Most importantly, it reduces the number of software dependencies that the system administrator needs when installing the software. The developer must have autoconf, automake, and possibly libtool on the development machine, but the output of these tools consists for the most part of generic shell scripts. Thus to compile and install software that has been processed by autoconf, all you need is a command line shell (available on every flavor of UNIX in existence), a compiler, and a recent enough version of make. </P><P> The configure.in script should always start with the AC_INIT macro and always end with the AC_OUTPUT macro. AC_INIT processes any command line options you might have given while running configure; it also double-checks the compile directory to make sure your build environment is in good shape. If the file you supply as a parameter to AC_INIT does not exist in the source tree, the generated configure script will bail out with an error message. You should always try to use a uniquely named source file for this check so that configure can quickly detect a dubious compilation environ- ment. </P><P> The autoconf system handles automatic file generation with the AC_OUTPUT macro. You supply a space-delimited list of target files you want the configure script to create; configure then searches for a file in the same path with ".in" appended to it and uses that as a template for creating the final output file. Thus if you wanted to perform variable substitutions on a shell script template init-app.sh.in in the root of the source tree, and on a Makefile.in in the src subdirectory, you would use the following command: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">AC_OUTPUT(init-app.sh src/Makefile) </PRE></TD></TR></TABLE></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN340">The Configuration Header</A></H2><P> As we saw in the previous section, you can pass a value directly to your makefiles with AC_SUBST. This macro will cause autoconf to insert the variable's value into the text of the makefile. You can then use it however you need to in the makefile, including passing it on to the compiler as part of its command line string. </P><P> However, if all you want to do is define some values foryour code with #define, autoconf has a special macro for the job,AC_DEFINE. Normally autoconf places these values, formatted for yourcompile line, into a globally available makefile variable,DEFS. Internally, autoconf calls AC_SUBST(DEFS) to imprint it in yourmakefiles, so you will still need to put a @DEFS@ declarationsomewhere in your Makefile.in file in order to use it (unless you useautomake, as described in Section 3.3.2). The prototype for AC_DEFINElooks like this: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">AC_DEFINE (VARIABLE [, VALUE [, DESCRIPTION]]) </PRE></TD></TR></TABLE><P> The VARIABLE parameter gives autoconf the name of the C constant to define; VARIABLE is the only required parameter. VALUE allows you to specify the contents of VARIABLE and defaults to 1 if you omit it. The DESCRIPTION parameter lets you specify a descriptive comment for the #define statement, but it is used only in conjunction with the AC_CONFIG_HEADER macro, as we'll see in a moment. </P><P> Try adding the following lines to configure.in somewhere between AC_INIT and AC_OUTPUT: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">AC_DEFINE(USE_FOO)AC_DEFINE(APPNAME, "myapp") </PRE></TD></TR></TABLE><P> Then add this line anywhere in Makefile.in: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">MYDEFS = @DEFS@ </PRE></TD></TR></TABLE><P> Run autoconf again-because we've modified configure.in-and then run the freshly created configure script to regenerate the makefile. The makefile has gained the line </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">MYDEFS = -DUSE_FOO=1 -DAPPNAME=\"myapp\" </PRE></TD></TR></TABLE><P> The autoconf script added the compiler-specific -D options for us and even took the opportunity to tack on "=1" as a default value to the USE_FOO definition. Unlike AC_SUBST, which puts each declaration into a separate variable, all invocations to AC_DEFINE will concatenate their arguments onto the end of the DEFS variable. If you tried to do this with AC_SUBST, you would end up with code like this in the Makefile.in file: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">MYDEFS = "-DUSE_FOO=@USE_FOO@ -DAPPNAME=@APPNAME@" </PRE></TD></TR></TABLE><P> A couple of these substitutions aren't too bad, but once you get into a larger, more complex project with 10 or 20 (or more!) declared variables, you'll be glad that you don't have to maintain this all by hand. You just call AC_DEFINE on each one as you go, and autoconf takes care of the rest. </P><P> This brings up a small problem with using AC_DEFINE and DEFS: scalability. If you have 10 -D options in every command line, your compile outputs will become voluminous and hard to read. The important stuff will become lost in a sea of compile parameters. To deal with this situation, autoconf has an alternate mode of handling AC_DEFINE that is much more scalable than using DEFS. autoconf can place all your AC_DEFINE declarations into a header file, which you can then add to your source files with the #include directive. You announce which header file you want to use with the AC_CONFIG_HEADER macro. You'll typically want to call this macro right after AC_INIT, as the second macro in your configure.in file. </P><P> Of course, it's not quite as easy as all that. autoconf also needs a template file to tell it how to format the configuration header. The configuration header file is usually named config.h, and the template file is usually the configuration file with the familiar ".in" suffix, config.h.in. As far as autoconf is concerned, it is entirely your job to create this header file, although the autoconf distribution comes with a little tool, autoheader, that automatically generates a config.h.in file for you on the basis of the contents of your configure.in file. </P><P> The config.h.in file looks like any normal C header file, except it contains only comments and #define statements, according to what you passed into the AC_DEFINE macro (this is where the DESCRIPTION parameter comes into play). All of⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?