From: James A. T. <tr...@de...> - 2003-05-17 05:31:01
|
For building a Debian package, in previous versions of gramps I used make install prefix=`pwd`/debian/tmp/usr This almost works with 0.9.1 except for the Makefile.am in the main directory which contains: # Build/rebuild the catalog install-data-hook: $(mkinstalldirs) $(DESTDIR)$(localstatedir)/log which causes the failure: /bin/sh ./mkinstalldirs /var/lib/log mkdir -p -- /var/lib/log mkdir: cannot create directory `/var/lib/log': Permission denied Is this a problem with the Makefiles or do you suggest a different line when you want the installation to be in a subdirectory? -- James (Jay) Treacy tr...@de... |
From: Don A. <dal...@us...> - 2003-05-17 16:02:01
|
I'm not sure on this one. Don Peterson probably knows better than anyone else. My guess is that it has to do with scrollkeeper/documentation registration. I can't think of any other reason why there would need to be access to /var/lib/log. Don On Fri, 2003-05-16 at 23:29, James A. Treacy wrote: > For building a Debian package, in previous versions of gramps I used > make install prefix=`pwd`/debian/tmp/usr > This almost works with 0.9.1 except for the Makefile.am > in the main directory which contains: > > # Build/rebuild the catalog > install-data-hook: > $(mkinstalldirs) $(DESTDIR)$(localstatedir)/log > > which causes the failure: > > /bin/sh ./mkinstalldirs /var/lib/log > mkdir -p -- /var/lib/log > mkdir: cannot create directory `/var/lib/log': Permission denied > > Is this a problem with the Makefiles or do you suggest a different line > when you want the installation to be in a subdirectory? -- Don Allingham <dal...@us...> GRAMPS - Open Source Genealogy |
From: Alex R. <sh...@al...> - 2003-05-17 16:28:04
|
Actually, we can drop /var/lib/log altogether as nothing ever gets recorded there. It was meant, I guess, for scrollkeeper logfiles, but I numerously ran scrollkeeper stuff with and without errors and nothing is created there. A thing to worry about in debian packages is that registering docs with the scrollkeeper will have to be done on postinst. Similarly, unregistering docs will have to be done on postrm. Something like this: gramps.postinst: # Register with the scrollkeeper if which scrollkeeper-update>/dev/null 2>&1; then scrollkeeper-update -q -o /usr/share/omf/gramps fi gramps.postrm: # Unregister with the scrollkeeper if which scrollkeeper-update>/dev/null 2>&1; then scrollkeeper-update -q fi That way we don't have an undeclared dependency on the scrollkeeper (bug 185875 in BTS), as it's only run if it exists. Of course, otherwise the docs are pretty much useless in their XML format :-) So, maybe adding Recommends: scrollkeeper is worth doing. Alex On Sat, May 17, 2003 at 09:59:18AM -0600, Don Allingham wrote: > I'm not sure on this one. Don Peterson probably knows better than anyone > else. My guess is that it has to do with scrollkeeper/documentation > registration. I can't think of any other reason why there would need to > be access to /var/lib/log. > > On Fri, 2003-05-16 at 23:29, James A. Treacy wrote: > > For building a Debian package, in previous versions of gramps I used > > make install prefix=`pwd`/debian/tmp/usr > > This almost works with 0.9.1 except for the Makefile.am > > in the main directory which contains: > > > > # Build/rebuild the catalog > > install-data-hook: > > $(mkinstalldirs) $(DESTDIR)$(localstatedir)/log > > > > which causes the failure: > > > > /bin/sh ./mkinstalldirs /var/lib/log > > mkdir -p -- /var/lib/log > > mkdir: cannot create directory `/var/lib/log': Permission denied > > > > Is this a problem with the Makefiles or do you suggest a different line > > when you want the installation to be in a subdirectory? -- Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: James A. T. <tr...@de...> - 2003-05-18 05:03:19
|
On Sat, May 17, 2003 at 11:27:02AM -0500, Alex Roitman wrote: > Actually, we can drop /var/lib/log altogether as nothing ever gets > recorded there. It was meant, I guess, for scrollkeeper logfiles, but I > numerously ran scrollkeeper stuff with and without errors and nothing is > created there. Ok. I have disabled the (attempted) creation of this directory for the Debian build. > A thing to worry about in debian packages is that registering docs > with the scrollkeeper will have to be done on postinst. Similarly, > unregistering docs will have to be done on postrm. Something like this: Actually, there are already postinst and postrm files in the package with similar contents. The next upload will include a dependency on scrollkeeper. -- James (Jay) Treacy tr...@de... |
From: <dpe...@si...> - 2003-05-19 16:00:56
|
On Sat, 17 May 2003, Alex Roitman had this to say: Hello everyone! I was out of town this weekend so I missed this excitement. Sorry I wasn't able to jump in earlier. Yes, this install-data-hook was initially in place for scrollkeeper maintenence, and was needed at one time---I think for the scrollkeeper 0.2.x series. It was from a boiler-plate HOWTO. I think Alex is right in that we no longer need this hook. (Maybe it was for non-standard install locations? I forget now.) Anyway, the scrollkeeper-update is taken care of either: 1) In the documentation makefiles if installed from source 2) In the %post and %postun sections of .rpm packages Sorry I don't know about debian's heiarchy, but I'm sure James can take care of that. :) I'm betting we can safely remove the install-data-hook line from the Makefile. Does anyone see a problem with that? --------- >Actually, we can drop /var/lib/log altogether as nothing ever gets >recorded there. It was meant, I guess, for scrollkeeper logfiles, but I >numerously ran scrollkeeper stuff with and without errors and nothing is >created there. > >A thing to worry about in debian packages is that registering docs >with the scrollkeeper will have to be done on postinst. Similarly, >unregistering docs will have to be done on postrm. Something like this: > >gramps.postinst: ># Register with the scrollkeeper >if which scrollkeeper-update>/dev/null 2>&1; then > scrollkeeper-update -q -o /usr/share/omf/gramps >fi > >gramps.postrm: ># Unregister with the scrollkeeper >if which scrollkeeper-update>/dev/null 2>&1; then > scrollkeeper-update -q >fi > >That way we don't have an undeclared dependency on the scrollkeeper >(bug 185875 in BTS), as it's only run if it exists. Of course, otherwise >the docs are pretty much useless in their XML format :-) So, maybe >adding Recommends: scrollkeeper is worth doing. > >Alex > >On Sat, May 17, 2003 at 09:59:18AM -0600, Don Allingham wrote: >> I'm not sure on this one. Don Peterson probably knows better than anyone >> else. My guess is that it has to do with scrollkeeper/documentation >> registration. I can't think of any other reason why there would need to >> be access to /var/lib/log. >> >> On Fri, 2003-05-16 at 23:29, James A. Treacy wrote: >> > For building a Debian package, in previous versions of gramps I used >> > make install prefix=`pwd`/debian/tmp/usr >> > This almost works with 0.9.1 except for the Makefile.am >> > in the main directory which contains: >> > >> > # Build/rebuild the catalog >> > install-data-hook: >> > $(mkinstalldirs) $(DESTDIR)$(localstatedir)/log >> > >> > which causes the failure: >> > >> > /bin/sh ./mkinstalldirs /var/lib/log >> > mkdir -p -- /var/lib/log >> > mkdir: cannot create directory `/var/lib/log': Permission denied >> > >> > Is this a problem with the Makefiles or do you suggest a different line >> > when you want the installation to be in a subdirectory? > > ________________________________________________ Donald A. Peterson | dpe...@si... Ph.D. Research Associate | Dept. of Chemistry | PH: (541) 737-7079 Oregon St. University | FAX: (541) 737-0480 ------------------------------------------------ |
From: Alexandre Duret-L. <ad...@us...> - 2003-05-19 19:18:42
|
>>> "Don" == Donald A Peterson <dpe...@si...> writes: [...] Don> I'm betting we can safely remove the install-data-hook line from the Don> Makefile. Does anyone see a problem with that? Not me. However I've a problem with localstatedir being hard-coded in configure. This hinders installations by non-root users. I usually installs gramps in $HOME/usr, and have to use `make -k install' to ignore all the /var/lib errors. To guard yourself from similar issues, I suggest you forget about `make dist' and instead use `make distcheck' to prepare releases. Fixing all the issues caught by `make distcheck' will certainly be a hard time the first time, but it's all for the best. If you upgrade to Automake 1.7.x, distcheck will also make sure you support DESTDIR-installations (DESTDIR support is currently missing in a few places in Gramps). BTW, you might want to use bits of the following patch. It fixes some errors `make distcheck' would have found if scroll-keeper wasn't causing it to abort earlier, as well as a few other unrelated things (let me know if you'd like more explanations). Index: src/Makefile.am =================================================================== RCS file: /cvsroot/gramps/gramps2/src/Makefile.am,v retrieving revision 1.13 diff -u -b -r1.13 Makefile.am --- src/Makefile.am 18 May 2003 22:52:42 -0000 1.13 +++ src/Makefile.am 19 May 2003 18:44:28 -0000 @@ -5,9 +5,9 @@ GVFSINC = @GPREF@ CFLAGS = -fPIC -shared -O @GNOMEINC@ @CFLAGS@ @CPPFLAGS@ -I@includedir@ LDFLAGS = @GNOMELIB@ @LDFLAGS@ -L@libdir@ @LIBS@ -CLEANFILES = ${INTLLIBS} grampslib.so +CLEANFILES = $(INTLLIBS) grampslib.so MOSTLYCLEANFILES = -INTLLIBS= intl22.so +INTLLIBS = intl22.so # What are the PYTHON scripts for this package that need to be handled? # @@ -93,8 +93,6 @@ Witness.py\ WriteXML.py -# Use GNU make's ':=' syntax for nice wildcard use. -# If not using GNU make, then list all files individually GLADEFILES = \ config.glade\ dialog.glade\ @@ -130,14 +128,12 @@ splash.jpg # Other stuff that we need to install -pkgdata_DATA = ${INTLLIBS} ${GLADEFILES} ${GRAPHICS} gramps.desktop grampslib.so +dist_pkgdata_DATA = $(GLADEFILES) $(GRAPHICS) gramps.desktop +nodist_pkgdata_DATA = grampslib.so $(INTLLIBS) -EXTRA_DIST = grampslib.i +EXTRA_DIST = grampslib.i intl.c grampslib_wrap.c -all: ${INTLLIBS} grampslib.so - -DIST_SOURCES = intl.c grampslib_wrap.c -dist_pkgdata_DATA = ${pkgdata_DATA} +all-local: $(INTLLIBS) grampslib.so # These can prbably be done in a better or more elegant/generic way # eventually (libtool?), but this works. @@ -151,18 +147,20 @@ # spirit of keeping each subdirectory as a separate entity unto itself. # But, since the template depends on everything from here, we allow this # one exception. -trans: po/template.po +# Build po/template.po. +.PHONY: trans +trans: ./build_po -check: +check-local: pychecker $(pkgpython_PYTHON) install-data-local: - ${INSTALL} -d ${prefix}/share/pixmaps - ${INSTALL_DATA} gramps.png ${prefix}/share/pixmaps - ${INSTALL} -d ${prefix}/share/gnome/apps/Applications - ${INSTALL_DATA} gramps.desktop ${prefix}/share/gnome/apps/Applications + $(INSTALL) -d $(DESTDIR)$(prefix)/share/pixmaps + $(INSTALL_DATA) $(srcdir)/gramps.png $(DESTDIR)$(prefix)/share/pixmaps + $(INSTALL) -d $(DESTDIR)$(prefix)/share/gnome/apps/Applications + $(INSTALL_DATA) $(srcdir)/gramps.desktop $(DESTDIR)$(prefix)/share/gnome/apps/Applications uninstall-local: - -rm ${prefix}/share/pixmaps/gramps.png - -rm ${prefix}/share/gnome/apps/Applications/gramps.desktop + -rm $(DESTDIR)$(prefix)/share/pixmaps/gramps.png + -rm $(DESTDIR)$(prefix)/share/gnome/apps/Applications/gramps.desktop Index: src/po/Makefile.am =================================================================== RCS file: /cvsroot/gramps/gramps2/src/po/Makefile.am,v retrieving revision 1.3 diff -u -b -r1.3 Makefile.am --- src/po/Makefile.am 10 Apr 2003 03:05:22 -0000 1.3 +++ src/po/Makefile.am 19 May 2003 18:44:28 -0000 @@ -1,23 +1,22 @@ # This is the src/po level Makefile configuration -EXTRA_DIST = ${POFILES} -CLEANFILES = ${MOFILES} +EXTRA_DIST = $(POFILES) template.po +CLEANFILES = $(MOFILES) -all: ${MOFILES} +all-local: $(MOFILES) install-data-local: - for lang in ${LANGUAGES}; do \ - ${INSTALL} -d ${prefix}/share/locale/$$lang; \ - ${INSTALL} -d ${prefix}/share/locale/$$lang/LC_MESSAGES; \ - ${INSTALL_DATA} $$lang.mo ${prefix}/share/locale/$$lang/LC_MESSAGES/${PACKAGE}.mo; \ + for lang in $(LANGUAGES); do \ + $(INSTALL) -d $(DESTDIR)$(prefix)/share/locale/$$lang; \ + $(INSTALL) -d $(DESTDIR)$(prefix)/share/locale/$$lang/LC_MESSAGES; \ + $(INSTALL_DATA) $(srcdir)/$$lang.mo $(DESTDIR)$(prefix)/share/locale/$$lang/LC_MESSAGES/$(PACKAGE).mo; \ done uninstall-local: - for lang in ${LANGUAGES}; do \ - rm -f ${prefix}/share/locale/$$lang/LC_MESSAGES/gramps.mo; \ + for lang in $(LANGUAGES); do \ + rm -f $(DESTDIR)$(prefix)/share/locale/$$lang/LC_MESSAGES/gramps.mo; \ done - SUFFIXES = .po .mo .po.mo: - ${MSGFMT} -v $< -o $@ + $(MSGFMT) -v $< -o $@ -- Alexandre Duret-Lutz |
From: <dpe...@si...> - 2003-05-20 00:00:17
|
On Mon, 19 May 2003, Alexandre Duret-Lutz had this to say: >>>> "Don" == Donald A Peterson <dpe...@si...> writes: > >[...] > > Don> I'm betting we can safely remove the install-data-hook line from the > Don> Makefile. Does anyone see a problem with that? > >Not me. However I've a problem with localstatedir being >hard-coded in configure. This hinders installations by non-root >users. I usually installs gramps in $HOME/usr, and have to >use `make -k install' to ignore all the /var/lib errors. Ok. Let me explain the history of that abomination. :) Originally, I had tried to leave this alone. However, any attempts to install without explicitly setting localstatedir failed miserably. That empirical evidence, together with the mandate from the scrollkeeper documentation that one MUST use --localstatedir=/var/lib, prompted me to do the hardcoding. However, it now seems that scrollkeeper---at least the version with GNOME2 along with the Yelp help browser---behaves nicely. I will remove the localstate hardcode from configure.in, and once again allow users to manually set it via the --localstate switch to the configure script. If anyone notices breakage, let me know and we can regress. >To guard yourself from similar issues, I suggest you forget >about `make dist' and instead use `make distcheck' to prepare >releases. > >Fixing all the issues caught by `make distcheck' will certainly >be a hard time the first time, but it's all for the best. I will look into this. Thanks for the hint. >If you upgrade to Automake 1.7.x, distcheck will also make >sure you support DESTDIR-installations (DESTDIR support >is currently missing in a few places in Gramps). Two things about this: 1) I know you've been an advocate of moving to AM1.7 for a while now. It sounds like it has a lot of goodness to it. However, given that no distribution includes this by default (debian testing, RH RawHide, and PLD are the only dists that I can see which even have it available) I think this may be dangerous. I worry about accidentally using macros or techniques that an average user will not have access to. 2) Could you point out the places we need to make DESTDIR support more uniform? >BTW, you might want to use bits of the following patch. It >fixes some errors `make distcheck' would have found if A couple more things (and a P.S. to follow): 1) For me, 'make distcheck' only gave errors in attempting to run pychecker on the various python modules. 2) I will go ahead and apply this patch and check in the new files. Thanks. 3 (P.S.) What is the difference between ${...} and $(...), and the difference between 'FOO=' and 'FOO = '? In the first case, I used to always use the $(...) form [that's how I learned makefiles] and then saw some projects using the ${...} form for variable expansion. I'm not entirely sure why/how gramps got into a mixed-mode, but we should certainly make it uniform. Why does the () form work better? For the second method, I had always learned/seen the expressions as 'FOO=' [i.e. no space around the "="]; why do you suggest the other? Thanks again for imparting your wisdom upon us. :) -Don ________________________________________________ Donald A. Peterson | dpe...@si... Ph.D. Research Associate | Dept. of Chemistry | PH: (541) 737-7079 Oregon St. University | FAX: (541) 737-0480 ------------------------------------------------ |
From: <dpe...@si...> - 2003-05-20 02:41:11
|
On Mon, 19 May 2003, dpe...@si... had this to say: >On Mon, 19 May 2003, Alexandre Duret-Lutz had this to say: > >>>>> "Don" == Donald A Peterson <dpe...@si...> writes: >> >>[...] >> >> Don> I'm betting we can safely remove the install-data-hook line from the >> Don> Makefile. Does anyone see a problem with that? >> >>Not me. However I've a problem with localstatedir being >>hard-coded in configure. This hinders installations by non-root > >version with GNOME2 along with the Yelp help browser---behaves nicely. I >will remove the localstate hardcode from configure.in, and once again >allow users to manually set it via the --localstate switch to the >configure script. If anyone notices breakage, let me know and we can >regress. Well, this isn't quite right. If you're installing as root, or building an RPM, scrollkeeper (and, it appears, GNOME-compliancy) _demands_ that localstatedir be set to /var/lib. However, without coding anything in, configure assumes localstatedir to be PREFIX/var, and thus will hose your install. This means that now "./configure" no longer does The Right Thing(tm), but rather "./configure --localstatedir=/var/lib" is required for a standard install. How can we compromise? Is there an easy way to set a different default value for --localstatedir w/o hardcoding it so that someone wanting to install in a non-standard place can still issue the --localstatedir option? >>To guard yourself from similar issues, I suggest you forget >>about `make dist' and instead use `make distcheck' to prepare >>releases. >> >>Fixing all the issues caught by `make distcheck' will certainly >>be a hard time the first time, but it's all for the best. I don't think make distcheck works. I will follow up privately. :) Cheers, -Don ________________________________________________ Donald A. Peterson | dpe...@si... Ph.D. Research Associate | Dept. of Chemistry | PH: (541) 737-7079 Oregon St. University | FAX: (541) 737-0480 ------------------------------------------------ |
From: Alexandre Duret-L. <ad...@us...> - 2003-05-20 06:29:31
|
>>> "Don" == Donald A Peterson <dpe...@si...> writes: [...] Don> However, given that no distribution includes [AM1.7] by Don> default (debian testing, RH RawHide, and PLD are the only Don> dists that I can see which even have it available) I think Don> this may be dangerous. I worry about accidentally using Don> macros or techniques that an average user will not have Don> access to. The average Gramps user does not need Automake installed at all. However people hacking Gramps CVS would probably need so. Still, rebuilding all **/Makefile.in with Automake 1.6.x should not be a problem. But it's really not a big deal if you stay with 1.6. My point is just that 1.7's `make distcheck' will catch more errors than 1.6's, not that 1.6 is rotten. Also note that 1.6.x and 1.7.x can be installed side by side. Don> 2) Could you point out the places we need to make DESTDIR Don> support more uniform? Those I noted were fixed in the patch I sent. [...] Don> 1) For me, 'make distcheck' only gave errors in attempting to run Don> pychecker on the various python modules. pychecker is run by `make check', and `make distcheck' ensures you don't make a release for which `make check' fails. If these errors are legitimate, maybe pychecker should not be run by `make check' but some custom target like `make pycheck'. Many administrators run commands similar to ./configure && make && make check && make install and do not install a package that fails `make check'. In my setup the pychecker errors did not causes `make check' failures due to a bug in the Debian wrapper for pychecker (which always exits with $?=0). [...] Don> 3 (P.S.) What is the difference between ${...} and $(...), and the Don> difference between 'FOO=' and 'FOO = '? Purely cosmetics. As you said, the files did not use a uniform convention. Don> In the first case, I used to always use the $(...) form Don> [that's how I learned makefiles] and then saw some Don> projects using the ${...} form for variable expansion. Don> I'm not entirely sure why/how gramps got into a Don> mixed-mode, but we should certainly make it uniform. Why Don> does the () form work better? It does not work better, but it's more common though. Also it makes the difference between make-expanded variables (`$(foo)') and shell-expanded variables in rules (`$${foo}') more obvious to the reader. Don> For the second method, I had always learned/seen the Don> expressions as 'FOO=' [i.e. no space around the "="]; why Don> do you suggest the other? For consistency with all the other assignments in this same file :) While what you say is definitely true for shell scripts, it doesn't matter in Makefiles. Automake itself uses `A = b' everywhere (it tries to follow the GNU Coding Standards in doing so). I'll answer your two other mails tonight. Time to leave. -- Alexandre Duret-Lutz |
From: <dpe...@si...> - 2003-05-21 00:35:10
|
On Mon, 19 May 2003, Alexandre Duret-Lutz had this to say: >>>> "Don" == Donald A Peterson <dpe...@si...> writes: > >[...] > >Fixing all the issues caught by `make distcheck' will certainly >be a hard time the first time, but it's all for the best. Hello Alexandre, Well, you're right. Making 'make distcheck' work certainly has been frusterating---esp. since I really don't know what I'm doing in this matter. :) I am getting closer, I think, but could use some help. >BTW, you might want to use bits of the following patch. It >fixes some errors `make distcheck' would have found if This patch for the src/po/Makefile.am (below) doesn't seem to work. At least not for me. It fails when trying to install the $(srcdir)/$$lang.mo files because they do not exist. Only the $$lang.po files are in $(srcdir). However, should we be including the *.mo files in the distribution? What if the user doesn't want NLS support? I don't know---just asking. In any case, I'd be happy to get some nudging in the right direction. >Index: src/po/Makefile.am >=================================================================== >RCS file: /cvsroot/gramps/gramps2/src/po/Makefile.am,v >retrieving revision 1.3 >diff -u -b -r1.3 Makefile.am >--- src/po/Makefile.am 10 Apr 2003 03:05:22 -0000 1.3 >+++ src/po/Makefile.am 19 May 2003 18:44:28 -0000 >@@ -1,23 +1,22 @@ > # This is the src/po level Makefile configuration >-EXTRA_DIST = ${POFILES} >-CLEANFILES = ${MOFILES} >+EXTRA_DIST = $(POFILES) template.po >+CLEANFILES = $(MOFILES) > >-all: ${MOFILES} >+all-local: $(MOFILES) > > install-data-local: >- for lang in ${LANGUAGES}; do \ >- ${INSTALL} -d ${prefix}/share/locale/$$lang; \ >- ${INSTALL} -d ${prefix}/share/locale/$$lang/LC_MESSAGES; \ >- ${INSTALL_DATA} $$lang.mo ${prefix}/share/locale/$$lang/LC_MESSAGES/${PACKAGE}.mo; \ >+ for lang in $(LANGUAGES); do \ >+ $(INSTALL) -d $(DESTDIR)$(prefix)/share/locale/$$lang; \ >+ $(INSTALL) -d $(DESTDIR)$(prefix)/share/locale/$$lang/LC_MESSAGES; \ >+ $(INSTALL_DATA) $(srcdir)/$$lang.mo $(DESTDIR)$(prefix)/share/locale/$$lang/LC_MESSAGES/$(PACKAGE).mo; \ > done > > uninstall-local: >- for lang in ${LANGUAGES}; do \ >- rm -f ${prefix}/share/locale/$$lang/LC_MESSAGES/gramps.mo; \ >+ for lang in $(LANGUAGES); do \ >+ rm -f $(DESTDIR)$(prefix)/share/locale/$$lang/LC_MESSAGES/gramps.mo; \ > done > >- > SUFFIXES = .po .mo > > .po.mo: >- ${MSGFMT} -v $< -o $@ >+ $(MSGFMT) -v $< -o $@ > > ________________________________________________ Donald A. Peterson | dpe...@si... Ph.D. Research Associate | Dept. of Chemistry | PH: (541) 737-7079 Oregon St. University | FAX: (541) 737-0480 ------------------------------------------------ |
From: Alexandre Duret-L. <ad...@us...> - 2003-05-21 07:48:43
|
>>> "Don" == Donald A Peterson <dpe...@si...> writes: [...] Don> Well, you're right. Making 'make distcheck' work certainly has been Don> frusterating---esp. since I really don't know what I'm doing in this Don> matter. :) I know the feeling. [...] Don> This patch for the src/po/Makefile.am (below) doesn't seem Don> to work. At least not for me. It fails when trying to Don> install the $(srcdir)/$$lang.mo files because they do not Don> exist. Only the $$lang.po files are in $(srcdir). Yep, my bad. Don> However, should we be including the *.mo files in the Don> distribution? That's what gettextized packages do. This way users do not need to have the gettext tools (e.g., msgfmt) installed. Don> What if the user doesn't want NLS support? When you use the gettext infrastructure, the AM_GNU_GETTEXT macros will add a --disable-nls switch to configure. One of the consequence of this switch is to disable the install rules in po/, it also makes all the intl function calls no-ops in the code. I guess you could do something similar in Gramps. (Conditionally defining `_' and siblings in Gramps, using AM_CONDITIONALS to disable the po/ install rules.) Yet that's work. Maybe it's not worth doing unless someone needs it? [...] -- Alexandre Duret-Lutz |