Bug 260023 – autotools.eclass don't catch not existing -I includes into parsed ACLOCAL_AMFLAGS

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Petr Polezhaev 2009-02-23 15:53:37 UTC]

Bug could be caused by broken Makefile.*, which specifies ACLOCAL_AMFLAGS with -I <dir>, when <dir> doesn't exists. eaclocal will parse Makefile, and supply whole variable as arguments to aclocal, which will surely fail.

Live ebuilds are most vunerable, because build-system can't be fixed by a patch.
Futhermore, somethimes include dir (i.e. m4) need to be included, but filled by elibtolize _after_ aclocal call. So aclocal called twice, and we need filter that dir out at first time, and include at second time.

Reproducible: Always

Steps to Reproduce:
# svn co https://svn.niifaq.ru/enlightenment/
# ebuild media-libs/etch/etch-9999.ebuild clean unpack

Actual Results:  
 * Running eautoreconf in '/var/tmp/portage/media-libs/etch-9999/work/etch' ...
 * Running aclocal -I m4 ...                                              [ !! ]

 * Failed Running aclocal !

log: aclocal-1.10: couldn't open directory `m4': No such file or directory

Expected Results:  
 * Running eautoreconf in '/var/tmp/portage/media-libs/etch-9999/work/etch' ...
 * eaclocal: include of non existing 'm4' ignored
 * Running aclocal ...                                                    [ ok ]
 * Running libtoolize --copy --force --install --automake ...             [ ok ]
 * Running aclocal -I m4 ...                                              [ ok ]
 * Running autoconf ...                                                   [ ok ]

[Comment 1 Petr Polezhaev 2009-02-23 15:57:19 UTC]

Created attachment 182908 [details, diff]
autotools.eclass.diff

This is proposed fix - a complex aclocal command line parsing system. As side-effect it also filters duplicated options (it differs options with different arguments) and may be configured for any futher checks on options.

[Comment 2 SpanKY 2009-02-25 01:36:30 UTC]

fix the packages

in the case of enlightenment, you can tell me the broken packages and i'll fix them upstream

in case of other ones, just run `mkdir` before running the autotools to workaround the issue

[Comment 3 Petr Polezhaev 2009-02-25 22:16:29 UTC]

As you maybe already noticed, that was PROTO/etch

mkdir will not be helpfull - it must be done by eclass, which specifies unpack function, so eclass, if it is not an autotools.eclass, must parse Makefile.* again itself to run mkdir - not a very good idea.

Upstreaming such bugs is a good idea, but has too big latency, so, IMHO, it must be done automatically (and it would be done automatically, question is just where it would be done).

[Comment 4 SpanKY 2009-02-26 04:26:06 UTC]

ebuilds can always override src_unpack before calling eclasses

if autotools.eclass ignores issues, they wont get fixed

ive committed m4 dirs to upstream epx and etch dirs

yes, getting things fixed upstream has latency associated with it, but if that's too high, you can workaround it in the ebuild with mkdir as i said