Re: parallelized configure

[Mike Frysinger]

On Tuesday 14 January 2014 20:11:34 Bob Friesenhahn wrote:
> On Tue, 14 Jan 2014, Mike Frysinger wrote:
> > there's semi-precedence though with introducing new macros when there's
> > no
> > 
> > confidence in safely converting existing one.  consider:
> >     AC_CHECK_FUNC beget
> >     AC_CHECK_FUNCs beget
> >     AC_CHECK_FUNCS_ONCE
> > 
> > same for HEADERS and DECLS.  maybe time to beget a
> > AC_CHECK_FUNCS_ONCE_PARALLEL ? :)  or maybe enshrine the ONCE behavior
> > and call it AC_CHECK_FUNCS_PARA.  that'd cover a decent amount of ground
> > (albeit, not as much as would truly be possible from an interlocked
> > pipeline) without too much pain.
> 
> Unfortunately, that is only part of the problem.  The main problem is
> the cascading shell variable definitions which appear, are modified,
> or even disappear as configure script statements are executed.  Some
> of these variable modifications are done as actions of the macros and
> others are done by code added by the package developer.

right.  my point is that the new macros come with new semantics that say "hey, 
you can't do X or rely on Y".  that way existing semantics stay the same.

> Configure could be sped up by using a shared caching system for common
> tests (e.g. standard header file existence) or perhaps even by
> creating a new shell which is a closer fit to what configure needs.

config.site deployment runs into the same problem.  some configure packages 
like 
to test headers with varying defines and test the resulting behavior.  we 
prototyped a scaled/large deployment in Gentoo ... worked great most of the 
time, but these edge cases kept us from deploying further :(.
-mike

signature.asc
Description: This is a digitally signed message part.