All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Seidel <jensseidel@users.sf.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: autopoint || touch config.rpath (was: [PATCH v3] enna:	Move to own recipe folder and update to new Enna hg repository.)
Date: Sat, 3 Apr 2010 15:51:06 +0200	[thread overview]
Message-ID: <20100403135105.GA6475@merkur.sol.de> (raw)
In-Reply-To: <1270293620.3692.33.camel@mattotaupa>

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@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



  reply	other threads:[~2010-04-03 14:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-28 17:18 [PATCH] enna: Move to own recipe folder and update to enna hg Paul Menzel
2010-03-30 13:20 ` [PATCH v2] " Paul Menzel
2010-04-02 15:59   ` [PATCH v3] enna: Move to own recipe folder and update to new Enna hg repository Paul Menzel
2010-04-02 18:28     ` Khem Raj
2010-04-02 19:44       ` Paul Menzel
2010-04-03 11:20         ` autopoint || touch config.rpath (was: [PATCH v3] enna: Move to own recipe folder and update to new Enna hg repository.) Paul Menzel
2010-04-03 13:51           ` Jens Seidel [this message]
2010-04-03 14:43             ` autopoint || touch config.rpath Paul Menzel
2010-04-07 15:44               ` Jens Seidel
2010-04-08  8:01                 ` Richard Purdie
2010-04-02 21:18       ` [PATCH v3] enna: Move to own recipe folder and update to new Enna hg repository Martin Jansa
2010-04-02 22:56         ` Setting `PV` in recipes using SCM repositories (was: [PATCH v3] enna: Move to own recipe folder and update to new Enna hg repository.) Paul Menzel
2010-04-04  8:43           ` Setting `PV` in recipes using SCM repositories Marco Cavallini
2010-04-03 11:03         ` [PATCH v4] enna: Move to own recipe folder and update to new Enna hg repository Paul Menzel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100403135105.GA6475@merkur.sol.de \
    --to=jensseidel@users.sf.net \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.