Am Samstag, den 03.04.2010, 15:51 +0200 schrieb Jens Seidel: > On Sat, Apr 03, 2010 at 01:20:20PM +0200, Paul Menzel wrote: > > Am Freitag, den 02.04.2010, 21:44 +0200 schrieb Paul Menzel: > > > Am Freitag, den 02.04.2010, 11:28 -0700 schrieb Khem Raj: > > > > On Fri, Apr 2, 2010 at 8:59 AM, Paul Menzel > > > > <[email protected]> wrote: > > > > > +do_configure_prepend() { > > > > > + autopoint || touch config.rpath > > > > > +} > > > > > > > > empty config.rpath would build it wrongly isnt it. Probably this > > > > should be removed > > Right. > > > > That is the work around Koen suggested [1]. Koen, can you comment > > > please. > > > > Is > > > > do_configure_prepend() { > > autopoint || automake --add-missing > > } > > > > a viable solution [2]? > > No, it isn't. I really wonder about all these guesses. I agree that the > autotools stuff is not very easy to understand but one should only provide > patches if one knows it.
You are right. Great to have an expert joining the discussion.
> Let me short summarize:
>
> automake is a tool to generate Makefile templates (called Makefile.in) from
> Makefile.am files. Normally a tgz ball ships already these generated files
> (that's dictated by GNU). Nevertheless these files are often not committed
> into version control systems and a script autogen.sh or better autoreconf is
> used to generate Makefile.in by calling automake. But autoreconf calls even
> more: e.g. autoconf (which generated configure) and now also autopoint.
> autopoint generated the gettext infrastructure (the translation system to
> support foreign languages) by copying all non config dependent gettext files
> (such as Makefile.in.in, some scripts, ...) into po and m4 macros. That's
> also a good thing as this avoids committing generated files.
Thank you for this great summary. I am still clueless about
`config.rpath` though.
> But why do you want to call either autopoint or automake? The belong
> together and autoreconf should care about it. If this doesn' work it could
> be a bug in the package.
>
> If you send me the project source and the command which fails (without
> bitbake stuff as I never used it up to now) together with the
> autoconf/automake versions I can try to inspect it. Since the error seems to
> happen in configure or even before there should be no difficult relationship
> to
> bitbake and recipes, right?
Correct. Though as far as I understood it using `inherit autotools` OE
is using its own commands to set up the environment using
`autotools.bbclass` and there you will find the following line [2]
causing problems [3].
EXTRA_AUTORECONF = "--exclude=autopoint"
Nobody knows why this was added in the first place, but if you try to
configure Enna [4] for example it will fail as I reported [5]. Other
packages seem to be affected too.
The argument is called in this line [6].
oenote Executing autoreconf --verbose --install --force ${EXTRA_AUTORECONF}
$acpaths
autoreconf -Wcross --verbose --install --force ${EXTRA_AUTORECONF} $acpaths
|| oefatal "autoreconf execution failed."
I cannot reproduce this using the provided files by Enna in my local
environment.
Thanks,
Paul
[1]
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/classes/autotools.bbclass
[2]
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/classes/autotools.bbclass#n38
[3]
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-March/018818.html
[4] http://enna.geexbox.org/
[5]
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-March/018796.html
[6]
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/classes/autotools.bbclass#n136
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
