Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: darren.hart@intel.com, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] perf: pass STAGING_INCDIR(sysroot) to perf
Date: Tue, 07 Aug 2012 15:44:30 +0100	[thread overview]
Message-ID: <1344350670.9756.269.camel@ted> (raw)
In-Reply-To: <50212648.8030204@windriver.com>

On Tue, 2012-08-07 at 10:29 -0400, Bruce Ashfield wrote:
> On 12-08-07 10:22 AM, Richard Purdie wrote:
> > On Tue, 2012-08-07 at 10:07 -0400, Bruce Ashfield wrote:
> >> On 12-08-07 10:02 AM, Richard Purdie wrote:
> >>> On Fri, 2012-08-03 at 23:43 +0800, Liang Li wrote:
> >>>> Via EXTRA_CFLAGS, we can pass the sysroot include directory to perf to
> >>>> provide slang.h rather than hardcoded host dir in perf's Makefile.
> >>>>
> >>>> Pass WERROR=0 to perf's Makefile to avoid warnings being treated
> >>>> as errors. Warnings are not fatal, and while they will be fixed in the
> >>>> future, there's no need for them to break the build.
> >>>
> >>> No mention of the additional slang dependency is made here?
> >>>
> >>>> Signed-off-by: Liang Li<liang.li@windriver.com>
> >>>> ---
> >>>>    meta/recipes-kernel/perf/perf_3.4.bb | 3 +++
> >>>>    1 file changed, 3 insertions(+)
> >>>>
> >>>> diff --git a/meta/recipes-kernel/perf/perf_3.4.bb b/meta/recipes-kernel/perf/perf_3.4.bb
> >>>> index 505c7b8..537e926 100644
> >>>> --- a/meta/recipes-kernel/perf/perf_3.4.bb
> >>>> +++ b/meta/recipes-kernel/perf/perf_3.4.bb
> >>>> @@ -24,6 +24,7 @@ DEPENDS = "virtual/kernel \
> >>>>               ${MLPREFIX}binutils \
> >>>>               ${TUI_DEPENDS} \
> >>>>               ${SCRIPTING_DEPENDS} \
> >>>> +           slang \
> >>>>              "
> >>>>
> >>>>    SCRIPTING_RDEPENDS = "${@perf_feature_enabled('perf-scripting', 'perl perl-modules python', '',d)}"
> >>>> @@ -63,6 +64,8 @@ EXTRA_OEMAKE = \
> >>>>    		AR="${AR}" \
> >>>>    		prefix=/usr \
> >>>>    		NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${SCRIPTING_DEFINES} \
> >>>> +		WERROR=0 \
> >>>> +		EXTRA_CFLAGS=-I${STAGING_INCDIR} \
> >>>>    		'
> >>>
> >>> This is is not acceptable since the include directory /usr/include/slang
> >>> is still being looked at and this just "hides" the error. STAGING_INCDIR
> >>> is on the compilers default search path anyway.
> >>
> >> But this makes it first, which is what we were going for. For
> >> an external toolchain, this also might not be true.
> >
> > You have an external toolchain which does not search the sysroot
> > usr/include directory? Really? ;-)
> 
> I do. Trust me on this. I'm not talking about Wind River, I'm
> not talking about oe-core or yocto here.

Well, for such a toolchain, you need to pass STAGING_INCDIR into the
CFLAGS anyway and are likely doing so at a different higher level. I
don't see how this patch changes anything.

