From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Fri, 8 Mar 2013 09:33:52 +0100 Subject: [Buildroot] [uclinux-dist-devel] [Announcement] The 2012R2 buildroot Linux release for Blackfin In-Reply-To: References: <20130307095939.1316014e@skate> <20130307121430.2780392a@skate> Message-ID: <20130308093352.73ab92e5@skate> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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 _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