[Buildroot] [PATCH] Allow Buildroot to update toolchain

[ANDY KENNEDY]

> > Never have I had a problem using the libraries that I build into the
> > toolchain using this same procedure.
> 
> That's because it works in your particular case, but it doesn't work in
> the general case. For example, with your solution, try to build an
> application which uses 'pkg-config' to discover libraries. It will
> fail, because you don't have $(HOST_DIR)/usr/bin/pkg-config, which
> Buildroot has specially compiled to make sure it points to the
> cross-compiled libraries and headers.

Most of the time pkg-config is not needed as the code being built is
proprietary and the companies that are using these don't have knowledge
of how/when to use these utilities.

> > Perhaps you should attempt my patch once (using it in the prescribed
> > method) to see the difference yourself.  What I did was to build the
> > original toolchain using Crosstool-NG, tar that up, then use that
> > tarball as the starting point.  After this, I built two versions of
> > the toolchain.  The first I started by using the unmodified 2013.08.1
> > Buildroot code.  After it was completed, I moved the two toolchains
> > to another directory (for safe keepings) untarred the toolchain again
> > and did another build (starting from a clean Buildroot directory,
> > then applying my patch) and build again using the same configuration
> > but setting HOST_DIR back to $(BUILD_DIR)/host and setting the new
> > configuration option (using menuconfig -- I'm lazy)
> > BR2_TOOLCHAIN_COPY_LIBS_INTO_TOOLCHAIN to yes.
> 
> I'm not sure to follow your procedure works. But clearly, a Buildroot
> option that copies back the libraries into the external toolchain is
> not acceptable: the external toolchain is not meant to be changed by
> Buildroot. If you really want to do that, you can just take
> output/host/usr/<tuple>/sysroot and use that to replace the original
> toolchain sysroot.

Hmmm, I'm not sure that would be exactly what I was going for, but
I'd have to try it (and I don't really care at this point).  Other than
the size differences below, the nice to have is that the toolchain is
contained in one directory.  Whereas I could push the original toolchain
a level deep then locate the Buildroot host dir next to it in that dir,
this, I fear, would be confusing to those who consume the toolchains.  I
would expect the question of "which one am I supposed to use" to come
back to me.  Though, one could fix this by (as I do anyway) by providing
a Makefile in the toolchain directory which will generate an environment
shell script to "configure" the toolchain for a given shell.

But, anywho, it doesn't matter.

> > /opt/toolchains# du -s yourway myway orig
> > 1098948 yourway
> > 991592  myway
> > 387772  orig
> 
> So you've saved 107 MB over 1 GB, that's about 10%. I don't see how it
> matches the 283% and 255% numbers you've given above.

1098948/387772 = 2.8340055... * 100% = 283%
991592/387772 = 2.557152....  * 100% = 255% (I guess this should have
been 256% with the rounding -- I truncated, my bad).

> > Now do you understand the difference between the two patches?
> 
> Which "two" patches ? You've submitted only one.

The patch submitted about a year or two ago that moved around the
HOST_DIR stuff vs the one I submitted last week.

> However, you have to understand that touching to the core mechanisms of
> Buildroot takes more time than getting package changes merged. This is
> because we're paying close attention to keep Buildroot simple, and
> avoid having multiple mechanisms to do the same thing, or mechanisms
> that serve too specific use cases that we think shouldn't be handled by
> Buildroot.
> 
> I personally believe that the existing Buildroot users like it because
> it is quite simple to understand and easy to use. If we start to accept
> all sorts of mechanisms without a good and sensible use case, a good
> coherency with the other existing mechanisms, then we will loose this
> simplicity, which is the core advantage of Buildroot.

One cannot argue with the principles presented here.  The application of
such principles are where I have differing views.

As far as this patch goes, if all within the Buildroot community are
vehemently against such a patch, so be it.  I will not blow against
the wind.

::enter drama queen mode::
Defeated,
::exit drama queen mode::
Andy