Bruno Haible <[EMAIL PROTECTED]> writes: >> I think I have two general questions here: >> >> 1) Is it guaranteed that replacing the gettext M4 files with those in >> gnulib will work with the gettext version installed? > > Yes. I avoid incompatible changes in the gnulib copies of these files, > except when upgrading to a new gettext release.
That sounds good. Let me clarify, does the gnulib files work with gettext 0.16.1? That's the version included in Debian for i386 right now. >> 2) Is it guaranteed that replacing the gnulib M4 files with those in >> gettext will work with other gnulib macros? > > No. gnulib changes weekly, daily, in so unpredictable ways, that this > cannot be guaranteed. Ok. 1) seems more elegant anyway. >> And of course the final question, what is the recommended way to handle >> the code-overlap between gnulib and gettextize in a project? > > You should take care to run gnulib-tool after autopoint. Problem is I have the gnulib files in git, and most developers aren't expected to run gnulib-tool at all. I could, however, arrange so that the some makefile overwrite the new gettextize files with the copies from gnulib. > It would be good if someone who has time could write some paragraphs about > it in the gnulib documentation... I'll try to do it once I understand the solution slightly better. I think the general recommendation is that users must make sure any files installed by gettextize are overwritten by the gnulib copy. >> Btw, I tried to install gettext 0.17 under /usr/local, but gettextize >> didn't seem to install the *.m4 files from /usr/local anyway, instead I >> got the lib-link file from /usr. > > If you installed gettext with --prefix=/usr/local, and call gettextize from > /usr/local/bin/, it will use the *.m4 files from /usr/local/share/aclocal/. > (Look at the variables 'prefix' and 'datarootdir' in this script.) That wasn't my experience, although I invoked 'autoreconf' and not gettextize directly. Maybe autoreconf do not call gettextize from PATH? /usr/local/bin is before /usr/bin for me. I'll see if I can reproduce this if it would help debugging. /Simon
