[Pkg-alsa-devel] Bug#647231: libvisual-plugins: FTBFS(!linux): error: possibly undefined macro: AM_PATH_ALSA

peter green plugwash at p10link.net
Tue Jan 24 20:05:04 UTC 2012


Note: I have no particular relationship to this package, i'm just trying to
reduce the number of uninstallable packages in armhf testing.

>configure.ac:210: warning: macro `AM_PATH_ALSA' not found in library
>configure.ac:210: error: possibly undefined macro: AM_PATH_ALSA
>      If this token and others are legitimate, please use m4_pattern_allow.
>      See the Autoconf documentation.
>autoreconf: /usr/bin/autoconf failed with exit status: 1

AM_PATH_ALSA is defined in /usr/share/aclocal/alsa.m4 which is
in package libasound2-dev which only exists on linux. 

Previously this was not an issue because configure was not rebuilt as part of
the build, however in his QA upload Steve Langasek changed the package build to
rebuild configure and hence made it FTBFS on non-linux architectures.

Having throught about this I see several possible soloutions

1: go back to including configure in the packaging rather than building it at
   package build time.
2: move alsa.m4 to a package that exists on all architectures
3: include a copy of alsa.m4 in the libvisual-plugins source
4: include a dummy definition of AM_PATH_ALSA that does nothing in 
   the libvisual-plugins source and only use it on architectures other
   than linux.

Option 1 is probablly the simplest fix but shipping generated code rather than 
doing the generation at build time seems like a step backwards to me.

Option 2 seems good in theory (after all autoconf is mean to generate configure
scripts that run on platforms other than the ones they were generated on so having
AM_PATH_ALSA available on architecture without alsa isn't too unreasonable IMO) 
but the question would be where to move it to and how much disruption would said
move cause...

Option 3 is code duplication that is generally frowned upon

Option 4 seems like the best option if the asla guys don't want to provide 
alsa.m4 on non-linux architectures.

I am CCing Steve (as the last person to touch the package and the one who
introduced the FTBFS) and the ALSA maintainers list to get their opinions on this.








More information about the Pkg-alsa-devel mailing list