Bug#373643: Unsupported or non-substituted DATADIRNAME variable in Makefile.in.in template
On Sun, Oct 22, 2006, Jurij Smakov wrote: I've just read through the bug trail and I just don't understand the issue. DATADIRNAME variable is not substituted by configure, that's clear. Can someone tell me what the correct behaviour is, namely what value one would expect this variable to get? Once that's established, it would be trivial to patch intltool's Makefile.in.in just to set it to whatever we want (I hope that it's some function of variables already substituted by configure). The issue is that the intltool macro relies (almost certainly) on AM_GLIB_GNU_GETTEXT being called before it to define DATADIRNAME. DATADIRNAME in AM_GLIB_GNU_GETTEXT is computed slightly differently under Solaris than other OSes. The intltool macro should never have relied on glib-gettext; glib-gettext is known to be broken and has its own flaws; see for example: http://bugzilla.gnome.org/show_bug.cgi?id=343825 People who are interested in fixing this bug should take into consideration that: 1) both Makefile.in.in and intltool.m4 need each other 2) glib-gettext is not an acceptable dependency 3) the m4 macro will be shipped on other OSes (via aclocal) and should behave as upstream intended -- Loïc Minier [EMAIL PROTECTED]
Bug#373643: Unsupported or non-substituted DATADIRNAME variable in Makefile.in.in template
Hi, I've just read through the bug trail and I just don't understand the issue. DATADIRNAME variable is not substituted by configure, that's clear. Can someone tell me what the correct behaviour is, namely what value one would expect this variable to get? Once that's established, it would be trivial to patch intltool's Makefile.in.in just to set it to whatever we want (I hope that it's some function of variables already substituted by configure). Best regards, -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373643: Unsupported or non-substituted DATADIRNAME variable in Makefile.in.in template
Hi, On Wed, Jun 14, 2006, Daniel Leidert wrote: No. It was a run from a clean CVS-copy running autogen.sh, which runs intltoolize (the CVS-copy itself does not contain this file, so it is freshly created from the file /usr/share/intltool/Makefile.in.in). I use automake 1.9 and the latest autoconf package. Ok, could you try calling GLIB_WITH_NLS in configure.ac before intltool? Could you provide the necessary files to reproduce your problem? (perhaps the upstream CVS location if it's public) It is also a bit surprising to me, that $itlocaledir does not make use of $datadir. Instead it uses this (IMHO) crappy (sorry) expression '$(prefix)/$(DATADIRNAME)/locale' Is there a special reason for this? One thing at a time. :) (You can file another bug report on that particular problem.) Further the --localedir options was introduced recently. IMHO the used expression will ignore this option. So IMHO, a check for configure.ac should be added to test on $localedir and the current solution (without the bug) should be the fallback (IMHO this is a suggestion for upstream). I don't understand this last part. Bye, -- Loïc Minier [EMAIL PROTECTED]
Bug#373643: Unsupported or non-substituted DATADIRNAME variable in Makefile.in.in template
Am Donnerstag, den 15.06.2006, 09:46 +0200 schrieb Loïc Minier:
Hi,
On Wed, Jun 14, 2006, Daniel Leidert wrote:
No. It was a run from a clean CVS-copy running autogen.sh, which runs
intltoolize (the CVS-copy itself does not contain this file, so it is
freshly created from the file /usr/share/intltool/Makefile.in.in). I use
automake 1.9 and the latest autoconf package.
Ok, could you try calling GLIB_WITH_NLS in configure.ac before
intltool? Could you provide the necessary files to reproduce your
problem? (perhaps the upstream CVS location if it's public)
I don't need the GLIB macros. I just ran AM_PO_SUBDIRS (or in the past,
I ran AM_GNU_GETTEXT, which is a bit overkill - but in bug #365727 I was
now told to use AM_PO_SUBDIRS for my purpose - atm I removed them
completely, because IT_PROG_INTLTOOL seems enough - except of the
DATADIRNAME variable issue). The necessity of the GLIB_* macros would be
some kind of overkill and a crap dependency, because the project uses
intltool for XML file internationalization and doesn't need any
libglib2.0-dev dependency. The code is available at
http://sourceforge.net/projects/chemical-mime/ CVS (the upload was done
some minutes ago, so anonymous CVS may lack the latest changes, I put
some archives to http://debian.wgdd.de/temp/
(chemical-mime-data-0.1.94.tar.{gz,bz2}).
http://chemical-mime.cvs.sourceforge.net/chemical-mime/chemical-mime-data/
run ./autogen ./configure disable-update-database
then run make and try an installation with DESTDIR=whateveryouwant to
reproduce the issue. DATADIRNAME has no value.
It is also a bit
surprising to me, that $itlocaledir does not make use of $datadir.
Instead it uses this (IMHO) crappy (sorry) expression
'$(prefix)/$(DATADIRNAME)/locale' Is there a special reason for this?
One thing at a time. :)
Well, the expression here uses the problematic DATADIRNAME variable,
which is not supported/not substituted. So I think, this is some related
information. Changing $itlocaledir to '$itlocaledir=$datadir/locale'
changes the problematic code to a working one.
(You can file another bug report on that particular problem.)
Further the --localedir options was introduced recently. IMHO the used
expression will ignore this option. So IMHO, a check for configure.ac
should be added to test on $localedir and the current solution (without
the bug) should be the fallback (IMHO this is a suggestion for
upstream).
I don't understand this last part.
The latest autoconf package adds support for a --localedir configure
option. So it is possible to define the location for the locales as
$localedir. This adds the possibility to add a check to configure.ac,
which tests, if $localedir is empty. If it is, the fallback could be
localedir=$datadir/locale or intltools (crappy) expression: localedir=
$(prefix)/$(DATADIRNAME)/locale. But this is really not directly related
to the issue I reported and something, I should tell upstream :)
Regards, Daniel
Bug#373643: Unsupported or non-substituted DATADIRNAME variable in Makefile.in.in template
Package: intltool Version: 0.35.0-1 Severity: grave -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The DATADIRNAME variable is not substituted on my system (a recent Debian Sid). Therefor one of my packages says: Making install in po make[1]: Entering directory `/home/dl/packages/cvs/chemical-mime-data/po' /home/dl/packages/cvs/chemical-mime-data/install-sh -d /home/dl/packages/cvs/chemical-mime-data/install/usr/local/@DATADIRNAME@/locale if test -n ; then \ [..] fi installing de.gmo as /home/dl/packages/cvs/chemical-mime-data/install/usr/local/@DATADIRNAME@/locale/de/LC_MESSAGES/chemical-mime-data.mo installing fr.gmo as /home/dl/packages/cvs/chemical-mime-data/install/usr/local/@DATADIRNAME@/locale/fr/LC_MESSAGES/chemical-mime-data.mo And then $ ls install/usr/local/ @DATADIRNAME@ share and the catalogs are under @DATADIRNAME@/, which completely breaks the installation of catalogs using intltool (therefor I initially set this report to grave, because it makes intltool completely useless). Regards, Daniel - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.08060320 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages intltool depends on: ii automake1.7 [automaken] 1.7.9-7A tool for generating GNU Standard ii automake1.9 [automaken] 1.9.6-4A tool for generating GNU Standard ii file 4.17-1 Determines file type using magic ii gettext 0.14.5-4 GNU Internationalization utilities ii libxml-parser-perl2.34-4 Perl module for parsing XML files ii patch 2.5.9-4Apply a diff file to an original ii perl 5.8.8-6Larry Wall's Practical Extraction intltool recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEkF3mdg0kG0+YFBERAvVaAJ9IiBhTkHhN8SBqhn2AVla+yNlLXACePsNs qufk8fS4qszD27vwnOHGEM4= =sCi5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373643: Unsupported or non-substituted DATADIRNAME variable in Makefile.in.in template
Hi, On Wed, Jun 14, 2006, Daniel Leidert wrote: The DATADIRNAME variable is not substituted on my system (a recent Debian Sid). Therefor one of my packages says: Does it work again if you re-intltoolize? (intltoolize --force --copy aclocal-VERS -I dir autoconf rm -rf automa4te.cache) Bye, -- Loïc Minier [EMAIL PROTECTED]
Bug#373643: Unsupported or non-substituted DATADIRNAME variable in Makefile.in.in template
Am Mittwoch, den 14.06.2006, 22:35 +0200 schrieb Loïc Minier: Hi, On Wed, Jun 14, 2006, Daniel Leidert wrote: The DATADIRNAME variable is not substituted on my system (a recent Debian Sid). Therefor one of my packages says: Does it work again if you re-intltoolize? (intltoolize --force --copy aclocal-VERS -I dir autoconf rm -rf automa4te.cache) No. It was a run from a clean CVS-copy running autogen.sh, which runs intltoolize (the CVS-copy itself does not contain this file, so it is freshly created from the file /usr/share/intltool/Makefile.in.in). I use automake 1.9 and the latest autoconf package. It is also a bit surprising to me, that $itlocaledir does not make use of $datadir. Instead it uses this (IMHO) crappy (sorry) expression '$(prefix)/$(DATADIRNAME)/locale' Is there a special reason for this? Further the --localedir options was introduced recently. IMHO the used expression will ignore this option. So IMHO, a check for configure.ac should be added to test on $localedir and the current solution (without the bug) should be the fallback (IMHO this is a suggestion for upstream). Regards, Daniel
