[OE-core] [PATCH 1/4] glibc: Remove site_config and glibc-initial

[Yang, Liezhi]

Hi Randy,

Sorry, I am OOO today, will do it next week.
BTW, I have looked into siteconfig and siteinfo recently, and have some crazy ideas on them, which seems can save a lot of configure time, I will try to send them out next week.

// Robert

Sent from mobile phone

> 在 2018年12月21日，10:22，Mark Hatle <mark.hatle at windriver.com> 写道：
> 
>> On 12/20/18 1:50 PM, Burton, Ross wrote:
>>> On Thu, 20 Dec 2018 at 18:02, Mark Hatle <mark.hatle at windriver.com> wrote:
>>> As far as zlib/ncurses being the only things that augmented them, when this was
>>> originally implemented many years ago -- those items were the most commonly used
>>> by other configure scripts.  So adding those defaults when zlib and/or ncurses
>>> was provided by the system offered a measurable difference in the performance of
>>> configure.
>> 
>> Do you know what the zlib and ncurses siteconfig files were doing?
>> Just short-circuiting the AC_CHECK_HEADER call, which is basically
>> stat(includedir + header.h).  I'd call that the definition of
>> premature optimisation. :)
> 
> In the original AC_CHECK_HEADER stuff, it was more then just a simple stat.  The
> system would compile a small executable that included the header and then
> attempted to execute a pass/fail -- or in the cross compile case would do
> something with the output binary.
> 
> This very well may have changed from a compilation step to a simple stat in
> configure in the the last 4 or 5 years.  It's that compilation/execution step
> (both that and the various sizeof) that were hideously slow in the original
> implementation and being avoided by the special contents.
> 
> The assumption we were making of course was that zlib, ncurses (or anything
> else) actually worked with those headers.. so we skipped the compilation and
> just did a stat based on the headers to fill things out.
> 
> The systems that did the sizeof and header identification in the site-config
> bbclass were written to do things in a dynamic way so that if the system
> behavior changed we wouldn't have incorrect defaults "until someone noticed".
> 
> The behavior of using the compiler to identify a sizeof and using tools to
> return the result is actually very efficient -- but does require a functioning
> compiler (and headers).  If I remember correctly, we're not fully compiling, but
> putting out an intermediate object which we can then query for the values of the
> various pieces.  (In one iteration at least, we processed all of the sizeof in a
> single pass making it even more efficient.)
> 
> --Mark
> 
>> Ross
>> 
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core