[Buildroot] svn commit: trunk/buildroot/target/device/Atmel:atngw100 atngw100-base atngw100-expanded etc...

Thiago A. Corrêa thiago.correa at gmail.com
Tue May 6 17:19:14 UTC 2008


>
>  > A couple of us AVR32 users have been
>  > discussing the patch.avr32 scheme, is this out of the question?
>
>  What is the benefit?
>  You can add patches to the AVR32 prepatched toolchain at "target/device/Atmel/toolchain"
>  Just need to add the correct directories.
>
>  The drawback of having patches inside the svn is that everyone not
>  using AVR32 will have to suffer the additional download.

Anyone not using avahi suffers additional download for that package,
as well as java, or MIPS, or x86. Do you see where I'm getting?

The benefit are several:

- More eye balls: the underlying building is used and improved by many
different platforms. Improvements in one affects all. A breakage here
will be detected and fixed more rapidly.

- Freedom of access: anyone with commit access to SVN can fix or
update the whole system, there is no dependency on a single person.

- Less disk space consumed and bandwidth saved: Anyone building for
more than one platform doesn't require additional 50Mb per toolchain.
That's for all developers, everyone here has at least once built for a
different $(ARCH) than they usually do.

- It worked: the external toolchain doesnt.

- Gives visibility to patches: If a patch breaks an $(ARCH) all you
have to do is rename it, but you gain the knowleadge that the issue
exists, and the patch maintainer can be notified. This makes it easier
for patches to be accepted upstream later on.

- We could get rid of Atmel Specifics: In buildroot we have 2 flavors
of external toolchain: generic and Atmel. Kill Atmel.

Seriously, building an image takes several gigabytes, my dl dir has
1Gb of downloaded packages alone, when extracted they expand a lot,
when compiled, another 2 fold, how significant is a few patches?

Regards,
    Thiago A. Correa



More information about the buildroot mailing list