📄 adding-gnome.html
字号:
<HTML><HEAD><TITLE>Adding GNOME</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="Dealing with Libraries"HREF="dealing-with-libraries.html"><LINKREL="NEXT"TITLE="Graphics"HREF="graphics.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="dealing-with-libraries.html">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom">Chapter 3. The GNOME Build Environment</TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="graphics.html">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="ADDING-GNOME">Adding GNOME</A></H1><P> Most of the information presented so far in this chapter has been pretty generic. You could apply it to virtually any open-source UNIX project. Here's where we tie it all together, adding the GNOME side of things. </P><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN568">GNOME Macros</A></H2><P> GNOME is a very complicated environment by itself; furthermore, all of it sits on top of the X Window System and the GIMP Toolkit (GTK+), each one of which is complex enough to leave your head spinning for weeks. Any measures we can take to ease the confusion and make our software more stable and easier to compile will pay off many times over in the long run. To this end, GNOME supplies quite a few m4 macros that you can use with autoconf. They all fit nicely in your configure.in file, although in some cases you must be careful of the order in which you call them. In particular, the AC_PROG_CC macro must be called before any macros that compile test programs to check for features. </P><P> To use these features you'll need a recent copy of the GNOME macros directory.3 You can get this from the GNOME source code repository-using the Concurrent Versions System (CVS) tool4-in the gnome-common module. Simply copy the macros subdirectory from the gnome-common module into your project, directly under the top-level directory. Then add the following line to configure.in, before any other calls to the GNOME macros: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">AM_ACLOCAL_INCLUDE(macros) </PRE></TD></TR></TABLE><P> This command makes the m4 files in the macros directory available to the autoconf system. If you forget to add it, aclocal won't pull those macros into aclocal.m4, autoconf will fail to expand them, and configure will bail out when it hits the raw, nonexpanded macros because the bash shell does not understand what you mean when you tell it to run the GNOME_INIT command. </P><P> This brings us to one of the most fundamental GNOME macros: GNOME_INIT. GNOME_INIT sets up the compile environment for GNOME, including a host of AC_SUBST macros for such variables as GNOME_LIBS, GNOMEUI_LIBS, GNOME_LIBDIR, and GNOME_INCLUDEDIR. It also tests for the gnome-config script (see Section 3.5.2). For a full accounting, take a look at gnome-common/macros/gnome.m4. </P><P> GNOME relies a lot on the X Window System. Most of the X-specific checks you'll need are covered by the GNOME_X_CHECKS macro. This macro takes care of searching for GTK+, by internally using the AM_PATH_GTK macro (which, incidentally, is installed by GTK+). It also checks for X11 session management, the xpm library, and the pthread library. </P><P> When you're still developing your application, you may want easy control of the number of warnings the compiler generates. GNOME has just the answer for this need: the GNOME_COMPILE_WARNINGS and GNOME_CXX_WARNINGS macros. You can slip either of these macros into configure.in, to enable a wide array of handy compile-time feedback. The former macro is geared toward the C compiler (currently, it's gcc specific), and the latter macro is for C++. To turn on the C warnings, you can add this flag to configure: --enable-com- pile-warnings. The C++ version is --enable-cxx-warnings. The acceptable values are yes, no, and minimum; minimum is the default. Thus if a developer wanted to compile a C++ package with maximum warnings just before a release, he or she could invoke the configure script like this: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">./configure --enable-cxx-warnings=yes </PRE></TD></TR></TABLE><P> The only real difference among the three settings is the variety of -W flags added to the CFLAGS and CXXFLAGS variables. </P></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN579">gnome-config</A></H2><P> After you have configure.in set up, the next logical step is creating the makefile. Nothing in GNOME mandates that you should use automake to generate your makefiles (or even autoconf to set up your configure script). These tools make it much easier to set up a project, but they are still a convenience, not a requirement. If you do decide you want to write all your makefiles by hand, or if you want to compile a single test file from the command line, you will prob- ably want to use the gnome-config tool to keep your compiler options consistent and accurate. You can also use it in your Makefile.am files, although as we'll see in Section 3.5.3, this isn't usually necessary because GNOME takes the liberty of setting up some makefile variables for you. </P><P> The gnome-config tool is a shell script supplied with the gnome-libs package. autoconf creates it during the gnome-libs configuration stage from the gnome-config.in file, substituting the various values that it detects in the GNOME_INIT m4 macro. These variables are hard-coded into the generated gnome-config script; you can access them in many forms, through command line options to gnome-config. For example, if you need to know the install prefix to the gnome-libs package, you can call gnome-config --prefix. The GNOME include directory is in gnome-config --includedir, and the libraries are in gnome-config --libdir. Thus if you wanted to set a variable in your handwritten makefile for the GNOME include path, you could do something like this: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">GNOME_INCLUDE_DIR=`gnome-config --includedir`MYAPP_CFLAGS="-I$(gnome_include_dir)" </PRE></TD></TR></TABLE><P> Notice the special back-ticks around the command (commonly found in the upper left-hand corner of the keyboard, on the same key as the tilde, ~), as opposed to the normal single quotation marks (usually found on the same key as the double quotation mark). The back-ticks instruct a shell to execute the contents they delineate and use the results of that command instead of the text of the command. This is known as a command expansion. </P><P> When you use back-ticks inside a makefile, the command will not be expanded until make fires off a shell to execute a rule that references it. make blindly passes it on to the shell, unaware that the back-ticks mean anything special. Thus you should depend on the expanded form of back-ticks only within the context of makefile rules. </P><P> In the example just given, if gnome-libs were installed to /usr/local, the $(GNOME_INCLUDE_DIR) variable would resolve to /usr/local/include when it was used in a make rule, but it would still contain the contents `gnome-config --includedir` anytime it was referenced inside the makefile. </P><P> An alternative GNU-specific syntax for command expansion instructs make to execute a shell immediately rather than waiting for a makefile rule. It takes the form of $(shell command). You can use this form without the limitations of the back-tick form, but be aware that this second form is not supported by most non-GNU flavors of make. With the GNU form of command expansion, our example would look like this: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">GNOME_INCLUDE_DIR=$(shell gnome-config --includedir) </PRE></TD></TR></TABLE><P> If you're using autoconf and automake and you've included the GNOME_INIT macro in your configure.in file, things will be even easier for you. The $(GNOME_CONFIG) variable will be available to your Makefile.am files, and you should use that instead of calling gnome-config directly. In most cases, however, you shouldn't need to invoke gnome-config at all. GNOME_INIT defines some helpful makefile variables on the basis of some commonly used invocations of gnome-config, including the imaginary $gnome_include_dir variable we introduced here. We'll go into these variables in more detail in Section 3.5.3. </P><P> The gnome-config script also lets you poll various GNOME library modules for information about such things as version numbers, compile-time flags, and link-time flags. gnome-config addresses two types of modules: core modules that are integrated directly into the gnome-config script, and external modules that gnome-config dynamically detects during runtime. You can get a list of both types of modules by running gnome-config --help at the command line. The core libraries are listed in the "Known values for LIBRARY" section of the output; the external modules come at the very end of the help message. Listing 3.7 shows one possible listing of the options for a typical gnome-libs installation. </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">Listing 3.7 Output of gnome-config --help$ gnome-config --helpUsage: gnome-config [OPTION]... [LIBRARY]...Generic options --version output gnome version information. --modversion output the module version information. --help display this help and exit.Compilation support options --cflags print pre-processor and compiler flags --libs print library linking information --libs-only-L only print the -L/-R part of --libs --libs-only-l only print the -l part of --libsInstall directories gnome-libs was configured to --prefix --exec-prefix --bindir --sbindir --libexecdir --datadir --sysconfdir --sharedstatedir --localstatedir --libdir --infodir --mandir --includedirKnown values for LIBRARY are: glib (calls glib-config) idl (to be used with orbit-idl) gnome gnomeui gnorba gtk (calls gtk-config) gtkxmhtml (only --libs) zvt (only --libs)If LIBRARY is none of these, /opt/gnome/lib/<LIBRARY>Conf.shis looked in for the necessary information. Those currentlyinstalled appear to be:applets, bonobo, capplet, docklets, gdk_pixbuf,gnomecanvaspixbuf, gnomemm, libIDL, libart, libglade,libgtop, obGnome, print, vfs, vfscorba, vfspthread, xml </PRE></TD></TR></TABLE><P> To retrieve information about a specific module, include that module on the command line with the appropriate flag. If you wanted to find out what compiler flags you should use in your new GNOME application, you could add the following lines to your makefile: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">MYAPP_CFLAGS=`gnome-config gnomeui --cflags`MYAPP_LDFLAGS=`gnome-config gnomeui --libs` </PRE></TD></TR></TABLE><P> These two commands will give you all the compile options you need to build a GNOME application. From the command line, they look something like this, assuming gnome-libs was installed with a prefix of /opt/gnome: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ gnome-config gnomeui --cflags-I/opt/gnome/include -DNEED_GNOMESUPPORT_H-I/opt/gnome/lib/gnome-libs/include-I/opt/gnome/lib/glib/include$ gnome-config gnomeui --libs-rdynamic -L/opt/gnome/lib -L/usr/X11/lib -lgnomeui -lart_lgpl-lgdk_imlib -lSM -lICE -lgtk -lgdk -lgmodule -lXext -lX11 -lm-lgnome -lgnomesupport -ldb -lglib -ldl </PRE></TD></TR></TABLE><P> If for some reason you need to separate the library objects (-l) from the library paths (-L), you can use the --libs-only-l and --libs-only-L options instead. </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ gnome-config gnomeui --libs-only-l-rdynamic -lgnomeui -lart_lgpl -lgdk_imlib -lSM -lICE -lgtk-lgdk -lgmodule -lXext -lX11 -lm -lgnome -lgnomesupport -ldb-lglib -ldl$ gnome-config gnomeui --libs-only-L-rdynamic -L/opt/gnome/lib -L/usr/X11/lib </PRE></TD></TR></TABLE><P> To find out the name and version number of an installed package, you can use the --modversion parameter. As the name implies, this parameter works predictably only on the external modules. The return value for --modversion defaults to the version of gnome-libs; if a module doesn't explicitly override it, gnome-config will return that default. This leads to confusing behavior, like this: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ gnome-config --modversion bonobobonobo-0.10$ gnome-config --modversion gtkgnome-libs-1.2.0 </PRE></TD></TR></TABLE><P> GTK+ does not share a version number with gnome-libs. If you want to find out the version number of GTK+ or GLib, you should call gtk-config or glib-config directly. If you want to know the version of gnome-libs itself, you should use --version instead of --modversion. </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">$ gtk-config --version1.2.8$ gnome-config --versiongnome-libs 1.2.0⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -