Easy Upgrade Path?

Hello List:

I've been getting used to the buildroot development environment using 2009.02-RC2 for ARM AT91SAM9g20-EK. I have made lots of changes and additions that suit our project (config files, packages, etc.) We have successfully compiled and included some of our own programs.

What is the recommended method to upgrade to the newest build environment so we don't have to re-do everything? Is this possible?

Best Regards,
Dan Pattison

Hi Dan

I don't know if there is any recommended way. None is documented, and I guess each one does whatever they see best.

I had the same problem as you, and after some thought I decided the best approach would be to "fork" from buildroot svn to my own private svn server (svn export) and do my changes there. I've also added a file upstream.rev which only contains the last revision from svn that I have merged from upstream (svn diff -r last:current > upstream-rev.patch && patch -p0 < upstream-rev.patch).

The downside is that svn diff patches doesn't remove files removed from the repository, so you need to do that manually. This happens most often were patches are stored. A simple diff can catch those then you need to manually do svn rm in your repository.
My own packages (code I've developed) I've added to package/mycompany/*, so, when I do a diff between buildroot checkout and my repository, I can easily mask that.

Also, generic changes/development, I try to push upstream whenever possible. This both benefits other users and also helps us keeping the differences smaller, so merges with upstream are a bit easier.

This is far from a good solution, but has worked so far.

Hope this helps.

Best Regards,
Thiago A. Correa

Hi,

Thiago> I don't know if there is any recommended way. None is Thiago> documented, and I guess each one does whatever they see best.

Thiago> I had the same problem as you, and after some thought I Thiago> decided the best approach would be to "fork" from buildroot Thiago> svn to my own private svn server (svn export) and do my Thiago> changes there. I've also added a file upstream.rev which only Thiago> contains the last revision from svn that I have merged from Thiago> upstream (svn diff -r last:current > upstream-rev.patch && Thiago> patch -p0 < upstream-rev.patch).

There's an easier way - Take a look@vendor branches and the svn_load_dirs.pl in the svn book.

Thiago> Also, generic changes/development, I try to push upstream Thiago> whenever possible. This both benefits other users and also Thiago> helps us keeping the differences smaller, so merges with Thiago> upstream are a bit easier.

Exactly.

Thiago> This is far from a good solution, but has worked so far.

We do something similar (using vendor branches though), and it works pretty well. We might want to do something to make it easier to keep the project/device specific stuff seperate though.

Bye, Peter Korsgaard

Thanks for the reply Thiago. I will see if I can get a svn server going and try your method.

Best Regards,
Dan Pattison

Ulf introduced local/ when he started to commit and this was a good idea.

It got booted out some time later, by someone.

The point is that you can put your config files and non-included packages there and keep that out of the rest of the tree.

I like the idea and would like to put it back in.

Thomas.

Hi,

Thomas> Ulf introduced local/ when he started to commit and this was Thomas> a good idea.

Thomas> It got booted out some time later, by someone.

I don't remember the details, but it was afaik quite half baked,

Thomas> The point is that you can put your config files and non-included Thomas> packages there and keep that out of the rest of the tree.

Thomas> I like the idea and would like to put it back in.

I agree that we should realize the fact that any big user of buildroot want to customize it somehow and make it easy to do - But we need to do it in a clean way.

Bye, Peter Korsgaard

The proposal was to create the local directory

mkdir local
touch local/Config.in
touch local/Makefile.in

and include the two new files in toplevel Makefile and Config.in If BUILDROOT_LOCAL exists, this should override local,
---

As long as the user is not interested, nothing happens. If the user is interested, then the user replaces the local with a symlink to his own directory.

Nothing halfbaked about that.
The idea was rejected, because it gave people an ability to include things in their filesystem which was not available in the svn to other users of Buildroot.

Best Regards
Ulf Samuelsson

I'm using local/ a lot in my own development. I have config files (buildroot, busybox, linux, uClibc), the device table and the target_skeleton in there.

There wasn't any support for additional packages via local/ although it would be useful - I had to modify the top level makefiles to add such a section here, making maintenance more difficult.

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

That's exactly where I was going w/ the patch I just posted. w/ my patch, you can specify at the various locations in "make menuconfig" each of the items you mentioned (patch adds ability to specify target_skeleton and device table for which I didn't see anywhere in there one could do that)

local/project/buildroot.config
local/project/busybox.config
local/project/linux.config
local/project/uClibc.config
local/project/target_skeleton
local/project/device_table.txt

I would think for a lot of setups out there, the above would cover most people's needs.

I follow the standard docs for adding software under package/ and tweak of package/Config.in so it appears in the config menus. Doing this minimizes changes needed to buildroot beyond what's documented for extending buildroot and provides all of the control I need for total customization.

-Eric

"Half baked" should not be reason enough to boot something unless it's being too obtrusive or replaced by something better.

This was neither.

As clean as possible, yes.

Thomas.

Hi,

Just for the sake of documentation, if anyone wants to try my "home method",

svn merge svn://uclibc.org/trunk/buildroot -rupstream.rev:HEAD

Seams to work much, much better, and you get --dry-run to see will
be the merge result :)

Please, notice again that there might be better methods. I tried to
locate the script Peter mentioned, but I couldn't get it to be installed in my gentoo distro :(
But svn merge seams to be doing what the perl script does.

Kind Regards,
Thiago A. Correa

Hi,

Thiago> svn merge svn://uclibc.org/trunk/buildroot -rupstream.rev:HEAD

Thiago> Seams to work much, much better, and you get --dry-run to see will
Thiago> be the merge result :)

Thiago> Please, notice again that there might be better methods. I tried to
Thiago> locate the script Peter mentioned, but I couldn't get it to be Thiago> installed in my gentoo distro :(
Thiago> But svn merge seams to be doing what the perl script does.

You can grab it from subversion svn:

http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn_load_dirs/

Bye, Peter Korsgaard