> > I accept we won't search usr/include/slang but we don't install slang in
> > that directory anyway so its irrelevant and that isn't the path you're
> > adding.
> >
> >>> So this patch is wrong in several different ways :(
> >>>
> >>> I've merged a temporary fix until we get this resolved properly.
> >>
> >> I think this is a point of view thing, since from here, this is a
> >> better temporary fix than commenting out the path in the perf
> >> Makefile, which will break standalone tree cases if I merge the patch
> >> into the tree, and I don't want to go to a milestone freeze with
> >> an out of tree patch.
> >
> > I doubt it will actually break anything.
> 
> It will, and does if I merge the patch to the kernel tree where
> it belongs. That is my point.

Can you please explain how it breaks? Previously all you've said it "it
might break". Now you say it does break but not how.

As I've explained, I can't see how it would do that as we should never
be looking in /usr/include/slang/.

I'm going to guess that this isn't an external toolchain problem and is
if you build the kernel standalone against your native system with no
cross compilation involved? Its likely a fedora system rather than
ubuntu/debian derived?

It would be nice to not have to guess at what the problem is though...

> >> So I'd ask again that we reconsider this patch, since what's in tree
> >> has issues with other use cases.
> >
> > No, I'm flatly refusing it, sorry.
> 
> That's your prerogative, but I dislike the kernel patch that you
> did with the same flatness.
> 
> I'm not trying to raise a fuss here, but you have to see the
> other point of view on this and acknowledge that the existing change
> is just as unpalatable to me, as the recipe space one is to you.

Well, I'm trying to illustrate how and why its a bad idea, you were just
talking about hypothetical issues with no details. If it does break
something, fine but at least please give some indication of what/how/why
and then we can discuss it.

> In the end, I don't really care, but I just don't like the optics
> of an unsigned, out of tree patch, that I'm not going to merge
> to the kernel, and one that will have to sit where it is for M3.

We had the autobuilder showing read for 5 days with radio silence and
admittedly some confusion over a patch status. What am I meant to do
given I'd really like to take the vacation I have planned this week?

Anyhow, lets see if we can resolve this. Can you answer my previous
question about whether changing this to -I=/usr/include/slang would
work?

Cheers,

Richard







  reply	other threads:[~2012-08-07 14:56 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-03 15:43 [PATCH] perf: pass STAGING_INCDIR(sysroot) to perf Liang Li
2012-08-07 12:56 ` Bruce Ashfield
2012-08-07 14:12   ` Richard Purdie
2012-08-07 14:19     ` Bruce Ashfield
2012-08-07 14:27       ` Richard Purdie
2012-08-07 14:02 ` Richard Purdie
2012-08-07 14:07   ` Bruce Ashfield
2012-08-07 14:22     ` Richard Purdie
2012-08-07 14:29       ` Bruce Ashfield
2012-08-07 14:44         ` Richard Purdie [this message]
2012-08-07 15:26           ` Bruce Ashfield
2012-08-07 15:41             ` Richard Purdie
2012-08-07 15:54               ` Bruce Ashfield
2012-08-07 16:02                 ` Richard Purdie
2012-08-08  3:37   ` Liang Li
2012-08-09  0:36     ` Darren Hart
2012-08-09  1:24       ` Liang Li
2012-08-09  1:41         ` Darren Hart
2012-08-09  1:52           ` Liang Li
2012-08-09  3:54             ` Darren Hart
2012-08-09  1:33       ` Bruce Ashfield
2012-08-14  2:17     ` [discussion] perf: specify SLANG_INC dir for perf Liang Li
2012-08-16 15:33       ` Bruce Ashfield
2012-08-16 15:58         ` Richard Purdie
2012-08-16 16:00           ` Bruce Ashfield
2012-08-16 16:12           ` McClintock Matthew-B29882
2012-08-17  3:32           ` Liang Li
2012-08-17  9:35             ` Richard Purdie
2012-08-17 10:00               ` Liang Li
2012-08-17 10:53                 ` Richard Purdie
2012-08-17 12:55                   ` Bruce Ashfield
2012-08-17 13:01                   ` Liang Li
2012-08-17 13:05                     ` Liang Li
2012-08-20 14:48                       ` Bruce Ashfield
2012-08-21  5:08                         ` Liang Li
2012-08-21  8:51                           ` Henning Heinold
2012-08-21  9:19                             ` Liang Li
2012-08-21 10:40                             ` Richard Purdie
2012-08-21 13:07                           ` Bruce Ashfield
2012-08-22  3:01                             ` Liang Li
2012-08-22  5:41                               ` Bruce Ashfield
2012-08-22  8:17                                 ` Liang Li
2012-08-17 14:35                     ` Darren Hart

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=1344350670.9756.269.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bruce.ashfield@windriver.com \
    --cc=darren.hart@intel.com \
    --cc=openembedded-core@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox