[Buildroot] [uclinux-dist-devel] [Announcement] The 2012R2 buildroot Linux release for Blackfin

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Dear Zhang, Sonic,

On Fri, 8 Mar 2013 02:19:01 -0500, Zhang, Sonic wrote:

> I mean my new patches to address some of your feedbacks in former patches got no response.
> http://lists.busybox.net/pipermail/buildroot/2012-August/057505.html
> http://lists.busybox.net/pipermail/buildroot/2012-August/057506.html
> http://lists.busybox.net/pipermail/buildroot/2012-August/057668.html
> http://lists.busybox.net/pipermail/buildroot/2012-August/057669.html

Yes, just like with any project, it is not easy to get core changes
merged, especially when those are the first contributions from a
developer. It requires time, patience and perseverance.

That's also why I was proposing you to get started with all the package
changes first. They are a lot easier to handle, less intrusive, and
therefore easier to get merged.

> >The thing is that your patches didn't take into account that there is a life beyond
> >Blackfin in Buildroot. While in your own fork you can do a Blackfin-specific hack,
> >we have to make it generic and maintainable in Buildroot upstream.
> 
> Which part of the source override patches are not generic enough? I didn't get any feedback.

Honestly, I don't remember off-hand, I'd have to go through the patches
again.

> >The right way of handling this specific patch is to add a configure.ac check for the
> >fork() function, which will define HAVE_FORK if fork() is available, and then we
> >can use HAVE_FORK in the glib code. This way, the patch has a chance of
> >getting merged upstream.
> 
> How to do deal with packages which are not generated by GNU autotools?

For these, using the -D__NO_MMU__ solution is probably acceptable.
Generally speaking, we try to carry package patches that could
potentially have a chance to go upstream. It's not always possible for
all changes, but we try to do it.

> >I still find the entire wording still very confusing. "When done, the saved selections
> >will be written to .config and autoconf.h." This is not true: only .config is important
> >here, autoconf.h is just generated from it.
> 
> 
> Thanks. Fixed.

> >Also, "Default buildroot settings are passed to make as a text file
> >configs/xxxxx_defconfig." This doesn't mean anything. The
> >configs/xxxx_defconfig files are minimal defconfig describing a particular
> >configuration, that one can use as a sample to start a new
> >configuration:
> >
> >       make <foobar>_defconfig
> >       make menuconfig
> >       make
> >
> 
> Ditto
> 
> >BTW, the title of the section is still "GNU configure Overview", which is wrong.
> 
> Ditto

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com