Re: make distcheck fails for non-GNU packages using libtool, gettext, automake, and address@hidden

[Bruno Haible]

Andrew Suffield writes:
> This little clusterfuck has taken *hours* to track down. It only
> occurs in the precise scenario listed in the subject - a non-GNU
> package that uses all three, and that generates an address@hidden po file (or
> address@hidden).
> 
> [I'm fairly sure this is belongs to either libtool or gettext (you
> have to read all the way to the bottom to find where libtool comes
> in). Sending it to bug-automake as an FYI rather than a bug]
> 
> The basic symptom is that distcheck fails in po/, while trying to
> update the address@hidden,}quot.po files, because automake has arranged
> things so that it cannot write to the source directory, and the
> Makefile.in.in from gettext wants to update the po files in the source
> directory.
> 
> [
> Background:
> Automake's distcheck magic lays things out like this:
> Source package is unpacked into $package-$version/
> The package is configured and built in $package-$version/=build/
> ]
> 
> Normally, po/Makefile will not update the po files unless they have
> changed from the source directory. Further investigation revealed that
> the address@hidden file in the source directory had comments like:
> # English translations for GNU foo package.
> While the one in =build/po had this:
> # English translations for foo package.
> 
> This comes from msginit, which fills in the package name
> automatically. The name is acquired by
> /usr/lib/gettext/project-id. project-id determines whether or not a
> package is a GNU package by grepping the directory that contains
> 'configure' for files with the string "GNU $package" in them.
> 
> Libtool's autoconf macros insert this comment into the libtool script:
> # Generated automatically by  (GNU $package $version)
> 
> This causes the GNU detection in project-id to misfire, so the po
> files get incorrect headers (it is likely that other projects have
> acquired incorrect headers in their po files from this).
> 
> (Incidentally, that should have said "Generated automatically by
> configure"; something else is wrong with libtool)
> 
> When distcheck is running, libtool goes into =build/ instead of the
> source directory, so project-id never sees it, so when msginit
> regenerates address@hidden in =build/po, it no longer thinks it is a GNU
> project, so the files differ and the build fails.
> 
> Phew.

Thanks for the detailed analysis. I believe that it takes hours to
track this down!

I'll be using the appended patch in gettext-0.11.6.

> Libtool probably shouldn't be suggesting that all the world is a GNU
> project

Right.

> and gettext probably shouldn't be using a mechanism quite so
> unreliable to figure it out

I didn't find anything more reliable. Certainly the libtool heuristics
produces more false positives.

Bruno

*** gettext/src/project-id      16 Jul 2002 19:06:22 -0000      1.4
--- gettext/src/project-id      14 Oct 2002 13:14:05 -0000
***************
*** 28,34 ****
          ;;
      esac
      if test -n "$package"; then
!       is_gnu=`LC_ALL=C grep "GNU $package" * 2>/dev/null`
        if test -n "$is_gnu"; then
          package="GNU $package"
        fi
--- 28,34 ----
          ;;
      esac
      if test -n "$package"; then
!       is_gnu=`LC_ALL=C grep "GNU $package" * 2>/dev/null | grep -v 
'^libtool:'`
        if test -n "$is_gnu"; then
          package="GNU $package"
        fi