All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yegor Yefremov <yegorslists@googlemail.com>
To: buildroot@busybox.net
Subject: [Buildroot] Best-Practice Suggestions for developing package patches in buildroot
Date: Thu, 29 Jan 2015 08:46:22 +0100	[thread overview]
Message-ID: <CAGm1_ku6SdP2jbM8K71ykv2pwBz7e7LtDw1bVFqmZ+YwpFOGDw@mail.gmail.com> (raw)
In-Reply-To: <CAJpxd069iQi27WrZ+LuzM_dEZxFHot4aDHTtkcgJnNBU1QSHgA@mail.gmail.com>

Hi Bryce,

On Thu, Jan 29, 2015 at 1:04 AM, Bryce Schober <bryce.schober@gmail.com> wrote:
> Buildroot devs,
>
> It would be helpful to get ideas for how best to develop a set of patches
> against a package's upstream source inside of the buildroot context
> (cross-compiler, libraries, etc.).
>
> Do you use something like quilt to manage patches while developing them?
>
> Do you fork the upstream repository a switch the package to use the fork,
> then back out your modifications into patches?
>
> Do you just copy the full commands generated by buildroot and use re-use
> them outside of buildroot's high-level make commands?
>
> For package problems that can be reproduced & fixed outside of the full
> buildroot sysroot it's much less of a problem. I'm interested specifically
> in development workflows that would be helpful for packages that have
> problems that require the buildroot sysroot to reproduce and fix.

Please read Section 8.6.11 "Using Buildroot during development"
(http://nightly.buildroot.org/manual.html#_advanced_usage). It will
give you a good idea, how to work on upstream code.
<pkg1>_OVERRIDE_SRCDIR is the keyword.

Yegor

  reply	other threads:[~2015-01-29  7:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29  0:04 [Buildroot] Best-Practice Suggestions for developing package patches in buildroot Bryce Schober
2015-01-29  7:46 ` Yegor Yefremov [this message]
2015-01-29  8:16   ` Jeremy Rosen
2015-01-29 18:09 Bryce Schober
2015-01-31 22:06 ` Thomas Petazzoni
2015-02-02  8:44   ` Jeremy Rosen

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=CAGm1_ku6SdP2jbM8K71ykv2pwBz7e7LtDw1bVFqmZ+YwpFOGDw@mail.gmail.com \
    --to=yegorslists@googlemail.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.