git.saurik.com Git - wxWidgets.git/blame_incremental - docs/html/gettext/gettext

... / ...

Commit	Line	Data
	1	<HTML>
	2	<HEAD>
	3	<!-- This HTML file has been created by texi2html 1.54
	4	from gettext.texi on 25 January 1999 -->
	5
	6	<TITLE>GNU gettext utilities - The Maintainer's View</TITLE>
	7	<link href="gettext_11.html" rel=Next>
	8	<link href="gettext_9.html" rel=Previous>
	9	<link href="gettext_toc.html" rel=ToC>
	10
	11	</HEAD>
	12	<BODY>
	13	<p>Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_9.html">previous</A>, <A HREF="gettext_11.html">next</A>, <A HREF="gettext_12.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
	14	<P><HR><P>
	15
	16
	17	<H1><A NAME="SEC67" HREF="gettext_toc.html#TOC67">The Maintainer's View</A></H1>
	18
	19	<P>
	20	The maintainer of a package has many responsibilities. One of them
	21	is ensuring that the package will install easily on many platforms,
	22	and that the magic we described earlier (see section <A HREF="gettext_7.html#SEC35">The User's View</A>) will work
	23	for installers and end users.
	24
	25	</P>
	26	<P>
	27	Of course, there are many possible ways by which GNU <CODE>gettext</CODE>
	28	might be integrated in a distribution, and this chapter does not cover
	29	them in all generality. Instead, it details one possible approach which
	30	is especially adequate for many free software distributions following GNU
	31	standards, or even better, Gnits standards, because GNU <CODE>gettext</CODE>
	32	is purposely for helping the internationalization of the whole GNU
	33	project, and as many other good free packages as possible. So, the
	34	maintainer's view presented here presumes that the package already has
	35	a <TT>`configure.in'</TT> file and uses GNU Autoconf.
	36
	37	</P>
	38	<P>
	39	Nevertheless, GNU <CODE>gettext</CODE> may surely be useful for free packages
	40	not following GNU standards and conventions, but the maintainers of such
	41	packages might have to show imagination and initiative in organizing
	42	their distributions so <CODE>gettext</CODE> work for them in all situations.
	43	There are surely many, out there.
	44
	45	</P>
	46	<P>
	47	Even if <CODE>gettext</CODE> methods are now stabilizing, slight adjustments
	48	might be needed between successive <CODE>gettext</CODE> versions, so you
	49	should ideally revise this chapter in subsequent releases, looking
	50	for changes.
	51
	52	</P>
	53
	54
	55
	56	<H2><A NAME="SEC68" HREF="gettext_toc.html#TOC68">Flat or Non-Flat Directory Structures</A></H2>
	57
	58	<P>
	59	Some free software packages are distributed as <CODE>tar</CODE> files which unpack
	60	in a single directory, these are said to be <STRONG>flat</STRONG> distributions.
	61	Other free software packages have a one level hierarchy of subdirectories, using
	62	for example a subdirectory named <TT>`doc/'</TT> for the Texinfo manual and
	63	man pages, another called <TT>`lib/'</TT> for holding functions meant to
	64	replace or complement C libraries, and a subdirectory <TT>`src/'</TT> for
	65	holding the proper sources for the package. These other distributions
	66	are said to be <STRONG>non-flat</STRONG>.
	67
	68	</P>
	69	<P>
	70	For now, we cannot say much about flat distributions. A flat
	71	directory structure has the disadvantage of increasing the difficulty
	72	of updating to a new version of GNU <CODE>gettext</CODE>. Also, if you have
	73	many PO files, this could somewhat pollute your single directory.
	74	In the GNU <CODE>gettext</CODE> distribution, the <TT>`misc/'</TT> directory
	75	contains a shell script named <TT>`combine-sh'</TT>. That script may
	76	be used for combining all the C files of the <TT>`intl/'</TT> directory
	77	into a pair of C files (one <TT>`.c'</TT> and one <TT>`.h'</TT>). Those two
	78	generated files would fit more easily in a flat directory structure,
	79	and you will then have to add these two files to your project.
	80
	81	</P>
	82	<P>
	83	Maybe because GNU <CODE>gettext</CODE> itself has a non-flat structure,
	84	we have more experience with this approach, and this is what will be
	85	described in the remaining of this chapter. Some maintainers might
	86	use this as an opportunity to unflatten their package structure.
	87	Only later, once gained more experience adapting GNU <CODE>gettext</CODE>
	88	to flat distributions, we might add some notes about how to proceed
	89	in flat situations.
	90
	91	</P>
	92
	93
	94	<H2><A NAME="SEC69" HREF="gettext_toc.html#TOC69">Prerequisite Works</A></H2>
	95
	96	<P>
	97	There are some works which are required for using GNU <CODE>gettext</CODE>
	98	in one of your package. These works have some kind of generality
	99	that escape the point by point descriptions used in the remainder
	100	of this chapter. So, we describe them here.
	101
	102	</P>
	103
	104	<UL>
	105	<LI>
	106
	107	Before attempting to use you should install some other packages first.
	108	Ensure that recent versions of GNU <CODE>m4</CODE>, GNU Autoconf and GNU
	109	<CODE>gettext</CODE> are already installed at your site, and if not, proceed
	110	to do this first. If you got to install these things, beware that
	111	GNU <CODE>m4</CODE> must be fully installed before GNU Autoconf is even
	112	<EM>configured</EM>.
	113
	114	To further ease the task of a package maintainer the <CODE>automake</CODE>
	115	package was designed and implemented. GNU <CODE>gettext</CODE> now uses this
	116	tool and the <TT>`Makefile'</TT>s in the <TT>`intl/'</TT> and <TT>`po/'</TT>
	117	therefore know about all the goals necessary for using <CODE>automake</CODE>
	118	and <TT>`libintl'</TT> in one project.
	119
	120	Those four packages are only needed to you, as a maintainer; the
	121	installers of your own package and end users do not really need any of
	122	GNU <CODE>m4</CODE>, GNU Autoconf, GNU <CODE>gettext</CODE>, or GNU <CODE>automake</CODE>
	123	for successfully installing and running your package, with messages
	124	properly translated. But this is not completely true if you provide
	125	internationalized shell scripts within your own package: GNU
	126	<CODE>gettext</CODE> shall then be installed at the user site if the end users
	127	want to see the translation of shell script messages.
	128
	129	<LI>
	130
	131	Your package should use Autoconf and have a <TT>`configure.in'</TT> file.
	132	If it does not, you have to learn how. The Autoconf documentation
	133	is quite well written, it is a good idea that you print it and get
	134	familiar with it.
	135
	136	<LI>
	137
	138	Your C sources should have already been modified according to
	139	instructions given earlier in this manual. See section <A HREF="gettext_3.html#SEC13">Preparing Program Sources</A>.
	140
	141	<LI>
	142
	143	Your <TT>`po/'</TT> directory should receive all PO files submitted to you
	144	by the translator teams, each having <TT>`<VAR>ll</VAR>.po'</TT> as a name.
	145	This is not usually easy to get translation
	146	work done before your package gets internationalized and available!
	147	Since the cycle has to start somewhere, the easiest for the maintainer
	148	is to start with absolutely no PO files, and wait until various
	149	translator teams get interested in your package, and submit PO files.
	150
	151	</UL>
	152
	153	<P>
	154	It is worth adding here a few words about how the maintainer should
	155	ideally behave with PO files submissions. As a maintainer, your role is
	156	to authentify the origin of the submission as being the representative
	157	of the appropriate translating teams of the Translation Project (forward
	158	the submission to <TT>`translation@iro.umontreal.ca'</TT> in case of doubt),
	159	to ensure that the PO file format is not severely broken and does not
	160	prevent successful installation, and for the rest, to merely to put these
	161	PO files in <TT>`po/'</TT> for distribution.
	162
	163	</P>
	164	<P>
	165	As a maintainer, you do not have to take on your shoulders the
	166	responsibility of checking if the translations are adequate or
	167	complete, and should avoid diving into linguistic matters. Translation
	168	teams drive themselves and are fully responsible of their linguistic
	169	choices for the Translation Project. Keep in mind that translator teams are <EM>not</EM>
	170	driven by maintainers. You can help by carefully redirecting all
	171	communications and reports from users about linguistic matters to the
	172	appropriate translation team, or explain users how to reach or join
	173	their team. The simplest might be to send them the <TT>`ABOUT-NLS'</TT> file.
	174
	175	</P>
	176	<P>
	177	Maintainers should <EM>never ever</EM> apply PO file bug reports
	178	themselves, short-cutting translation teams. If some translator has
	179	difficulty to get some of her points through her team, it should not be
	180	an issue for her to directly negotiate translations with maintainers.
	181	Teams ought to settle their problems themselves, if any. If you, as
	182	a maintainer, ever think there is a real problem with a team, please
	183	never try to <EM>solve</EM> a team's problem on your own.
	184
	185	</P>
	186
	187
	188	<H2><A NAME="SEC70" HREF="gettext_toc.html#TOC70">Invoking the <CODE>gettextize</CODE> Program</A></H2>
	189
	190	<P>
	191	Some files are consistently and identically needed in every package
	192	internationalized through GNU <CODE>gettext</CODE>. As a matter of
	193	convenience, the <CODE>gettextize</CODE> program puts all these files right
	194	in your package. This program has the following synopsis:
	195
	196	</P>
	197
	198	<PRE>
	199	gettextize [ <VAR>option</VAR>... ] [ <VAR>directory</VAR> ]
	200	</PRE>
	201
	202	<P>
	203	and accepts the following options:
	204
	205	</P>
	206	<DL COMPACT>
	207
	208	<DT><SAMP>`-c'</SAMP>
	209	<DD>
	210	<DT><SAMP>`--copy'</SAMP>
	211	<DD>
	212	Copy the needed files instead of making symbolic links. Using links
	213	would allow the package to always use the latest <CODE>gettext</CODE> code
	214	available on the system, but it might disturb some mechanism the
	215	maintainer is used to apply to the sources. Because running
	216	<CODE>gettextize</CODE> is easy there shouldn't be problems with using copies.
	217
	218	<DT><SAMP>`-f'</SAMP>
	219	<DD>
	220	<DT><SAMP>`--force'</SAMP>
	221	<DD>
	222	Force replacement of files which already exist.
	223
	224	<DT><SAMP>`-h'</SAMP>
	225	<DD>
	226	<DT><SAMP>`--help'</SAMP>
	227	<DD>
	228	Display this help and exit.
	229
	230	<DT><SAMP>`--version'</SAMP>
	231	<DD>
	232	Output version information and exit.
	233
	234	</DL>
	235
	236	<P>
	237	If <VAR>directory</VAR> is given, this is the top level directory of a
	238	package to prepare for using GNU <CODE>gettext</CODE>. If not given, it
	239	is assumed that the current directory is the top level directory of
	240	such a package.
	241
	242	</P>
	243	<P>
	244	The program <CODE>gettextize</CODE> provides the following files. However,
	245	no existing file will be replaced unless the option <CODE>--force</CODE>
	246	(<CODE>-f</CODE>) is specified.
	247
	248	</P>
	249
	250	<OL>
	251	<LI>
	252
	253	The <TT>`ABOUT-NLS'</TT> file is copied in the main directory of your package,
	254	the one being at the top level. This file gives the main indications
	255	about how to install and use the Native Language Support features
	256	of your program. You might elect to use a more recent copy of this
	257	<TT>`ABOUT-NLS'</TT> file than the one provided through <CODE>gettextize</CODE>,
	258	if you have one handy. You may also fetch a more recent copy of file
	259	<TT>`ABOUT-NLS'</TT> from Translation Project sites, and from most GNU
	260	archive sites.
	261
	262	<LI>
	263
	264	A <TT>`po/'</TT> directory is created for eventually holding
	265	all translation files, but initially only containing the file
	266	<TT>`po/Makefile.in.in'</TT> from the GNU <CODE>gettext</CODE> distribution.
	267	(beware the double <SAMP>`.in'</SAMP> in the file name). If the <TT>`po/'</TT>
	268	directory already exists, it will be preserved along with the files
	269	it contains, and only <TT>`Makefile.in.in'</TT> will be overwritten.
	270
	271	<LI>
	272
	273	A <TT>`intl/'</TT> directory is created and filled with most of the files
	274	originally in the <TT>`intl/'</TT> directory of the GNU <CODE>gettext</CODE>
	275	distribution. Also, if option <CODE>--force</CODE> (<CODE>-f</CODE>) is given,
	276	the <TT>`intl/'</TT> directory is emptied first.
	277
	278	</OL>
	279
	280	<P>
	281	If your site support symbolic links, <CODE>gettextize</CODE> will not
	282	actually copy the files into your package, but establish symbolic
	283	links instead. This avoids duplicating the disk space needed in
	284	all packages. Merely using the <SAMP>`-h'</SAMP> option while creating the
	285	<CODE>tar</CODE> archive of your distribution will resolve each link by an
	286	actual copy in the distribution archive. So, to insist, you really
	287	should use <SAMP>`-h'</SAMP> option with <CODE>tar</CODE> within your <CODE>dist</CODE>
	288	goal of your main <TT>`Makefile.in'</TT>.
	289
	290	</P>
	291	<P>
	292	It is interesting to understand that most new files for supporting
	293	GNU <CODE>gettext</CODE> facilities in one package go in <TT>`intl/'</TT>
	294	and <TT>`po/'</TT> subdirectories. One distinction between these two
	295	directories is that <TT>`intl/'</TT> is meant to be completely identical
	296	in all packages using GNU <CODE>gettext</CODE>, while all newly created
	297	files, which have to be different, go into <TT>`po/'</TT>. There is a
	298	common <TT>`Makefile.in.in'</TT> in <TT>`po/'</TT>, because the <TT>`po/'</TT>
	299	directory needs its own <TT>`Makefile'</TT>, and it has been designed so
	300	it can be identical in all packages.
	301
	302	</P>
	303
	304
	305	<H2><A NAME="SEC71" HREF="gettext_toc.html#TOC71">Files You Must Create or Alter</A></H2>
	306
	307	<P>
	308	Besides files which are automatically added through <CODE>gettextize</CODE>,
	309	there are many files needing revision for properly interacting with
	310	GNU <CODE>gettext</CODE>. If you are closely following GNU standards for
	311	Makefile engineering and auto-configuration, the adaptations should
	312	be easier to achieve. Here is a point by point description of the
	313	changes needed in each.
	314
	315	</P>
	316	<P>
	317	So, here comes a list of files, each one followed by a description of
	318	all alterations it needs. Many examples are taken out from the GNU
	319	<CODE>gettext</CODE> 0.10.35 distribution itself. You may indeed
	320	refer to the source code of the GNU <CODE>gettext</CODE> package, as it
	321	is intended to be a good example and master implementation for using
	322	its own functionality.
	323
	324	</P>
	325
	326
	327
	328	<H3><A NAME="SEC72" HREF="gettext_toc.html#TOC72"><TT>`POTFILES.in'</TT> in <TT>`po/'</TT></A></H3>
	329
	330	<P>
	331	The <TT>`po/'</TT> directory should receive a file named
	332	<TT>`POTFILES.in'</TT>. This file tells which files, among all program
	333	sources, have marked strings needing translation. Here is an example
	334	of such a file:
	335
	336	</P>
	337
	338	<PRE>
	339	# List of source files containing translatable strings.
	340	# Copyright (C) 1995 Free Software Foundation, Inc.
	341
	342	# Common library files
	343	lib/error.c
	344	lib/getopt.c
	345	lib/xmalloc.c
	346
	347	# Package source files
	348	src/gettextp.c
	349	src/msgfmt.c
	350	src/xgettext.c
	351	</PRE>
	352
	353	<P>
	354	Dashed comments and white lines are ignored. All other lines
	355	list those source files containing strings marked for translation
	356	(see section <A HREF="gettext_3.html#SEC15">How Marks Appears in Sources</A>), in a notation relative to the top level
	357	of your whole distribution, rather than the location of the
	358	<TT>`POTFILES.in'</TT> file itself.
	359
	360	</P>
	361
	362
	363	<H3><A NAME="SEC73" HREF="gettext_toc.html#TOC73"><TT>`configure.in'</TT> at top level</A></H3>
	364
	365
	366	<OL>
	367	<LI>Declare the package and version.
	368
	369	This is done by a set of lines like these:
	370
	371
	372	<PRE>
	373	PACKAGE=gettext
	374	VERSION=0.10.35
	375	AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE")
	376	AC_DEFINE_UNQUOTED(VERSION, "$VERSION")
	377	AC_SUBST(PACKAGE)
	378	AC_SUBST(VERSION)
	379	</PRE>
	380
	381	Of course, you replace <SAMP>`gettext'</SAMP> with the name of your package,
	382	and <SAMP>`0.10.35'</SAMP> by its version numbers, exactly as they
	383	should appear in the packaged <CODE>tar</CODE> file name of your distribution
	384	(<TT>`gettext-0.10.35.tar.gz'</TT>, here).
	385
	386	<LI>Declare the available translations.
	387
	388	This is done by defining <CODE>ALL_LINGUAS</CODE> to the white separated,
	389	quoted list of available languages, in a single line, like this:
	390
	391
	392	<PRE>
	393	ALL_LINGUAS="de fr"
	394	</PRE>
	395
	396	This example means that German and French PO files are available, so
	397	that these languages are currently supported by your package. If you
	398	want to further restrict, at installation time, the set of installed
	399	languages, this should not be done by modifying <CODE>ALL_LINGUAS</CODE> in
	400	<TT>`configure.in'</TT>, but rather by using the <CODE>LINGUAS</CODE> environment
	401	variable (see section <A HREF="gettext_7.html#SEC37">Magic for Installers</A>).
	402
	403	<LI>Check for internationalization support.
	404
	405	Here is the main <CODE>m4</CODE> macro for triggering internationalization
	406	support. Just add this line to <TT>`configure.in'</TT>:
	407
	408
	409	<PRE>
	410	AM_GNU_GETTEXT
	411	</PRE>
	412
	413	This call is purposely simple, even if it generates a lot of configure
	414	time checking and actions.
	415
	416	<LI>Have output files created.
	417
	418	The <CODE>AC_OUTPUT</CODE> directive, at the end of your <TT>`configure.in'</TT>
	419	file, needs to be modified in two ways:
	420
	421
	422	<PRE>
	423	AC_OUTPUT([<VAR>existing configuration files</VAR> intl/Makefile po/Makefile.in],
	424	<VAR>existing additional actions</VAR>])
	425	</PRE>
	426
	427	The modification to the first argument to <CODE>AC_OUTPUT</CODE> asks
	428	for substitution in the <TT>`intl/'</TT> and <TT>`po/'</TT> directories.
	429	Note the <SAMP>`.in'</SAMP> suffix used for <TT>`po/'</TT> only. This is because
	430	the distributed file is really <TT>`po/Makefile.in.in'</TT>.
	431
	432	</OL>
	433
	434
	435
	436	<H3><A NAME="SEC74" HREF="gettext_toc.html#TOC74"><TT>`aclocal.m4'</TT> at top level</A></H3>
	437
	438	<P>
	439	If you do not have an <TT>`aclocal.m4'</TT> file in your distribution,
	440	the simplest is taking a copy of <TT>`aclocal.m4'</TT> from
	441	GNU <CODE>gettext</CODE>. But to be precise, you only need macros
	442	<CODE>AM_LC_MESSAGES</CODE>, <CODE>AM_WITH_NLS</CODE> and <CODE>AM_GNU_GETTEXT</CODE>,
	443	and <CODE>AM_PATH_PROG_WITH_TEST</CODE>, which is called by <CODE>AM_WITH_NLS</CODE>,
	444	so you may use an editor and remove macros you do not need.
	445
	446	</P>
	447	<P>
	448	If you already have an <TT>`aclocal.m4'</TT> file, then you will have
	449	to merge the said macros into your <TT>`aclocal.m4'</TT>. Note that if
	450	you are upgrading from a previous release of GNU <CODE>gettext</CODE>, you
	451	should most probably <EM>replace</EM> the said macros, as they usually
	452	change a little from one release of GNU <CODE>gettext</CODE> to the next.
	453	Their contents may vary as we get more experience with strange systems
	454	out there.
	455
	456	</P>
	457	<P>
	458	These macros check for the internationalization support functions
	459	and related informations. Hopefully, once stabilized, these macros
	460	might be integrated in the standard Autoconf set, because this
	461	piece of <CODE>m4</CODE> code will be the same for all projects using GNU
	462	<CODE>gettext</CODE>.
	463
	464	</P>
	465
	466
	467	<H3><A NAME="SEC75" HREF="gettext_toc.html#TOC75"><TT>`acconfig.h'</TT> at top level</A></H3>
	468
	469	<P>
	470	If you do not have an <TT>`acconfig.h'</TT> file in your distribution, the
	471	simplest is use take a copy of <TT>`acconfig.h'</TT> from GNU
	472	<CODE>gettext</CODE>. But to be precise, you only need the lines and comments
	473	for <CODE>ENABLE_NLS</CODE>, <CODE>HAVE_CATGETS</CODE>, <CODE>HAVE_GETTEXT</CODE> and
	474	<CODE>HAVE_LC_MESSAGES</CODE>, <CODE>HAVE_STPCPY</CODE>, <CODE>PACKAGE</CODE> and
	475	<CODE>VERSION</CODE>, so you may use an editor and remove everything else. If
	476	you already have an <TT>`acconfig.h'</TT> file, then you should merge the
	477	said definitions into your <TT>`acconfig.h'</TT>.
	478
	479	</P>
	480
	481
	482	<H3><A NAME="SEC76" HREF="gettext_toc.html#TOC76"><TT>`Makefile.in'</TT> at top level</A></H3>
	483
	484	<P>
	485	Here are a few modifications you need to make to your main, top-level
	486	<TT>`Makefile.in'</TT> file.
	487
	488	</P>
	489
	490	<OL>
	491	<LI>
	492
	493	Add the following lines near the beginning of your <TT>`Makefile.in'</TT>,
	494	so the <SAMP>`dist:'</SAMP> goal will work properly (as explained further down):
	495
	496
	497	<PRE>
	498	PACKAGE = @PACKAGE@
	499	VERSION = @VERSION@
	500	</PRE>
	501
	502	<LI>
	503
	504	Add file <TT>`ABOUT-NLS'</TT> to the <CODE>DISTFILES</CODE> definition, so the file gets
	505	distributed.
	506
	507	<LI>
	508
	509	Wherever you process subdirectories in your <TT>`Makefile.in'</TT>, be sure
	510	you also process dir subdirectories <SAMP>`intl'</SAMP> and <SAMP>`po'</SAMP>. Special
	511	rules in the <TT>`Makefiles'</TT> take care for the case where no
	512	internationalization is wanted.
	513
	514	If you are using Makefiles, either generated by automake, or hand-written
	515	so they carefully follow the GNU coding standards, the effected goals for
	516	which the new subdirectories must be handled include <SAMP>`installdirs'</SAMP>,
	517	<SAMP>`install'</SAMP>, <SAMP>`uninstall'</SAMP>, <SAMP>`clean'</SAMP>, <SAMP>`distclean'</SAMP>.
	518
	519	Here is an example of a canonical order of processing. In this
	520	example, we also define <CODE>SUBDIRS</CODE> in <CODE>Makefile.in</CODE> for it
	521	to be further used in the <SAMP>`dist:'</SAMP> goal.
	522
	523
	524	<PRE>
	525	SUBDIRS = doc lib @INTLSUB@ src @POSUB@
	526	</PRE>
	527
	528	that you will have to adapt to your own package.
	529
	530	<LI>
	531
	532	A delicate point is the <SAMP>`dist:'</SAMP> goal, as both
	533	<TT>`intl/Makefile'</TT> and <TT>`po/Makefile'</TT> will later assume that the
	534	proper directory has been set up from the main <TT>`Makefile'</TT>. Here is
	535	an example at what the <SAMP>`dist:'</SAMP> goal might look like:
	536
	537
	538	<PRE>
	539	distdir = $(PACKAGE)-$(VERSION)
	540	dist: Makefile
	541	rm -fr $(distdir)
	542	mkdir $(distdir)
	543	chmod 777 $(distdir)
	544	for file in $(DISTFILES); do \
	545	ln $$file $(distdir) 2>/dev/null \|\| cp -p $$file $(distdir); \
	546	done
	547	for subdir in $(SUBDIRS); do \
	548	mkdir $(distdir)/$$subdir \|\| exit 1; \
	549	chmod 777 $(distdir)/$$subdir; \
	550	(cd $$subdir && $(MAKE) $@) \|\| exit 1; \
	551	done
	552	tar chozf $(distdir).tar.gz $(distdir)
	553	rm -fr $(distdir)
	554	</PRE>
	555
	556	</OL>
	557
	558
	559
	560	<H3><A NAME="SEC77" HREF="gettext_toc.html#TOC77"><TT>`Makefile.in'</TT> in <TT>`src/'</TT></A></H3>
	561
	562	<P>
	563	Some of the modifications made in the main <TT>`Makefile.in'</TT> will
	564	also be needed in the <TT>`Makefile.in'</TT> from your package sources,
	565	which we assume here to be in the <TT>`src/'</TT> subdirectory. Here are
	566	all the modifications needed in <TT>`src/Makefile.in'</TT>:
	567
	568	</P>
	569
	570	<OL>
	571	<LI>
	572
	573	In view of the <SAMP>`dist:'</SAMP> goal, you should have these lines near the
	574	beginning of <TT>`src/Makefile.in'</TT>:
	575
	576
	577	<PRE>
	578	PACKAGE = @PACKAGE@
	579	VERSION = @VERSION@
	580	</PRE>
	581
	582	<LI>
	583
	584	If not done already, you should guarantee that <CODE>top_srcdir</CODE>
	585	gets defined. This will serve for <CODE>cpp</CODE> include files. Just add
	586	the line:
	587
	588
	589	<PRE>
	590	top_srcdir = @top_srcdir@
	591	</PRE>
	592
	593	<LI>
	594
	595	You might also want to define <CODE>subdir</CODE> as <SAMP>`src'</SAMP>, later
	596	allowing for almost uniform <SAMP>`dist:'</SAMP> goals in all your
	597	<TT>`Makefile.in'</TT>. At list, the <SAMP>`dist:'</SAMP> goal below assume that
	598	you used:
	599
	600
	601	<PRE>
	602	subdir = src
	603	</PRE>
	604
	605	<LI>
	606
	607	You should ensure that the final linking will use <CODE>@INTLLIBS@</CODE> as
	608	a library. An easy way to achieve this is to manage that it gets into
	609	<CODE>LIBS</CODE>, like this:
	610
	611
	612	<PRE>
	613	LIBS = @INTLLIBS@ @LIBS@
	614	</PRE>
	615
	616	In most packages internationalized with GNU <CODE>gettext</CODE>, one will
	617	find a directory <TT>`lib/'</TT> in which a library containing some helper
	618	functions will be build. (You need at least the few functions which the
	619	GNU <CODE>gettext</CODE> Library itself needs.) However some of the functions
	620	in the <TT>`lib/'</TT> also give messages to the user which of course should be
	621	translated, too. Taking care of this it is not enough to place the support
	622	library (say <TT>`libsupport.a'</TT>) just between the <CODE>@INTLLIBS@</CODE>
	623	and <CODE>@LIBS@</CODE> in the above example. Instead one has to write this:
	624
	625
	626	<PRE>
	627	LIBS = ../lib/libsupport.a @INTLLIBS@ ../lib/libsupport.a @LIBS@
	628	</PRE>
	629
	630	<LI>
	631
	632	You should also ensure that directory <TT>`intl/'</TT> will be searched for
	633	C preprocessor include files in all circumstances. So, you have to
	634	manage so both <SAMP>`-I../intl'</SAMP> and <SAMP>`-I$(top_srcdir)/intl'</SAMP> will
	635	be given to the C compiler.
	636
	637	<LI>
	638
	639	Your <SAMP>`dist:'</SAMP> goal has to conform with others. Here is a
	640	reasonable definition for it:
	641
	642
	643	<PRE>
	644	distdir = ../$(PACKAGE)-$(VERSION)/$(subdir)
	645	dist: Makefile $(DISTFILES)
	646	for file in $(DISTFILES); do \
	647	ln $$file $(distdir) 2>/dev/null \|\| cp -p $$file $(distdir); \
	648	done
	649	</PRE>
	650
	651	</OL>
	652
	653	<P><HR><P>
	654	<p>Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_9.html">previous</A>, <A HREF="gettext_11.html">next</A>, <A HREF="gettext_12.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
	655	</BODY>
	656	</HTML>