[Buildroot] Analysis of build failures

[Nathaniel Roach <nroach44@gmail.com>]

On 07/09/14 20:17, Thomas De Schampheleire wrote:
> On Sun, Sep 7, 2014 at 9:21 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> On Sat, 06 Sep 2014 22:25:33 +0200, Peter Korsgaard wrote:
>>
>>>  > Seems like Nathaniel autobuilder does not have the ncurses development
>>>  > libraries installed (also causing build failures in host-mysql, for
>>>  > example). What is our policy regarding ncurses? I have it installed in
>>>  > my autobuilder because I use it to run "make menuconfig". But it's true
>>>  > it's not technically absolutely required to run a Buildroot build.
>>>
>>>  > Should we add dependency on host-ncurses where appropriate? Or should
>>>  > we make ncurses development files on the build machine a mandatory
>>>  > dependency? What if the user uses only xconfig or gconfig?
>>>
>>> Given how many people use menuconfig, I think we should just make
>>> ncurses a mandatory dependency. Just about anybody doing embedded Linux
>>> development needs them anyway to configure
>>> barebox/linux/busybox/uclibc/ctng/..
>>>
>>> If not, then we would also need to add host-ncurses to our
>>> barebox/linux/busybox/uclibc-menuconfig targets.
>>
>> Well not sure we want to go down this road: it would mean we should add
>> host-qt as a dependency of the linux-xconfig target for example. We
>> could also decide that the *-menuconfig targets need to have curses-dev
>> installed on the build machine, but that the package that we build and
>> that need host-curses will depend on host-curses.
>>
>> But well, menuconfig is indeed widely used, so maybe the easiest
>> solution would be to make ncurses-dev a mandatory dependency.
>>
> 
> An alternative is to use the suitable-host-package mechanism in such
> cases: if the host does have ncurses (but the same could be done for
> autoconf, automake, flex, bison, and other host packages) then build
> it inside buildroot. If it does, then just use them directly.
> Since the build of host-ncurses does take some time, it may be
> advantageous for the user to install ncurses on the host anyway, to
> avoid long build times, so a notice at the end of the build process to
> suggest that could be useful.
> 
> Best regards,
> Thomas
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


Just my two cents:

For anything that requires user interaction like xconfig for menuconfig
(for buildroot or the kernel for example), use the host's libraries -
They are likely to have them installed and it will be quicker if I want
to change a config option. Also, none of the config binaries will be
copied to the target.

For any package that depends on ncurses to build, build host-ncurses -
This provides isolation against any changes between distributions and
ensures that we have control over versions.

Additionally, if the build time dependencies of BR are kept to a
minimum, it may be beneficial some situations where the user may not
have control of the building system - I doubt anyone actually uses BR in
this situation, but it's possible. I can see a situation where the user
configures BR on their laptop, and pushes the config to a more powerful
shared system to build it.

Finally, I'm not fond of the suitable-host-package approach Thomas has
mentioned: while again, I doubt the probability of such a case
happening, things like distro-specific patches or behavior may change
builds. (For example, my router firmware segfaults during build on
Ubuntu but not on Debian)

Thanks, Nathaniel