Bug 3796

Summary:	aclocal fails with 'cannot open ...'
Product:	Sisyphus	Reporter:	Mikhail Zabaluev <mhz>
Component:	automake_1.8	Assignee:	Dmitry V. Levin <ldv>
Status:	CLOSED NOTABUG	QA Contact:	qa-sisyphus
Severity:	blocker
Priority:	P1
Version:	unstable
Hardware:	all
OS:	Linux

Description Mikhail Zabaluev 2004-03-06 00:27:01 MSK

If aclocal from automake_1.8 is invoked in a package directory, it fails with an
error reporting that it cannot open a certain .m4 file required by the package's
autotools macro files. Weirdest of all is that the file apparently has been
found first by a macro definition contained within it.
Any aclocal from earlier major versions of automake does not report such an error.

Steps to Reproduce:
1. Make sure automake_1.8 is installed.
2. Unpack opencdk-0.5.3 source archive from the opencdk source package.
3. Set environment variable AUTOMAKE_VERSION=1.8
4. Change to the source directory opencdk-0.5.3 and run aclocal
Actual Results:  
aclocal-1.8: cannot open libgcrypt.m4: No such file or directory

Comment 1 Dmitry V. Levin 2004-03-06 02:47:29 MSK

Well, all previous automake versions ignored this m4_include expression completely, 
you can see this by just renaming libgcrypt.m4 to foobar.m4. 
 
Since m4_include doesn't use dirlist (according to documentation, it just opens the file given as 
argument), I see no error in aclocal behaviour. 
 
In opencdk package, you should remove both aclocal.m4 and acinclude.m4 files. 
Automake should find all necessary macros using its dependency tracker logic.