[oe] autopoint || touch config.rpath (was: [PATCH v3] enna: Move to own recipe folder and update to new Enna hg repository.)

Jens Seidel jensseidel at users.sf.net
Sat Apr 3 13:51:06 UTC 2010


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.

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.

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?

Jens




More information about the Openembedded-devel mailing list