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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
