Bug#749649: aclocal: couldn't open directory `m4': No such file or directory

[Sebastian Ramacher]

Control: retitle -1 libva: autoreconf fails with automake < 1.3.2

On 2014-05-28 16:07:53, Nestor A Diaz wrote:
> Source: libva
> Version: 1.3.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> I am compiling libva from jessie, and it throws the above error.
> I just have to create the m4 directory by hand.
> So I guess in order to automate the process you should create the directory in
> the rules files
> 
> # ./debian/rules binary
> dh binary --parallel --with autoreconf
>    dh_testdir -O--parallel
>    dh_autoreconf -O--parallel
> aclocal: couldn't open directory 'm4': No such file or directory
> autoreconf: aclocal failed with exit status: 1
> dh_autoreconf: autoreconf -f -i returned exit code 1
> make: *** [binary] Error 2

I think this is related to the following two changes in automake 1.3.2:

2013-02-21  Pavel Raiskup  <praiskup at redhat.com>

        aclocal: fix for more-than-once specified directories

        Related to automake bug#13514.

        Do not consider directories for extra m4 files multiple times in
        'aclocal'.  Doing so caused problems on older packages that specify

            configure.ac:  AC_CONFIG_MACRO_DIRS([m4])
            Makefile.am:   ACLOCAL_AMFLAGS = -I m4

        if the 'm4' directory does not exist when aclocal is called the first
        time by autoreconf.

        See:
        <http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html>


2013-02-20  Pavel Raiskup  <praiskup at redhat.com>

        aclocal: just warn if the primary local m4 dir doesn't exist (don't error)

        Related to automake bug#13514.

        Every package which does not need to have the local m4 macro
        directory pre-existing in the version control system (because
        e.g., it does not have nor need any private m4 macros) would
        fail during the "autoreconf -vfi" phase if AC_CONFIG_MACRO_DIRS([m4])
        is specified in configure.ac (it could be to instruct tools like
        'autopoint' and 'libtoolize' to use 'm4' as the local directory
        where to install definitions of their m4 macros, and to instruct
        aclocal to look into it).  The failure would go like this:

          autoreconf: Entering directory `.'
          autoreconf: running: aclocal --force
          aclocal: error: couldn't open directory 'm4': No such file or directory
          autoreconf: aclocal failed with exit status: 1

        The problem is that when 'aclocal' is run for the first time during
        'autoreconf', the directory 'm4' does not exist yet.  It will be
        created by e.g., 'libtoolize' or 'autopoint' later on.  During the
        second 'aclocal' run, the 'm4' directory exists and aclocal does not
        complain.

        To work around this issue, we degrade the error to a simple warning.
        The warning is still quite useful when aclocal is run by hand - so
        we are not removing completely.

libva's configure.ac contains AC_CONFIG_MACRO_DIRS([m4]) and Makefile.am
has ACLOCAL_AMFLAGS = -I m4. Moreover, the m4 folder does not exist and
is populated by libtoolize after the first aclocal run.

I'll add the necessary automake requirments to Build-Depends for now.
Creating m4 is a workaround, but I'd prefer something that can be
forwarded upstream (if possible).

Cheers
-- 
Sebastian Ramacher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20140529/db43ee0a/attachment.sig>