All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Liu <ming.liu@windriver.com>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 3/3] gettext: fix implicit build result
Date: Thu, 17 Jul 2014 17:38:53 +0800	[thread overview]
Message-ID: <53C799AD.4070706@windriver.com> (raw)
In-Reply-To: <CAJTo0LaqmvZ7yoXtEOShd0TKNGzTXidoOd_dLhEu=DiCoyvr=Q@mail.gmail.com>

On 07/17/2014 05:21 PM, Burton, Ross wrote:
> On 17 July 2014 08:58, Ming Liu <ming.liu@windriver.com> wrote:
>> Some "once only" variants are being defined instead of standard autoconf
>> macros, for instance, AC_CHECK_HEADERS_ONCE like AC_CHECK_HEADERS. The
>> advantage is that the check for each of the headers will be put only once
>> into the 'configure' file, therefore it keeps the size down. But there
>> is also a drawback that the checks then will turn to be statically inserted
>> to the configure and cannot be conditionalized any more. It will
>> definitely break the dependencies chosen as internally included.
> I'm confused as to why this breaks anything, and if it does break
> gettext then it's not embedded-specific but an upstream bug in the
> configure script, surely.  Can you explain what the problem is?
Yes, I'd like to explain it a little more.
AC_CHECK_HEADERS_ONCE will statically add some code to 'configure' file 
to force checking headers no matter it's in a condition or not. For example:
   ......
   if test "$gl_cv_libxml_use_included" != yes; then
     ......
     AC_CHECK_HEADERS_ONCE([somehead.h])
     ......
   fi

will always check somehead.h even gl_cv_libxml_use_included equal to 
'yes', then there will be a problem if we want to choose some 
dependency, for instance, libxml2, to be internally included, that means 
not refer to any headers or libraries in system, but oppositely, 
AC_CHECK_HEADERS_ONCE will pull in the header that it's supposed to 
check, and that would break the dependency we intended to set.

//Ming Liu
>
> Ross
>
>



      reply	other threads:[~2014-07-17  9:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17  7:58 [PATCH 1/3] flac: explicitly disable checking for nasm Ming Liu
2014-07-17  7:58 ` [PATCH 2/3] gmp: use PACKAGECONFIG to address readline dependency Ming Liu
2014-07-17  7:58 ` [PATCH 3/3] gettext: fix implicit build result Ming Liu
2014-07-17  9:21   ` Burton, Ross
2014-07-17  9:38     ` Ming Liu [this message]

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=53C799AD.4070706@windriver.com \
    --to=ming.liu@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=ross.burton@intel.com \
    /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.