diff options
Diffstat (limited to 'doc/gettext_11.html')
| -rw-r--r-- | doc/gettext_11.html | 707 |
1 files changed, 707 insertions, 0 deletions
diff --git a/doc/gettext_11.html b/doc/gettext_11.html new file mode 100644 index 0000000..ea125d0 --- /dev/null +++ b/doc/gettext_11.html @@ -0,0 +1,707 @@ +<HTML> +<HEAD> +<!-- This HTML file has been created by texi2html 1.51 + from gettext.texi on 19 April 2001 --> + +<TITLE>GNU gettext utilities - 11 The Maintainer's View</TITLE> +</HEAD> +<BODY> +Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_10.html">previous</A>, <A HREF="gettext_12.html">next</A>, <A HREF="gettext_14.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>. +<P><HR><P> + + +<H1><A NAME="SEC72" HREF="gettext_toc.html#TOC72">11 The Maintainer's View</A></H1> + +<P> +The maintainer of a package has many responsibilities. One of them +is ensuring that the package will install easily on many platforms, +and that the magic we described earlier (see section <A HREF="gettext_8.html#SEC37">8 The User's View</A>) will work +for installers and end users. + +</P> +<P> +Of course, there are many possible ways by which GNU <CODE>gettext</CODE> +might be integrated in a distribution, and this chapter does not cover +them in all generality. Instead, it details one possible approach which +is especially adequate for many free software distributions following GNU +standards, or even better, Gnits standards, because GNU <CODE>gettext</CODE> +is purposely for helping the internationalization of the whole GNU +project, and as many other good free packages as possible. So, the +maintainer's view presented here presumes that the package already has +a <TT>`configure.in'</TT> file and uses GNU Autoconf. + +</P> +<P> +Nevertheless, GNU <CODE>gettext</CODE> may surely be useful for free packages +not following GNU standards and conventions, but the maintainers of such +packages might have to show imagination and initiative in organizing +their distributions so <CODE>gettext</CODE> work for them in all situations. +There are surely many, out there. + +</P> +<P> +Even if <CODE>gettext</CODE> methods are now stabilizing, slight adjustments +might be needed between successive <CODE>gettext</CODE> versions, so you +should ideally revise this chapter in subsequent releases, looking +for changes. + +</P> + + + +<H2><A NAME="SEC73" HREF="gettext_toc.html#TOC73">11.1 Flat or Non-Flat Directory Structures</A></H2> + +<P> +Some free software packages are distributed as <CODE>tar</CODE> files which unpack +in a single directory, these are said to be <STRONG>flat</STRONG> distributions. +Other free software packages have a one level hierarchy of subdirectories, using +for example a subdirectory named <TT>`doc/'</TT> for the Texinfo manual and +man pages, another called <TT>`lib/'</TT> for holding functions meant to +replace or complement C libraries, and a subdirectory <TT>`src/'</TT> for +holding the proper sources for the package. These other distributions +are said to be <STRONG>non-flat</STRONG>. + +</P> +<P> +We cannot say much about flat distributions. A flat +directory structure has the disadvantage of increasing the difficulty +of updating to a new version of GNU <CODE>gettext</CODE>. Also, if you have +many PO files, this could somewhat pollute your single directory. +Also, GNU <CODE>gettext</CODE>'s libintl sources consist of C sources, shell +scripts, <CODE>sed</CODE> scripts and complicated Makefile rules, which don't +fit well into an existing flat structure. For these reasons, we +recommend to use non-flat approach in this case as well. + +</P> +<P> +Maybe because GNU <CODE>gettext</CODE> itself has a non-flat structure, +we have more experience with this approach, and this is what will be +described in the remaining of this chapter. Some maintainers might +use this as an opportunity to unflatten their package structure. + +</P> + + +<H2><A NAME="SEC74" HREF="gettext_toc.html#TOC74">11.2 Prerequisite Works</A></H2> + +<P> +There are some works which are required for using GNU <CODE>gettext</CODE> +in one of your package. These works have some kind of generality +that escape the point by point descriptions used in the remainder +of this chapter. So, we describe them here. + +</P> + +<UL> +<LI> + +Before attempting to use <CODE>gettextize</CODE> you should install some +other packages first. +Ensure that recent versions of GNU <CODE>m4</CODE>, GNU Autoconf and GNU +<CODE>gettext</CODE> are already installed at your site, and if not, proceed +to do this first. If you got to install these things, beware that +GNU <CODE>m4</CODE> must be fully installed before GNU Autoconf is even +<EM>configured</EM>. + +To further ease the task of a package maintainer the <CODE>automake</CODE> +package was designed and implemented. GNU <CODE>gettext</CODE> now uses this +tool and the <TT>`Makefile'</TT>s in the <TT>`intl/'</TT> and <TT>`po/'</TT> +therefore know about all the goals necessary for using <CODE>automake</CODE> +and <TT>`libintl'</TT> in one project. + +Those four packages are only needed to you, as a maintainer; the +installers of your own package and end users do not really need any of +GNU <CODE>m4</CODE>, GNU Autoconf, GNU <CODE>gettext</CODE>, or GNU <CODE>automake</CODE> +for successfully installing and running your package, with messages +properly translated. But this is not completely true if you provide +internationalized shell scripts within your own package: GNU +<CODE>gettext</CODE> shall then be installed at the user site if the end users +want to see the translation of shell script messages. + +<LI> + +Your package should use Autoconf and have a <TT>`configure.in'</TT> file. +If it does not, you have to learn how. The Autoconf documentation +is quite well written, it is a good idea that you print it and get +familiar with it. + +<LI> + +Your C sources should have already been modified according to +instructions given earlier in this manual. See section <A HREF="gettext_3.html#SEC13">3 Preparing Program Sources</A>. + +<LI> + +Your <TT>`po/'</TT> directory should receive all PO files submitted to you +by the translator teams, each having <TT>`<VAR>ll</VAR>.po'</TT> as a name. +This is not usually easy to get translation +work done before your package gets internationalized and available! +Since the cycle has to start somewhere, the easiest for the maintainer +is to start with absolutely no PO files, and wait until various +translator teams get interested in your package, and submit PO files. + +</UL> + +<P> +It is worth adding here a few words about how the maintainer should +ideally behave with PO files submissions. As a maintainer, your role is +to authentify the origin of the submission as being the representative +of the appropriate translating teams of the Translation Project (forward +the submission to <TT>`translation@iro.umontreal.ca'</TT> in case of doubt), +to ensure that the PO file format is not severely broken and does not +prevent successful installation, and for the rest, to merely to put these +PO files in <TT>`po/'</TT> for distribution. + +</P> +<P> +As a maintainer, you do not have to take on your shoulders the +responsibility of checking if the translations are adequate or +complete, and should avoid diving into linguistic matters. Translation +teams drive themselves and are fully responsible of their linguistic +choices for the Translation Project. Keep in mind that translator teams are <EM>not</EM> +driven by maintainers. You can help by carefully redirecting all +communications and reports from users about linguistic matters to the +appropriate translation team, or explain users how to reach or join +their team. The simplest might be to send them the <TT>`ABOUT-NLS'</TT> file. + +</P> +<P> +Maintainers should <EM>never ever</EM> apply PO file bug reports +themselves, short-cutting translation teams. If some translator has +difficulty to get some of her points through her team, it should not be +an issue for her to directly negotiate translations with maintainers. +Teams ought to settle their problems themselves, if any. If you, as +a maintainer, ever think there is a real problem with a team, please +never try to <EM>solve</EM> a team's problem on your own. + +</P> + + +<H2><A NAME="SEC75" HREF="gettext_toc.html#TOC75">11.3 Invoking the <CODE>gettextize</CODE> Program</A></H2> + +<P> +Some files are consistently and identically needed in every package +internationalized through GNU <CODE>gettext</CODE>. As a matter of +convenience, the <CODE>gettextize</CODE> program puts all these files right +in your package. This program has the following synopsis: + +</P> + +<PRE> +gettextize [ <VAR>option</VAR>... ] [ <VAR>directory</VAR> ] +</PRE> + +<P> +and accepts the following options: + +</P> +<DL COMPACT> + +<DT><SAMP>`-c'</SAMP> +<DD> +<DT><SAMP>`--copy'</SAMP> +<DD> +Copy the needed files instead of making symbolic links. Using links +would allow the package to always use the latest <CODE>gettext</CODE> code +available on the system, but it might disturb some mechanism the +maintainer is used to apply to the sources. Because running +<CODE>gettextize</CODE> is easy there shouldn't be problems with using copies. + +<DT><SAMP>`-f'</SAMP> +<DD> +<DT><SAMP>`--force'</SAMP> +<DD> +Force replacement of files which already exist. + +<DT><SAMP>`-h'</SAMP> +<DD> +<DT><SAMP>`--help'</SAMP> +<DD> +Display this help and exit. + +<DT><SAMP>`--version'</SAMP> +<DD> +Output version information and exit. + +</DL> + +<P> +If <VAR>directory</VAR> is given, this is the top level directory of a +package to prepare for using GNU <CODE>gettext</CODE>. If not given, it +is assumed that the current directory is the top level directory of +such a package. + +</P> +<P> +The program <CODE>gettextize</CODE> provides the following files. However, +no existing file will be replaced unless the option <CODE>--force</CODE> +(<CODE>-f</CODE>) is specified. + +</P> + +<OL> +<LI> + +The <TT>`ABOUT-NLS'</TT> file is copied in the main directory of your package, +the one being at the top level. This file gives the main indications +about how to install and use the Native Language Support features +of your program. You might elect to use a more recent copy of this +<TT>`ABOUT-NLS'</TT> file than the one provided through <CODE>gettextize</CODE>, +if you have one handy. You may also fetch a more recent copy of file +<TT>`ABOUT-NLS'</TT> from Translation Project sites, and from most GNU +archive sites. + +<LI> + +A <TT>`po/'</TT> directory is created for eventually holding +all translation files, but initially only containing the file +<TT>`po/Makefile.in.in'</TT> from the GNU <CODE>gettext</CODE> distribution. +(beware the double <SAMP>`.in'</SAMP> in the file name). If the <TT>`po/'</TT> +directory already exists, it will be preserved along with the files +it contains, and only <TT>`Makefile.in.in'</TT> will be overwritten. + +<LI> + +A <TT>`intl/'</TT> directory is created and filled with most of the files +originally in the <TT>`intl/'</TT> directory of the GNU <CODE>gettext</CODE> +distribution. Also, if option <CODE>--force</CODE> (<CODE>-f</CODE>) is given, +the <TT>`intl/'</TT> directory is emptied first. + +</OL> + +<P> +If your site support symbolic links, <CODE>gettextize</CODE> will not +actually copy the files into your package, but establish symbolic +links instead. This avoids duplicating the disk space needed in +all packages. Merely using the <SAMP>`-h'</SAMP> option while creating the +<CODE>tar</CODE> archive of your distribution will resolve each link by an +actual copy in the distribution archive. So, to insist, you really +should use <SAMP>`-h'</SAMP> option with <CODE>tar</CODE> within your <CODE>dist</CODE> +goal of your main <TT>`Makefile.in'</TT>. + +</P> +<P> +It is interesting to understand that most new files for supporting +GNU <CODE>gettext</CODE> facilities in one package go in <TT>`intl/'</TT> +and <TT>`po/'</TT> subdirectories. One distinction between these two +directories is that <TT>`intl/'</TT> is meant to be completely identical +in all packages using GNU <CODE>gettext</CODE>, while all newly created +files, which have to be different, go into <TT>`po/'</TT>. There is a +common <TT>`Makefile.in.in'</TT> in <TT>`po/'</TT>, because the <TT>`po/'</TT> +directory needs its own <TT>`Makefile'</TT>, and it has been designed so +it can be identical in all packages. + +</P> + + +<H2><A NAME="SEC76" HREF="gettext_toc.html#TOC76">11.4 Files You Must Create or Alter</A></H2> + +<P> +Besides files which are automatically added through <CODE>gettextize</CODE>, +there are many files needing revision for properly interacting with +GNU <CODE>gettext</CODE>. If you are closely following GNU standards for +Makefile engineering and auto-configuration, the adaptations should +be easier to achieve. Here is a point by point description of the +changes needed in each. + +</P> +<P> +So, here comes a list of files, each one followed by a description of +all alterations it needs. Many examples are taken out from the GNU +<CODE>gettext</CODE> 0.10.37 distribution itself. You may indeed +refer to the source code of the GNU <CODE>gettext</CODE> package, as it +is intended to be a good example and master implementation for using +its own functionality. + +</P> + + + +<H3><A NAME="SEC77" HREF="gettext_toc.html#TOC77">11.4.1 <TT>`POTFILES.in'</TT> in <TT>`po/'</TT></A></H3> + +<P> +The <TT>`po/'</TT> directory should receive a file named +<TT>`POTFILES.in'</TT>. This file tells which files, among all program +sources, have marked strings needing translation. Here is an example +of such a file: + +</P> + +<PRE> +# List of source files containing translatable strings. +# Copyright (C) 1995 Free Software Foundation, Inc. + +# Common library files +lib/error.c +lib/getopt.c +lib/xmalloc.c + +# Package source files +src/gettext.c +src/msgfmt.c +src/xgettext.c +</PRE> + +<P> +Hash-marked comments and white lines are ignored. All other lines +list those source files containing strings marked for translation +(see section <A HREF="gettext_3.html#SEC15">3.2 How Marks Appear in Sources</A>), in a notation relative to the top level +of your whole distribution, rather than the location of the +<TT>`POTFILES.in'</TT> file itself. + +</P> + + +<H3><A NAME="SEC78" HREF="gettext_toc.html#TOC78">11.4.2 <TT>`configure.in'</TT> at top level</A></H3> + + +<OL> +<LI>Declare the package and version. + +This is done by a set of lines like these: + + +<PRE> +PACKAGE=gettext +VERSION=0.10.37 +AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE") +AC_DEFINE_UNQUOTED(VERSION, "$VERSION") +AC_SUBST(PACKAGE) +AC_SUBST(VERSION) +</PRE> + +Of course, you replace <SAMP>`gettext'</SAMP> with the name of your package, +and <SAMP>`0.10.37'</SAMP> by its version numbers, exactly as they +should appear in the packaged <CODE>tar</CODE> file name of your distribution +(<TT>`gettext-0.10.37.tar.gz'</TT>, here). + +<LI>Declare the available translations. + +This is done by defining <CODE>ALL_LINGUAS</CODE> to the white separated, +quoted list of available languages, in a single line, like this: + + +<PRE> +ALL_LINGUAS="de fr" +</PRE> + +This example means that German and French PO files are available, so +that these languages are currently supported by your package. If you +want to further restrict, at installation time, the set of installed +languages, this should not be done by modifying <CODE>ALL_LINGUAS</CODE> in +<TT>`configure.in'</TT>, but rather by using the <CODE>LINGUAS</CODE> environment +variable (see section <A HREF="gettext_8.html#SEC39">8.2 Magic for Installers</A>). + +<LI>Check for internationalization support. + +Here is the main <CODE>m4</CODE> macro for triggering internationalization +support. Just add this line to <TT>`configure.in'</TT>: + + +<PRE> +AM_GNU_GETTEXT +</PRE> + +This call is purposely simple, even if it generates a lot of configure +time checking and actions. + +<LI>Have output files created. + +The <CODE>AC_OUTPUT</CODE> directive, at the end of your <TT>`configure.in'</TT> +file, needs to be modified in two ways: + + +<PRE> +AC_OUTPUT([<VAR>existing configuration files</VAR> intl/Makefile po/Makefile.in], +<VAR>existing additional actions</VAR>]) +</PRE> + +The modification to the first argument to <CODE>AC_OUTPUT</CODE> asks +for substitution in the <TT>`intl/'</TT> and <TT>`po/'</TT> directories. +Note the <SAMP>`.in'</SAMP> suffix used for <TT>`po/'</TT> only. This is because +the distributed file is really <TT>`po/Makefile.in.in'</TT>. + +</OL> + + + +<H3><A NAME="SEC79" HREF="gettext_toc.html#TOC79">11.4.3 <TT>`config.guess'</TT>, <TT>`config.sub'</TT> at top level</A></H3> + +<P> +You need to add the GNU <TT>`config.guess'</TT> and <TT>`config.sub'</TT> files +to your distribution. They are needed because the <TT>`intl/'</TT> directory +has platform dependent support for determining the locale's character +encoding and therefore needs to identify the platform. + +</P> +<P> +You can obtain the newest version of <TT>`config.guess'</TT> and +<TT>`config.sub'</TT> from <TT>`ftp://ftp.gnu.org/pub/gnu/config/'</TT>. +Less recent versions are also contained in the GNU <CODE>automake</CODE> and +GNU <CODE>libtool</CODE> packages. + +</P> +<P> +Normally, <TT>`config.guess'</TT> and <TT>`config.sub'</TT> are put at the +top level of a distribution. But it is also possible to put them in a +subdirectory, altogether with other configuration support files like +<TT>`install-sh'</TT>, <TT>`ltconfig'</TT>, <TT>`ltmain.sh'</TT>, +<TT>`mkinstalldirs'</TT> or <TT>`missing'</TT>. All you need to do, other than +moving the files, is to add the following line to your +<TT>`configure.in'</TT>. + +</P> + +<PRE> +AC_CONFIG_AUX_DIR([<VAR>subdir</VAR>]) +</PRE> + + + +<H3><A NAME="SEC80" HREF="gettext_toc.html#TOC80">11.4.4 <TT>`aclocal.m4'</TT> at top level</A></H3> + +<P> +If you do not have an <TT>`aclocal.m4'</TT> file in your distribution, +the simplest is to concatenate the files <TT>`codeset.m4'</TT>, +<TT>`gettext.m4'</TT>, <TT>`iconv.m4'</TT>, <TT>`isc-posix.m4'</TT>, +<TT>`lcmessage.m4'</TT>, <TT>`progtest.m4'</TT> from GNU <CODE>gettext</CODE>'s +<TT>`m4/'</TT> directory into a single file. + +</P> +<P> +If you already have an <TT>`aclocal.m4'</TT> file, then you will have +to merge the said macro files into your <TT>`aclocal.m4'</TT>. Note that if +you are upgrading from a previous release of GNU <CODE>gettext</CODE>, you +should most probably <EM>replace</EM> the macros (<CODE>AM_GNU_GETTEXT</CODE>, +<CODE>AM_WITH_NLS</CODE>, etc.), as they usually +change a little from one release of GNU <CODE>gettext</CODE> to the next. +Their contents may vary as we get more experience with strange systems +out there. + +</P> +<P> +These macros check for the internationalization support functions +and related informations. Hopefully, once stabilized, these macros +might be integrated in the standard Autoconf set, because this +piece of <CODE>m4</CODE> code will be the same for all projects using GNU +<CODE>gettext</CODE>. + +</P> + + +<H3><A NAME="SEC81" HREF="gettext_toc.html#TOC81">11.4.5 <TT>`acconfig.h'</TT> at top level</A></H3> + +<P> +Earlier GNU <CODE>gettext</CODE> releases required to put definitions for +<CODE>ENABLE_NLS</CODE>, <CODE>HAVE_GETTEXT</CODE> and <CODE>HAVE_LC_MESSAGES</CODE>, +<CODE>HAVE_STPCPY</CODE>, <CODE>PACKAGE</CODE> and <CODE>VERSION</CODE> into an +<TT>`acconfig.h'</TT> file. This is not needed any more; you can remove +them from your <TT>`acconfig.h'</TT> file unless your package uses them +independently from the <TT>`intl/'</TT> directory. + +</P> + + +<H3><A NAME="SEC82" HREF="gettext_toc.html#TOC82">11.4.6 <TT>`Makefile.in'</TT> at top level</A></H3> + +<P> +Here are a few modifications you need to make to your main, top-level +<TT>`Makefile.in'</TT> file. + +</P> + +<OL> +<LI> + +Add the following lines near the beginning of your <TT>`Makefile.in'</TT>, +so the <SAMP>`dist:'</SAMP> goal will work properly (as explained further down): + + +<PRE> +PACKAGE = @PACKAGE@ +VERSION = @VERSION@ +</PRE> + +<LI> + +Add file <TT>`ABOUT-NLS'</TT> to the <CODE>DISTFILES</CODE> definition, so the file gets +distributed. + +<LI> + +Wherever you process subdirectories in your <TT>`Makefile.in'</TT>, be sure +you also process dir subdirectories <SAMP>`intl'</SAMP> and <SAMP>`po'</SAMP>. Special +rules in the <TT>`Makefiles'</TT> take care for the case where no +internationalization is wanted. + +If you are using Makefiles, either generated by automake, or hand-written +so they carefully follow the GNU coding standards, the effected goals for +which the new subdirectories must be handled include <SAMP>`installdirs'</SAMP>, +<SAMP>`install'</SAMP>, <SAMP>`uninstall'</SAMP>, <SAMP>`clean'</SAMP>, <SAMP>`distclean'</SAMP>. + +Here is an example of a canonical order of processing. In this +example, we also define <CODE>SUBDIRS</CODE> in <CODE>Makefile.in</CODE> for it +to be further used in the <SAMP>`dist:'</SAMP> goal. + + +<PRE> +SUBDIRS = doc intl lib src @POSUB@ +</PRE> + +Note that you must arrange for <SAMP>`make'</SAMP> to descend into the +<CODE>intl</CODE> directory before descending into other directories containing +code which make use of the <CODE>libintl.h</CODE> header file. For this +reason, here we mention <CODE>intl</CODE> before <CODE>lib</CODE> and <CODE>src</CODE>. + +that you will have to adapt to your own package. + +<LI> + +A delicate point is the <SAMP>`dist:'</SAMP> goal, as both +<TT>`intl/Makefile'</TT> and <TT>`po/Makefile'</TT> will later assume that the +proper directory has been set up from the main <TT>`Makefile'</TT>. Here is +an example at what the <SAMP>`dist:'</SAMP> goal might look like: + + +<PRE> +distdir = $(PACKAGE)-$(VERSION) +dist: Makefile + rm -fr $(distdir) + mkdir $(distdir) + chmod 777 $(distdir) + for file in $(DISTFILES); do \ + ln $$file $(distdir) 2>/dev/null || cp -p $$file $(distdir); \ + done + for subdir in $(SUBDIRS); do \ + mkdir $(distdir)/$$subdir || exit 1; \ + chmod 777 $(distdir)/$$subdir; \ + (cd $$subdir && $(MAKE) $@) || exit 1; \ + done + tar chozf $(distdir).tar.gz $(distdir) + rm -fr $(distdir) +</PRE> + +</OL> + + + +<H3><A NAME="SEC83" HREF="gettext_toc.html#TOC83">11.4.7 <TT>`Makefile.in'</TT> in <TT>`src/'</TT></A></H3> + +<P> +Some of the modifications made in the main <TT>`Makefile.in'</TT> will +also be needed in the <TT>`Makefile.in'</TT> from your package sources, +which we assume here to be in the <TT>`src/'</TT> subdirectory. Here are +all the modifications needed in <TT>`src/Makefile.in'</TT>: + +</P> + +<OL> +<LI> + +In view of the <SAMP>`dist:'</SAMP> goal, you should have these lines near the +beginning of <TT>`src/Makefile.in'</TT>: + + +<PRE> +PACKAGE = @PACKAGE@ +VERSION = @VERSION@ +</PRE> + +<LI> + +If not done already, you should guarantee that <CODE>top_srcdir</CODE> +gets defined. This will serve for <CODE>cpp</CODE> include files. Just add +the line: + + +<PRE> +top_srcdir = @top_srcdir@ +</PRE> + +<LI> + +You might also want to define <CODE>subdir</CODE> as <SAMP>`src'</SAMP>, later +allowing for almost uniform <SAMP>`dist:'</SAMP> goals in all your +<TT>`Makefile.in'</TT>. At list, the <SAMP>`dist:'</SAMP> goal below assume that +you used: + + +<PRE> +subdir = src +</PRE> + +<LI> + +The <CODE>main</CODE> function of your program will normally call +<CODE>bindtextdomain</CODE> (see see section <A HREF="gettext_3.html#SEC14">3.1 Triggering <CODE>gettext</CODE> Operations</A>), like this: + + +<PRE> +bindtextdomain (<VAR>PACKAGE</VAR>, LOCALEDIR); +</PRE> + +To make LOCALEDIR known to the program, add the following lines to +Makefile.in: + + +<PRE> +datadir = @datadir@ +localedir = $(datadir)/locale +DEFS = -DLOCALEDIR=\"$(localedir)\" @DEFS@ +</PRE> + +Note that <CODE>@datadir@</CODE> defaults to <SAMP>`$(prefix)/share'</SAMP>, thus +<CODE>$(localedir)</CODE> defaults to <SAMP>`$(prefix)/share/locale'</SAMP>. + +<LI> + +You should ensure that the final linking will use <CODE>@INTLLIBS@</CODE> as +a library. An easy way to achieve this is to manage that it gets into +<CODE>LIBS</CODE>, like this: + + +<PRE> +LIBS = @INTLLIBS@ @LIBS@ +</PRE> + +In most packages internationalized with GNU <CODE>gettext</CODE>, one will +find a directory <TT>`lib/'</TT> in which a library containing some helper +functions will be build. (You need at least the few functions which the +GNU <CODE>gettext</CODE> Library itself needs.) However some of the functions +in the <TT>`lib/'</TT> also give messages to the user which of course should be +translated, too. Taking care of this it is not enough to place the support +library (say <TT>`libsupport.a'</TT>) just between the <CODE>@INTLLIBS@</CODE> +and <CODE>@LIBS@</CODE> in the above example. Instead one has to write this: + + +<PRE> +LIBS = ../lib/libsupport.a @INTLLIBS@ ../lib/libsupport.a @LIBS@ +</PRE> + +<LI> + +You should also ensure that directory <TT>`intl/'</TT> will be searched for +C preprocessor include files in all circumstances. So, you have to +manage so both <SAMP>`-I../intl'</SAMP> and <SAMP>`-I$(top_srcdir)/intl'</SAMP> will +be given to the C compiler. + +<LI> + +Your <SAMP>`dist:'</SAMP> goal has to conform with others. Here is a +reasonable definition for it: + + +<PRE> +distdir = ../$(PACKAGE)-$(VERSION)/$(subdir) +dist: Makefile $(DISTFILES) + for file in $(DISTFILES); do \ + ln $$file $(distdir) 2>/dev/null || cp -p $$file $(distdir); \ + done +</PRE> + +</OL> + +<P><HR><P> +Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_10.html">previous</A>, <A HREF="gettext_12.html">next</A>, <A HREF="gettext_14.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>. +</BODY> +</HTML> |