[oe] autopoint || touch config.rpath

[Paul Menzel]

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 <paulepanter at users.sourceforge.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20100403/d5a7ec50/attachment-0002.sig>