All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Darren Hart <dvhart@linux.intel.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: RFC: Further kernel build process changes?
Date: Wed, 7 Jan 2015 16:20:12 -0500	[thread overview]
Message-ID: <54ADA30C.4090804@windriver.com> (raw)
In-Reply-To: <1420665363.25779.73.camel@linuxfoundation.org>

On 15-01-07 04:16 PM, Richard Purdie wrote:
> On Wed, 2015-01-07 at 10:33 -0800, Darren Hart wrote:
>> On 1/7/15, 5:22 AM, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>>> On 2015-01-07 7:26 AM, Richard Purdie wrote:
>>>>
>>>> External module builds do work in this configuration *if* you pass in
>>>> the correct options e.g.:
>>>>
>>>> make -C work-shared/MACHINE/kernel-source
>>>> O=work-shared/MACHINE/kernel-build M=${S}
>>>>
>>>> I've put together a quick proof of concept of this below.

<snip>

>>>>    KERNEL_OBJECT_SUFFIX = ".ko"
>>>>
>>>>    # kernel modules are generally machine specific
>>>>    PACKAGE_ARCH = "${MACHINE_ARCH}"
>>>>
>>>> +do_configure[depends] += "virtual/kernel:do_install"
>>
>>
>> I¹m not clear on the separation of do_shared_workdir and do_install now...
>
> See above, this probably needs to change.
>
> The patch was really a test to see how badly a build would explode with
> separate source and builddir and whether the kernel build system can
> cope with three separate locations (source, build objects, module). From
> that perspective it passed in that I could build oprofile, perf and some
> kernel modules. From here we need a step back and to go through and do
> it "properly".

Agreed. I've queued all the known patches, and have proven that my
builds work with this applied with minor adaptations.

I've got a first pass through with the consolidation and some other
scribbles notes. I'll generate a topic branch and send it out when
it looks reasonably sane (but not complete .. since we don't want to
sit on large private changes).

Cheers,

Bruce

>
> Cheers,
>
> Richard
>



  reply	other threads:[~2015-01-07 21:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 12:26 RFC: Further kernel build process changes? Richard Purdie
2015-01-07 13:22 ` Bruce Ashfield
2015-01-07 18:33   ` Darren Hart
2015-01-07 21:16     ` Richard Purdie
2015-01-07 21:20       ` Bruce Ashfield [this message]
2015-01-13  1:19 ` Robert Yang
2015-01-13  1:27   ` Robert Yang
2015-01-13  2:59     ` Hart, Darren

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=54ADA30C.4090804@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=dvhart@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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.