Re: Bug#378239: $(MKINSTALLDIRS) is set to non-existent file $(top_builddir)/./mkinstalldirs when used with automake 1.9 (fwd)

[Daniel Leidert]

Am Montag, den 17.07.2006, 14:59 +0200 schrieb Bruno Haible: 
> Hi Daniel and Santiago,
> 
> This is not a bug in GNU gettext.
> 
> Daniel Leidert wrote:
> > Package: gettext
> > Version: 0.14.6-1
> > Severity: important
> > 
> > The following situation: A source with several po-subdirs in the form of
> > $(top_srcdir)/src/plugin_$plugin/po
> 
> GNU gettext does support multiple PO directories under a single
> configure.ac.

I know.

> > (Makefile.in.in and other gettext files 
> > there are freshly copied from /usr/share/gettext/po)
> 
> That's not the recommended way to install the files. You have the
> 'gettextize' and 'autopoint' programs. Choose among them depending
> on whether you are upgrading to a new gettext version (then use
> gettextize) or retrieving redundant files (then use autopoint).

Both, gettextize and autopoint are _NOT_ able to prepare po-directories
other than $(top_srcdir)/po. So what you suggest is impossible. I wanted
to add it to the wishlist, when I have time.

> > The configure.ac file contains the following relevant macros:
> > 
> > ALL_LINGUAS="da de es fi fr it ja no pl pt pt_BR ru sr sv tr zh_CN zh_TW"
> > AC_SUBST(ALL_LINGUAS)
> 
> For several years already, this syntax in configure.ac is not documented
> any more. Use po/LINGUAS files instead (one such file per PO directory).

This is not for gettext. This is for intltool, which does the i18n-work
in $(top_srcdir)/po, where I need it. And it has nothing to do with the
described problem.

> > GETTEXT_PACKAGE=AC_PACKAGE_NAME
> > AC_SUBST(GETTEXT_PACKAGE)
> > AM_GLIB_GNU_GETTEXT
> 
> AM_GLIB_GNU_GETTEXT is not part of GNU gettext.

Right. This has also nothing to do with the described problem.

> Complain to whomever
> maintains (or does not maintain) that macro.

AM_GLIB_GNU_GETTEXT does _NOT_ prepare the Makefiles in src/plugin_*/po!
This is done via AM_PO_SUBDIRS (which I was told to use from you, IIRC),
which calls AM_MKINSTALLDIRS, which puts the 

MKINSTALLDIRS = $(top_builddir)/./mkinstalldirs
mkinstalldirs = $(SHELL) $(MKINSTALLDIRS)

stuff into the final src/*/po/Makefile. So I don't have to report this
issue to the glib maintainers, because AM_PO_SUBDIRS (the one forgot to
cite) is the macro, which is involved in this bug! The
AM_GLIB_GNU_GETTEXT macro probably shows the same bug, when it is used
to prepare the $(top_srcdir)/po/Makefile. But it cannot be used to
prepare my src/*/po/Makefile files.

> Or use AM_GNU_GETTEXT.

This doesn't solve anything. This shows completely the same bug, except
that I can probably remove the call of the AM_PO_SUBDIRS macro from
configure.ac. Just to show you the result, I've replaced
AM_GLIB_GNU_GETTEXT with AM_GNU_GETTEXT([external]) in configure.ac.
This is the result (exactly the same bug):

[..]
Making install in plugin_about
make[3]: Entering directory 
`/home/dl/packages/workspace/bluefish-unstable-cvs/bluefish-unstable-1.1/_build/src/plugin_about'
Making install in po
make[4]: Entering directory 
`/home/dl/packages/workspace/bluefish-unstable-cvs/bluefish-unstable-1.1/_build/src/plugin_about/po'
/bin/sh ../../../../mkinstalldirs 
/home/dl/packages/workspace/bluefish-unstable-cvs/bluefish-unstable-1.1/_inst/share
/bin/sh: ../../../../mkinstalldirs: Datei oder Verzeichnis nicht gefunden
make[4]: *** [install-data-yes] Fehler 127
make[4]: Leaving directory 
`/home/dl/packages/workspace/bluefish-unstable-cvs/bluefish-unstable-1.1/_build/src/plugin_about/po'
make[3]: *** [install-recursive] Fehler 1
make[3]: Leaving directory 
`/home/dl/packages/workspace/bluefish-unstable-cvs/bluefish-unstable-1.1/_build/src/plugin_about'
make[2]: *** [install-recursive] Fehler 1
make[2]: Leaving directory 
`/home/dl/packages/workspace/bluefish-unstable-cvs/bluefish-unstable-1.1/_build/src'
make[1]: *** [install-recursive] Fehler 1
make[1]: Leaving directory 
`/home/dl/packages/workspace/bluefish-unstable-cvs/bluefish-unstable-1.1/_build'
make: *** [distcheck] Fehler 2

This is now the second time I report some weired problem to you. And
it's the second time, that you ignore what I write and tell me things,
which are completely useless all already examined. This is really
getting disappointing.

Daniel