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 ]
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.
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
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).
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
