Buildroot best/common practices

Dave Dodge dododge at dododge.net
Thu Jan 19 09:11:01 UTC 2006


On Mon, Jan 16, 2006 at 09:38:21AM -0500, Doyle, Patrick wrote:
> When I start thinking about that, I start thinking, "Gee what I
> should do is to track which revision of buildroot I checked out, and
> then generate a patch file of my local changes against that
> revision, and keep control of that, along with the generated
> configuration files."

If you want to maintain local changes, this may be helpful:

  http://savannah.nongnu.org/projects/quilt

Quilt is designed to help you create and manage a set of patches
against someone else's codebase, where occasionally that base will
change and you'll need to re-fuzz or update the patch contexts
appropriately.  It stems from Andrew Morton's old scripts to manage
the -mm changes to vanilla Linux.

For example, you check out the svn tree of the codebase.  Then use
"quilt new" to start a new patch against that codebase.  You use
"quilt add" to tell quilt about any files you're changing or adding
for this patch (note: you must do this _before_ modifying the file!).
After making some changes, a "quilt refresh" will generate a regular
patch file containing your changes.

To update the underlying codebase, you can use "quilt pop" to remove
your changes from the live tree.  Then you can "svn update" without
your changes interfering.  At this point a "quilt push" will attempt
to reapply your patch.  If some chunk fails to apply, you'll have to
deal with that by hand.  Once the patch is applied, you can use "quilt
refresh" again and it will update the patch contexts to take care of
any fuzzing that might have been needed.

If you have a series of distinct changes, you can put each into a
separate patch and quilt will also track the order that they need to
be applied.  When working with a series of multiple patches, the
push/pop commands let you move back and forth in the series.  The
whole thing is very simple and tolerant, in that you can go into
quilt's "patches" directory and hand-edit the data files without
likely breaking anything.

If you use emacs, there's also a quilt-mode (and I have some minor
adjustments to it):

  http://www.selenic.com/quilt/
  http://lists.gnu.org/archive/html/quilt-dev/2006-01/msg00007.html

Among other things, this automatically sets buffers read-only if they
aren't in the current patch, preventing you from accidentally
modifying a file before doing a "quilt add".

Even on projects where I commit to svn, I still use quilt to develop
my changes.  It lets me easily have partial/broken code under
development and do things out-of-order.  I noticed that mercurial now
has a "Queues" extension that apparently integrates this sort of
workflow directly into the system.

                                                  -Dave Dodge



More information about the uClibc mailing list