All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danomi Manchego <danomimanchego123@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] uboot: fix custom patch dir legacy handling
Date: Tue, 20 Dec 2016 17:55:41 -0500	[thread overview]
Message-ID: <CANxTyt7w5QA3rQYsOZ7Vev1d4-aVddVX48Oxdc065PTao6pbyg@mail.gmail.com> (raw)
In-Reply-To: <20161220230014.030d3f0d@free-electrons.com>

On Tue, Dec 20, 2016 at 5:00 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 20 Dec 2016 22:45:49 +0100, Peter Korsgaard wrote:
>
>>  > I noticed it now because we are upgrading from 2014.05 to 2016.11.  We
>>  > use both the uboot custom patch dir feature (replaced) and the linux
>>  > custom path feature (dropped, frowny face), so I'm hitting those right
>>  > now.
>>
>> Ok. The replacement for both is simply BR2_GLOBAL_PATCH_DIR (with linux
>> patches under linux/ and u-boot patches under uboot/).
>
> Not completely true: the "linux custom path" feature is not replaced by
> BR2_GLOBAL_PATCH_DIR. If one wants to get the same functionality, i.e
> telling Buildroot to use the Linux kernel source code from an available
> local directory, then the only solution is to use LINUX_OVERRIDE_SRCDIR.

Understood.  It's just that using a custom path for boot loaders and
the kernel is the norm for us, not an exception.  In fact, I've never
been on a project where we were able to use a main line kernel or
uboot.  Sometimes, we'll go through the exercise of making patches
against an initial state of a vendor's git repo, but many of out
project leaders prefer to just source control everything locally.
Under those circumstances, it's nicer to have the local path in the
defconfig than in a secondary local.mk or in the .mk file itself.

Danomi -

  parent reply	other threads:[~2016-12-20 22:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-20  3:10 [Buildroot] [PATCH 1/1] uboot: fix custom patch dir legacy handling Danomi Manchego
2016-12-20  9:06 ` Peter Korsgaard
2016-12-20 20:53   ` Arnout Vandecappelle
2016-12-20 21:04     ` Peter Korsgaard
2016-12-20 21:22       ` Danomi Manchego
2016-12-20 21:45         ` Peter Korsgaard
2016-12-20 22:00           ` Thomas Petazzoni
2016-12-20 22:22             ` Peter Korsgaard
2016-12-20 22:55             ` Danomi Manchego [this message]
2016-12-20 22:56               ` Thomas Petazzoni
2016-12-20 23:12                 ` Danomi Manchego

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=CANxTyt7w5QA3rQYsOZ7Vev1d4-aVddVX48Oxdc065PTao6pbyg@mail.gmail.com \
    --to=danomimanchego123@gmail.com \
    --cc=buildroot@busybox.net \
    /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.