[Buildroot] Easy Upgrade Path?

[Buildroot] Easy Upgrade Path?

[Dan Pattison]

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

[Buildroot] Easy Upgrade Path?

[Thiago A. Corrêa]

Hi Dan

On Mon, Feb 9, 2009 at 4:53 PM, Dan Pattison <dan.pattison@ethertek.ca> wrote:
> 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?
>

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

[Buildroot] Easy Upgrade Path?

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi,

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

 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

[Buildroot] Easy Upgrade Path?

[Dan Pattison]

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

Best Regards,
Dan Pattison


Thiago A. Corr?a wrote:
> Hi Dan
>
> On Mon, Feb 9, 2009 at 4:53 PM, Dan Pattison <dan.pattison@ethertek.ca> wrote:
>   
>> 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?
>>
>>     
>
> 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
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.233 / Virus Database: 270.10.19/1941 - Release Date: 02/06/09 11:31:00
>
>   

[Buildroot] Easy Upgrade Path?

[Thiago A. Corrêa]

Hi,

On Tue, Feb 10, 2009 at 10:35 PM, Dan Pattison <dan.pattison@ethertek.ca> wrote:
> Thanks for the reply Thiago. I will see if I can get a svn server going and
> try your method.
>

   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

[Buildroot] Easy Upgrade Path?

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

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

[Buildroot] Easy Upgrade Path?

[Thomas Lundquist]

On Mon, Feb 09, 2009 at 10:53:34AM -0800, Dan Pattison wrote:
> 
> 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?

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.

[Buildroot] Easy Upgrade Path?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Lundquist <lists@zelow.no> writes:

Hi,

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

 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

[Buildroot] Easy Upgrade Path?

[Ulf Samuelsson]

>>>>>> "Thomas" == Thomas Lundquist <lists@zelow.no> writes:
>
> Hi,
>
> >> What is the recommended method to upgrade to the newest build
> >> environment so we don't have to re-do everything? Is this possible?
>
> 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.
>

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

[Buildroot] Easy Upgrade Path?

[Thomas Lundquist]

On Thu, Feb 12, 2009 at 02:35:18PM +0100, Peter Korsgaard wrote:
> 
>  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,

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

This was neither.

> 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.

As clean as possible, yes.


Thomas.

[Buildroot] Easy Upgrade Path?

[Hamish Moffatt]

On Thu, Feb 12, 2009 at 02:29:45PM +0100, Thomas Lundquist wrote:
> On Mon, Feb 09, 2009 at 10:53:34AM -0800, Dan Pattison wrote:
> > 
> > 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?
> 
> 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.

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 <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Easy Upgrade Path?

[Eric Malkowski]

Hamish Moffatt wrote:
> On Thu, Feb 12, 2009 at 02:29:45PM +0100, Thomas Lundquist wrote:
>   
>> On Mon, Feb 09, 2009 at 10:53:34AM -0800, Dan Pattison wrote:
>>     
>>> 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?
>>>       
>> 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.
>>     
>
> 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
>   
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